Some head scratching around how to, achieve Polyphonic Multichannel, could not found any reference, but got it in the end
There is also a typo 
(attribute?)
So to work: subpatch set to (View-Settings) Polyphonic Multichannel - tick - Has MIDI channel attribute to get this
if not, its only Polyphonic
nice;-)
Haken Continuum still has no mpe specs; going thru EigenD?… next step
Ok, so this is voice per channel ( poly multichannel)
If you don't have midi attribute checked it should be 1-16 ( actually based off midi channel in patch settings)
Is it not working like this?
(I've not checked yet)
MPE is enabled by using polyphonic expression.
ok, just check, and its working as expected, i.e. you do not need attribute.
here is a simple working example
(you'll note I use patch/patcher so I can embed the voice in the patch... makes editing much easier... but it works identically to subpatches... i.e. this is not the reason it works)
vpcexample.axp (7.4 KB)
notes:
(oops, screenshot shows voice named patcher_1, because i forgot to reopen it after renaming it to voice in the main patch, sorry for any confusion)
Great @thetechnobear !! Will dive in later tonight (all week at the Theathre new show on the weekend)
What else to add; works nicely
There is lots to grasp (and this is leaving EigenD/mpe out of equation) this one more example is very welcome.
Notice you removed all other options ?
Number of presets/Entries per preset … etc. unrelated
Cool
No removing presets is not related
However, I'm now doing this out of habit, as it can significantly reduce memory use in larger patches, and it's easier to remember to do when you create the patch than going through the all later.
I even think we should have this as the default, so you have to explicitly size the presets when you need them. But not sure @johannes will agree as potentially the user will forget.
Ideally the UI would be dynamic , such that the user could easily see if (and how many) presets were available.
Had this written but somehow did not press send…
Yeah have discoverd that also even cpu usage, and what about modulation targets and sources??.
Presets are very handy (remember I have this on G2 
with some patches just two with others more, maybe 4 is average. "User" has just one more thing to "gamble" with.
Thanks for taking the time with mpe @thetechnobear - just got into it myself an facing some challenges with the linnstrument.
Is velocity not recognized by the axoloti object? I still would prefer to strike the keys to open an adsr and have the velocity set the gain of the sound and then perhaps use the pressure for some vibrato or something.
I think there is some issues with the USB datarate on the linn and axo, so I am just using the DIN midi and that might be too slow for pressure heh - if i strike keys, then you get some glitching with the pressure opening up the envelope - I assume because pressure is calculated over longer time than velocity.
As for the rest of the stuff, it seems to work OK.
sure, as far as i know velocity is working with the mpe objects...
I just happen to code up the mpe synths using pressure as gain, as its my preferred approach, I like to play the envelope
someone else has issues with the linnstrument and the usb, but unfortunately, there is just no way for me to test it... so I cant really think why it would be an issue.
(as far as I could tell, the usb host port was just not getting complete messages)
perhaps axoloti is not able to process the usb messages fast enough, but thats a a big assumption. I think @johannes was talking about a possible interrupt storm, but Ive no idea how to prove this, or fix it.
the odd thing about all of this, is when I connect my soundplane and eigenharp to the computer and send the data via the device port, i don't have any issues with data rate (I'm sending data at about 500hz).
so it does seem like this is an issue that is specific to the usb host port
its more likely, that the quantity of messages over the DIN is just too much, so its possibly jumping between values. over DIN you would likely have to throttle the data rate on the linnstrument end.
thanks for the response. was just playing with pitch and the gate connected and that was already pretty fun. more tests tomorrow!
Hi Mark! Just realized who you are . Anyway, I just looked at KEYB.axo and saw that it is a tad different with _velo and _rvelo compared to MPE.axo . I've changed the values for the outlets to be defined in the krate and it seems to work fine over here now - double checked and velocity wasnt working correctly with the linnstrument with MPE.axo when compared to the version that had these adjustments.
So in the midihandler if statement, _velo and _revelo are just data2 now, and in the code.krate section i put the data2<<20 part.
hopefully pressure still works hehe, will check.
ah, sorry, the code was the same original, and id assumed it had stayed that way, could be a fix was applied to keyb that didnt make it to mpe, I'll take a look...
(nice thing is with the libraries (1.0.8/9) , I can now push changes to fix objects mid release cycle )
man this is so cool 
i do have some issues with the way pressure works (striking keys seems to communicate that there is 0 pressure). might be the code might be the speed of the messages..not sure.
I am using DIN midi btw..not sure whatsup with usb acting funny on the axo but not really important right now in my adventure.
ok, velocities are now fixed in 1.0.8 and 1.0.9 (sync libraries to pick up)
pressure, this is probably a corner case of MPE 'standard'
how I handle pressure is...
I only take pressure from a controller that is explicitly sent as channel pressure (per mpe spec)
one thing i do however do is set pressure to zero on note off, even it its not sent.
as I believe, personally, if its a note off, then you have removed your finger, so you can't be applying pressure BUT i know some controllers don't send this (a bug in my opinion) ... and this makes patching more difficult (i.e you have to work with both gate and pressure, rather than sometimes just rely on pressure.
so what this means...
is although I dont set pressure explicitly to zero at note on, it will be zero until the first pressure is received.
why not just use the note on data 2 value for pressure.... because velocity is NOT pressure, they are two different metrics and as such are unrelated... i.e. you should be able to strike a note fast (velocity = 127) but it still be a light pressure (say 30)
velocity should be calculated as dP/dT , for a defined set of samples... where pressure is P
I also assume (/expect) a controller not to send pressure before the note_on, as you would not know what pitch to apply (if relevant e.g. because your activating a oscillator attached to a VCA controlled directly by pressure)
soo... it could be the linnstrument, may have different assumptions (and unfortunately at the moment with the MPE spec, thats pretty much all it is... its still quite loose in some areas) OR... it could be as you say, something to do with the messages not getting thru. (the note_on should be followed almost immediately by the first channel message in my opinion)
yeah not much I can do about the USB thing... if its an interrupt storm then its really in johannes area, and given neither of us have a linnstrument, I'm not sure we can do much about it.
what i will point out though, is for me, the eigenharp and soundplane both work, it I host them on the a PC, and then send them to axoloti that way.
(my current project is to change this, so that they are hosted on a Beaglebone black/RaspPI2, so again the data will come via the device port, rather than being hosted)
I think i can just do a mix of velocity and pressure via patch..i dont know yet, but will figure it out!
thanks.
yeah, that really patch/sound design
please share what you come up with, I've not had alot of time recently for this, but do intend to do some patch design in this area... axoloti is fairly unique in this area, and I think we could create some really fantastic patches for mpe controllers.
btw, another tip, Ive found mpe controllers vary quite a bit in their scaling/curves of Y and Z... this is actually quite fun, as patches react differently on say the eigenharp/soundplane/continuum ... but you might want to allow some tuning on these parameters if you want to share them
anyway, have fun
