tackling poly~ and this poly~
I have moderate succes trying to tackle poly~ ( it's a lot more confusing compared to pd clone~ )
For some reason the makenote into pack is not providiing enough information ,I need to append it with a midi format module and use the rightmost outlet for poly~ , thispoly~ to work
Is the prefix midievent 144 (which is part of the midiformat message ) so important for thispoly~
After all it just needs mid pitch data and velocity and gate on-off
just use [prepend note] after the [pack]
it is confusing because nowadays there are 3 or more different methods.
when you build something more unorthodox and when you do not require to have standard functionality such as intelligent voice stealing, you can limit yourself to the "target" message, which means that you control the "voice on" messages from outside the poly.
I just want to know why the midievent 144 is so important for poly~ to function properly .
Is it because I am using a liveadsr ~ , ?
Why is unpacking a makenote not sufficient ?
it's utterly confusing
it is the poly~ object itself which understand this kind of messages and does the voicing with it.
(maybe you remember my post from the midievent thread: it first was present only in vst~, and only there is it mandatory.)
poly~ would also understand "target 3, 60. 0.7".
The help files and reference are really a letdown
There is no mention if target value $1 should be send as a list or separated by , like target 0, $1 or 0 $1
The poly~ reference says this-
The poly~ instance that will receive subsequent messages (other than messages specifically used by the poly~ object itself) arriving at the poly~ object's inlets - for example, The message target 2 routes messages to the second instance
A subsequent message would be another message. So send "target $1, my subsequent message". The "voice messages" tab in the poly~ help has an example with a target message hooked up to it.
More recently they added the "setvalue" message where you can target a specific poly~ instance with a message. This is similar to mc~ objects.
it is basically like setting a gate via its control inlet. once the target is set, stuff goes there.
I got the hang of it
What works best (for me at least ) is send the target message to the left inut , and controls to their inlets
Target 0 will controll all voices and you can do some parameter style locked effects when choosing another target and adjusting appropriate parameter .
Powerfull feature !
Only downsde is that it's not really clear whcich voices have been altered after you have tweaked a few of them
And now all of a sudden the mc. target to target individual parameters makes complete sense to me .
It's amazing for fm duties when used on envelope settings
yes indeed, sometimes you need to know something about voices state or activity and then you have to "remember" all of that outside the poly.
it can help to have all the target numbers (for voicing but also the zero) in one place (as int), then you can attach a [change] before a [prepend target] to reduce data.
One trick I learned is that you can bind pattr objects in a poly to the parent patcher using something like [pattrmarker top] in the parent and then [pattr @bind top::my-ui-object] in the poly~. Then the state of the poly will always be in sync with the pattr object in your UI. Even on reloads!