(Internally) outputting polyphonic aftertouch supported?

#1

Hi!

I'm building a synth that should be controlled by analog in signals, each analog in controls a note, but I would like the note to be responsive to the continuous data flow (e.g. the amplitude of the note), not just note on/off.

I thought that it would be appropriate with in internal polyphonic synth that supports aftertouch data, i.e. each voice receives continuous data while the note is playing.
I see that there are "touch" supported midi inputs available for that, so far perfect! However, there seem to be no "internal" midi outputs (nor "outputs" btw) with this feature.
Am I overlooking something? Or is there an alternative way to send out aftertouch data or an alternative data format? (I know about CC data but that is not nicely accompanying a note though!)

Cheers!

Kurijn

Wishlist of objects
#2

good point...
we are missing channel pressure and poly pressure outputs for midi.
put it on the wish list, and I'll try to get it done, its a pretty trivial object

in the meantime, if you are so inclined you could easily adapt one of the other midi/out, all that is needed is to change the arguments to midisend3

#3

@Kurijn

Did you try the midi/ctrl/mpe object instead of the midi/in/keyb?

That one has got channel pressure.

#4

@jaffasplaffa

I think the only option to have continuous data flow during a note, is using aftertouch so poly pressure.

#5

ok, so a few things here.

first I think the discussion was about output, the mpe object only implements input.
Ive implemented output options for both poly at and channel pressure.

hmm, this is perhaps badly worded :smile:

CC/channel pressure existing continuously regardless of notes or not, but of course they are not attached to a note, rather the whole midi channel.
where as poly AT is specific to a note, and should be noted can even live outside a note gate... e.g. you can send a polyAT message for a note that is not currently ON... though this is not very common, so you may find your synth doesnt support it (axoloti doesnt really)

the issue for MPE, is that poly AT is the only message that can be be assigned to a note, i.e. its the only note expression,
whereas MPE want at least 3 expressions. pitchbend, pressure and timbre ... so its solution is to use a separate midi channel for each 'note' , and then send channel messages , in particular pitchbend, channel pressure, and CC 74.

of course this means its limited to 16 simultaneous touches, due to midi restrictions, but given most of us have 10 fingers thats not a big limitation, expect for notes with long release times. but a synth can be 'clever' here... once you have released a touch (note-off) you obviously cannot physical affect its pitch,pressure, timbre since you aren't in contact with the surface... so the synth can decide to only use PB,pressure/timbre for active touches.
of course, if two players use the same surface, bets are off... and they can only use 8 fingers each :smile:

#6

ok, I've been trying the new "midi/[intern and out]/poly touch" blocks (thanks btw!).
however, unfortunately I don't get them to work...
I've tried to simply send a number to note and then a 1 bool to trig with toggle. that works with the previous midi "note" blocks (when velocity is provided as well).
with the poly pressure ones:
-using the "internal" block and "midi/in/keyb touch" I don't seem to capture anything at all...
-using the "out" block and
* an external synth: I see that some midi information is received (by a led indicator), but no note is triggered.
* pure data: the "notein" block doesn't react, the "polytouchin" block indeed outputs the note & poly value, but the poly output is not continuously updating, it sticks on the value sent with the note on event.

Also important to note: while using an external midi controller with aftertouch I don't capture any data with the "touch" output from the "midi/in/keyb touch" block (and I am positive that the aftertouch of that synth works).

let me know if I can report you some more tests if needed.

cheers!
K

#7

it works ( or should) in the same way as midi/out/cc
that is, you need to send a rising edge trig to send each new value.

the most 'obvious' way to do this is to connect a change object to the trig input.

#8

AHA!
I got it now, it works! I have to use BOTH "note" and "poly touch" blocks!
The first one to actually trigger the note, the second to send note poly data afterwards...
Sorry, I'm not that known with this stuff!
Cheers!
K

#9

cool...

yes, poly pressure is independent of gate... if your synth supports it
so, for example, you could open up a vca directly using the pressure input, rather than driving a envelope (from gate input) to open the vca.
... but I will say its not that common for synths to support this , they tend to rely on note on/gate to drive env, but more (hardware and software) modular synths can do this.

you could do this in axoloti, though its a little more complex than it needs be, since the polyphonic subpatch allocates voices based on notes.

which gives me an idea :smile:

@johannes , do you think we need an extra voice mode for patches....
"free polyphonic" mode, this would just create voices, but every voice would get every voice message, it would be completely up to the (sub) patch to decide if it is going to respond to the message...
I can think of a number of uses:
- unison
- patches that want to do their own voice allocation (the can use polyidx as driver)
- patches that don't use midi ( ok, you can use poly already, but this makes a bit more obvious)

I think we should also have variants on some of the midi objects (or upgrade existing ones), that output the midi channel.

I do recognise you can do the above currently, but having the midi objects in the parent patch, setting the sub patch to poly, and then passing the messages as inlets.

#10

I'd try to avoid more "mode switches" where possible. Voice allocation is better expressed in code than in patching.
Modularizing voice allocators, it does not fit the current object model. It would be a cool feature, but I'm not convinced the "effort to added use cases ratio" is hot.