Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

Microtonality #141

Open
suhr opened this issue Nov 3, 2018 · 12 comments
Open

Microtonality #141

suhr opened this issue Nov 3, 2018 · 12 comments

Comments

@suhr
Copy link

suhr commented Nov 3, 2018

No description provided.

@Fire-wood
Copy link
Member

Hey, thanks for checking out Axiom!
Could you be a bit more descriptive with what needs microtuning? Maybe these will help you: controls can be set to specific values and ranges, exact values can be input in the Maxim code and there is a zoom slider on graphs for more control.

@suhr
Copy link
Author

suhr commented Nov 4, 2018

I'm talking about the possibility to use musical tunings different from 12 tone equal temperament.

Is note a fractional value? If so, MIDI to note could load scl+kbd or tun files.

@suhr suhr changed the title Microtuning Microtonality Nov 4, 2018
@cpdt
Copy link
Member

cpdt commented Nov 4, 2018

@suhr Yes, all numeric values (including notes) are fractional, so you could add/multiply to change tuning.

MIDI to note simply provides the MIDI note number that was encoded in the input event. The conversion to a frequency is done by the [freq] converter (see the reference page on converters), which is done by all of the oscillators. That converter uses the standard MIDI tuning, however if you have a formula for a different tuning you could easily use that instead of the converter. Does this do what you want?

Alternatively, you can configure tuning in the host application that Axiom is running in.

Thanks for providing references to those file formats. I'll have a look at them, however at least at the moment please keep in mind that it's semi-out of scope (since, at least from what I can tell, it's something that would be handled by the host).

@cpdt
Copy link
Member

cpdt commented Nov 13, 2018

Hey @suhr, are you able to let us know if what I described above is a suitable solution to the feature request? If so, feel free to close this (or we will in a few days), if not, can you elaborate further so we can work out how to implement it?

@suhr
Copy link
Author

suhr commented Nov 13, 2018

For some cases it is. But in general case you want to have a map MIDI note → Pitch. It is reasonable to just load .tun files (or something similar). Such mapping could be done in a separate module.

@cpdt
Copy link
Member

cpdt commented Nov 14, 2018

Yeah, fair enough. From my perspective at the moment though, it looks like something that should/would be handled by whatever host Axiom is running in (is this a correct assumption?). While it'd definitely be nice to have as a feature at some point, it's not much of a priority for us at the moment for that reason (and since this is entirely a free-time project, unfortunately I'm not able to get everything that I'd like to done :/).

Of course, you're free to implement it and make a PR if you're willing to try your hand at it. If you do want to, let me know and I can walk you through the process :)

@suhr
Copy link
Author

suhr commented Nov 14, 2018

If you do want to, let me know and I can walk you through the process :)

Sure. Can I implement it in Rust?

@cpdt
Copy link
Member

cpdt commented Nov 15, 2018

Awesome! Unfortunately most of it would be in C++ since that's what the actual editor/GUI app is written in - at the moment the compiler (bit that sits between the editor and LLVM) is written in Rust. I'm open to introducing Rust to more components though :)

The first step here of course would be to figure out how this should look from a user perspective. I'm not sure how familiar you are with how Axiom actually works, but basically the modules you see are just pre-built sets of nodes which were made in the editor with the scripting language (called Maxim). If you drag one in and double-click it, it'll open up the code panel and you can see or edit how it's implemented. You can also make a fresh, empty node by right clicking somewhere and clicking "New Node".

So basically we need a way for a .tun file to be loaded by the editor, and the data somehow be exposed to the scripting language. This is something I've also been thinking about for the sampler control (#63), which would also need a way to load in files. I'd rather not define a new datatype in the language just for passing this data from, say a control with a file picker, to a function that actually does the processing, but I'm not really sure what other alternatives there are.

Along those lines I guess we'd also need a way to package those files into the save file as well (which the sampler would also need), which could integrate with #68.

Does that make sense at all? What do you think?

@suhr
Copy link
Author

suhr commented Nov 15, 2018

I'll take a look at Maxim modules.

@suhr
Copy link
Author

suhr commented Nov 23, 2018

For tunings, it may be reasonable to just have types for multi-line text. Then you have just use two modules for kbd+scl.

Btw, I have written a module for equal temperaments in maxim. How do I make it look like built-in modules? And how do I add it to the global palette?

@cpdt
Copy link
Member

cpdt commented Nov 23, 2018

Just to clear up some terminology, nodes are the things that appear in the main area and have controls on them. A module is one or several nodes together, in the library. The distinction is pretty important, since modules can contain several nodes (e.g. see the Feedback Delay module, which has two connected nodes).

But anyway - you can save nodes as a module by selecting the ones you want, then right clicking and picking "Save As Module...". The library is persistent, so any modules you save are always accessible.

I'm not that much of a fan of passing things around in plain text in the editor (if that's what you're referring to?), since it means we suddenly have the possibility of runtime errors which can happen at any time, e.g. due to text that isn't in the format that's expected. In general Axiom is designed so that any action you can perform in the editor is valid, or an error is shown when you perform the modification in rare cases (like syntax/compile errors). Unfortunately passing text around can't guarantee that anymore, since it's always possible to change the text to something else dynamically causing an error.

@suhr
Copy link
Author

suhr commented Nov 23, 2018

All right, can we have a list of values instead (though it is less convenient than just text)?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants