event-routing audio to poly~ instances

    Oct 08 2014 | 11:43 pm
    Hello everyone, I have a question about working with poly~ that I'm trying to figure out.
    So, in the tutorials for poly~, they show you how to cleanly manage your voice activity with muting and flagging voices as busy dynamically within the voice instance. This is usually controlled in a canned, timed fashion, usually by a pseudo-note message triggering a line segment, with the beginning of the note unmuting and marking the voice as busy and the end of the line segment's time muting the voice and unflagging its business.
    In another case, a noise~ oscillator is pumped into 16 voices. Using a looping counter, a center frequency is randomly set on a filter present on each voice (or something like that, can't exactly remember).
    My question is, if I combine these mechanisms with events that are generated from continuously streaming audio, is it possible for me to spigot off which voice I send a streaming instance of my MSP signal to?
    To break it down:
    - Streaming audio is always piping through the system, so it is always audible through one poly~ voice. - Every time an event generated by amplitude tracking the input audio stream happens, the two channels of the stream switch which voice they're pointed to. - As would be normally expected by something using poly~, each voice has its own release envelope from other effects processes inside of it that independently mute and free up that voice.
    Can I use some combination of gate~ and poly~ to re-route in this way?
    Anyone have an idea?
    Thank you!

    • Oct 08 2014 | 11:45 pm
      My current suspicion is that I will have to abandon using poly~ altogether and just have redundant instances of the same MSP subpatcher aimed downstream from a gate~ object.
    • Oct 09 2014 | 2:49 pm
      my personal, general advise would be: more complex "control" things should alyways be built outside the poly patcher. you can easily become mad if you try it inside.
      gate~ and selector~ are for sure helpful objects to build something like that. it could also make sense to use [prepend bubu] and [route bubu] wiht your signals, then you dont need to have 32 signal inlets to your poly patcher.
      and dont forget that a muted poly voice can not be turned on by a signal, because it does not see it. :)
    • Oct 10 2014 | 9:54 pm
      I'm not sure how I would create a poly~ed subpatcher with ex. 32 inputs and not have these inputs pipe active signal into all of them, though? For now I've moved on to having 10 permanent instances which get signal piped into them by gate~.