monadgroup / axiom

A powerful realtime node-based audio synthesizer.
Other
677 stars 32 forks source link

Microtonality #141

Open suhr opened 5 years ago

Fire-wood commented 5 years ago

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 commented 5 years ago

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.

cpdt commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Sure. Can I implement it in Rust?

cpdt commented 5 years ago

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 commented 5 years ago

I'll take a look at Maxim modules.

suhr commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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