hmm, I think I would 'avoid' have the voice management know anything about envelopes or even gates.
(voices are not necessarily always used for such things)
Ive another idea... which actually is based a little on the Max/Reaktor models,
polyphonic inlets and outlets
(this would not replace the current mechanism, at lease initially, it would sit alongside, and be used with patches marked as polyphonic)
this would be similar to normal inlets, except the 'outside' can address individual voices.
this is like Reaktors toV object, you give it data and a voice, to target a specific voice.
inside the subpatch, these polyphonic inlets, are seen as monophonic.. so no change there.
(in someway this is getting a little like reactors model, the subpatch is marked as polyphonic, and some wires are conceptually polyphonic)
for backwards compatibly we keep existing midi polyphonic behaviour, and the default behaviour of a monophonic outlet to a polyphonic inlet is to copy the data to all voices.
well this is actually the reverse, currently what happens to outlets of polyphonic modules depends on type e.g. data is summed... but it would be nice have some control of this...
Im thinking here of an object like fromV
what this does is take a polyphonic outlet, and a voice index and has a monophonic output.
thus allowing the parent patch, to be able (with multiple fromV objects, or a selector) take apart the various outputs.
(the default behaviour of a polyphonic output into a monophonic input, is the current behaviour e.g. summing)
what does this mean?
well it means we don't actually needs allocators at all, instead like Reaktor/Max , we just provide a mechanism for patch writers to access voices directly i.e. write there own allocator.
because its 'separate' from voice allocation, they can live side by side (at least initially, we may review in time) - which means compatibility.
its very generic, no assumptions about what a voice is used for.... e.g. its not even assuming the voice is used for audio, it could be anything.
(it would also fit nicely if in the future we make midi data type, as that could then feed in/out using polyphonic inlets/outlets)
I also think its quite simple to implement
(simple) example of use:
so a user whats a simple polyphonic patch, with note and date input via midi... but wants to take control of how the midi gets translated to a voice
a user creates a sub-patch with 2 polyphonic inlets, note and gate... they may also have mono inlets, eg. for filter cutoff control.
in the parent patch, they have an object with a midi handler , that looks at the midi data directly... selects a voice , and then puts the note and gate data on that specify voice inlet.
there is a question about if this can be done only as a custom object or also as patching.
a custom object is the most efficient, since its the only way to do conditional behaviour
BUT we can also have a patching objects.
this basically would required that the user would (potentially) need to a patching object (toV) for each voice they want to target , the toV object takes a voice id and a data value (so one for each data type), the voice id can either be fixed (using const/i) or derived. the output is a polyphonic output to connect to the polyphonic inlet of the subpatch. using a dynamic value for toV obviously means its only possible to set one value per 'k-rate cycle' or midi handling cycling.
(visually , we should differentiate poly inlets/outlets and wires from mono equivalents... perhaps like a 'double line', as its 'thicker' coz its got more data ?)
one other option object developers have, is to write polyphonic outlet objects...
e.g. one could write a polyphonic midi/in/keyb this could then directly be connected to polyphonic sub patches.
(this is exactly the approach Reaktor takes)
(sorry the above perhaps is not as clear as it could be, but if it has interest then we can dig into details, and I could make some drawings to clear up any confusion.
but to be clear, its not too dissimilar to Reacktor toV/FromV , an in alot of ways the way poly~ is used in Max when you give it a voice number... so reading those will probably make it reasonable clear)