OWL MIDI API for Patch Use

OWL
#1

I’m working on some fairly complex patches that have a ton of settings. Up until now I’ve been mapping them to the various Knobs in interesting ways but I’d much prefer MIDI Support.

My plan would be to use TouchOSC on my iPhone to make an interface that can send MIDI through my computer to the OWL.

Extending the registerParameter interface to allow callback functions that can respond to MIDI CCs would greatly enhance the OWLs ability. I’ve already hacked together an attempt at this, but it would be much more useful to have an official implementation.

Thoughts? Any chance of getting this implemented soon?

#2

Are callbacks necessary? How about extending the existing getParameterValue() interface?

e.g. Patch::registerExtendedParameter() with name and default value, and Patch::getExtendedParameterValue() returning a float between 0.0 and 1.0?

This could then be easily mapped to MIDI CC values in a certain range. And possibly in the future to OSC, though I’m not sure what the transport protocol would be for OSC.

#3

Callbacks aren’t necessary, I just assumed MIDI messages would arrive far less frequently than actual ADC values and saw that the ADCs get stored in the patch object. For MIDI messages there might not be enough interest to store extra information for every possible MIDI message on the off chance it is requested.

More than ranged ‘knob’ values, the sent value is often used as a switch or quantized setting. Because of that, providing the 7-bit value would be a little more useful for me (though it isn’t hard to get back to it from floats…)

EDIT: Now that I think of it, NRPN support in the form of floats would be pretty awesome on top of 7-bit values.

#4

With floats we can support things like NRPNs and smoothing. I’m not quite sure how best to implement this with a nice, simple API and minimal impact on performance though.

At the moment we do smoothing and hysteresis on 5 parameters, which has a very small performance overhead.

How many parameters do you think is useful? Up to 8 more? 16?

#5

For me at least, I’m probably going to burn through them quickly using them more as binary toggles etc. I don’t plan on smoothly changing the values and thus the hysteresis and smoothing aren’t that important for me. I’d rather have more parameters that aren’t smoothed than fewer that are.

And because I’m only planning on changing them on ~human time scales (not with automation) they should be arriving pretty infrequently, hence my suggestion of call backs so that you don’t have to store them and smooth them for every patch, always.

Again, I mostly just need a clean way for the MIDI portions of the code to notify me that a new message has arrived. If I need to smooth etc I can always do it myself.

#6

I think this is a good feature request.

Could you please open an issue on github:

I think a good, straightforward implementation would be to simply have more OWL parameters, and map them out to MIDI CCs or whatever.