Midi and analog input (pots etc) Software implementation

#1

Hi,

First of all just wanted to say this is a great project. keep up the good work!

Looking at buying my first core but first i have a few things i would like to clarify.

Ok, so from what i understand you can assign a midi CC to a parameter to tweak in real time from a midi enabled input device. So when the core is running stand alone, you attach a midi knob bank to the hardware midi input of the core and tweak away.. ok cool.

Now, if i were to add a hardware pot to the core, if i am correct the input from this pot would exist on an extra layer inside the patcher, and send 'messages' directly to the parameter, a parameter which is also mapped to a midi CC on the midi layer. So it theoretically has a range beyond that of midi CC's. Am i also correct that it is possible (with a bit of coding perhaps) to map that value coming from the pot analog input to midi CC to send out the midi output port on the core?

My second question is then if i were to try to implement a SMALL matrix style hardware bank like say the waldorf pulse, lets say with 4 knobs that do multiple things depending on the selection of another say analog switch between 4 rows (so 16 values in total)... if what i assume to be correct it can be coded so that the knobs can do 'quadruple' time so to speak and the midi CC messages that they send can be the appropriate CC for whatever 'mode' the user interface is in ? obviously dependent on a lot of coding but possible yeah ?

So third question, assuming that to be all good, is again, assuming i can write the code it's possible to make the knobs 'latch' like the original nord lead say, as obviously my example of the waldorf pulse used continous controllers, but if just using standard pots its possible to make it so the value doesn't change until the pot passes through the current parameters value so the value doesn't jump into its new position as soon as the pot is moved.

Sorry i know thats a lot of stuff but any help would be greatly appreciated... Thanks!

Advantage of using native hardware over external midi?
The 7bit, 12bit, 32bit thing
#2

quite a lot of questions, so perhaps easier if I explain some concepts which hopefully will allow you to answer you own questions...

midi objects vs parameter mapping.

when dealing with midi you have 3 choices.
- parameter CC mapping so that axoloti 'automatically' will update parameters (assuming mapped) on receipt of a given CC.
- use midi object (like midi/in/cc) to feed an inlet.
- parameter mapping via mod source, which can be a cc

the first, since its 'automatic' has to map the 0 to 127 range on receipt of the CC. this cannot be fine tuned, so is 'stepped' and uses the whole range
midi objects inserted into patch , output floats and we now support 14 bit midi, and how you interpret this and put into an inlet is 'up to you' so you can use reduced range etc, so the 0-127 may not be the limitation as its first appears
mod source, mod source_cc , is like the first approach but you can define a range (like an attenuator in a modular) , but like midi objects you need to insert an object into the patch.

the gpio, so your pots, can use the approach 2 or 3, but there is no parameter mapping.
so 'out of the box' with no extra coding, you would need to add objects to your patch.

parameters are all 32 bit, so that defines the ultimate range and resolution.
so gpio could be higher resolution, not higher range... but actually I think is limited to 12 bit, so 14 bit midi would be higher... though there are not many 14 bit midi controllers.
(update rate is tricky since midi is run in a separate thread, and is pretty high prio, I'd assume, but don't know if gpio is the same)

parameter mapping, if you don't want to be adding objects in the patch then if you know C, then you can also access and change the parameters directly from C. this is what I did with the Ableton Push (which uses relative midi encoding so is not limited to 7 bit midi resolution) .
Using this approach you could implement any kind of 'dynamic' parameter mapping you wanted, and also latch or any other mechanism you wanted. this code could be included as a 'controller object' so would be available for all patches you use.

so in answer to your questions, all you ask is possible, adding gpio objects to your patch to update other objects via inlets, or using mod sources is the easy solution (no C code required), but its also possible to do your own parameter mapper code ... its more 'work' and requires more skills, but means its possibly generic to all patches you write.

#3

Thanks for your reply.

My intention is to write my own parameter mapping code. I haven't used c++ before but have experience with objective-c on osx/ios and other languages like java & python, so i should know enough to get me there (and yes i'm well aware its gonna take some time to write my own mapping/UI code i like challenges!)...

Speaking of writing mapping/UI code i read other parts of this forum before your reply where the consensus was to 'outsource' this to another microprocessor/board like the teensy, which communicates to the core via midi. This seems like a slightly hacky implementation, but then again you did say that the midi in executes on a separate high-priority thread so maybe not so bad, but from what you confirm it's possible to implement all on the core and why would the core have gpio? on the board if it wasn't intended to be used this way?

#4

In case of a huge number of pots, going through midi makes such a setup nicely scalable, as Axoloti will only have to process changes, the microcontroller board will do the scanning and reduce the datastream to changes only. This maps well on parameters, parameter changes are event-driven.

GPIO analog input is 12bit, if you need to keep 12 bit (which can be really nice), it is better to not even try reducing the datastream to changes. A little noise will trigger change so often that it gets inefficient. This maps well on a control-rate value (blue) wires. gpio/in/analog does this. The firmware scans/converts all the gpio analog channels at 12bit at 3000Hz. This happens with little processor use, as the scanning, adc sequencing and memory transfer is without processor overhead after setup. But only 15 channels are available.

Nothing wrong with using gpio analog inputs if 15 channels is enough.

I'm willing to look into knob-hook behavior and bank switching, but you'll need some patience...

#5

Thank you for your input.

I will order my core shortly. My ambition probably exceeds my abilities at the moment, i have very little knowledge about the electrical side but i'm fairly comfortable with the sound/coding side so i know i'd be silly to go into this without a great deal of patience.

#6

Implemented, pushed to github and in the next release.