Not sure it's a bug or feature: it looks like the factory mpe object doesn't work at all when in a top-level patcher, whereas other midi objects do work fine. Normal, or am I missing something?
I'm testing with a Seaboard RISE and had to use the attached patch (with MPE subpatcher, polyphony = 1) to observe what this midi controller does.
Midi/ctrl/mpe not working in top level patcher?
jfcharles
#1
please see example patches.
It needs to be used in a polyphonic expression sub patche
jfcharles
#3
Yes, examples work fine. It's just surprising that it doesn't work at all in top-level, whereas midi/in/keyb works, for instance. That's ok, just a thing to be aware of. Thanks.
not really... MPE by definition requires multiple voices, and also encompasses a voice allocation strategy...
how would this work on a top level patch, which only has one voice?
(and if you have only one voice why would you need 'polyphonic expression' 
)
(I suspect it will 'work', if you set the midi channel of the main patch to the same channel as the note is coming in on, but remember, most mpe controllers are going to rotate channels, so thats really of no use!)
midi/in/keyb on the other hand is not voiced at all, it actually would be better labelled as 'midi note on/off', it merely takes any midi note on event and puts out the output.
this is why examples and help (which also exists for midi/ctrl/mpe) are provided, to give a 'template' to new users who aren't sure of how things are works.... just grabbing an object and assuming it will work in a a particular way, is not always going to be productive.
jfcharles
#5
Actually, I think it's very useful to observe in a main patch what a MPE controller gives you (actual range, etc.)
I was thinking that in a top-level patch, it would just behave like a sub-patch with polyphony set to 1. Indeed, it's not necessary to allow that since one can just make it (that's what I ended up doing for my tests):
observe-mpe.axp (6.8 KB)