Open Dewb opened 11 years ago
I've been thinking and thinking on how to do this generically but without sacrificing performance in the render cycle. There are way too many details to write here but i would love to chat on this when I am back from wwdc.
On Wednesday, June 12, 2013, Michael Dewberry wrote:
This would make polyphony a bit more elegant, and would probably open up some more use cases that I'm drawing a blank on right now. See comment thread in #178 https://github.com/TonicAudio/Tonic/issues/178.
— Reply to this email directly or view it on GitHubhttps://github.com/TonicAudio/Tonic/issues/183 .
Nick Donaldson ndonald2@gmail.com
See also #169
I think this is really useful feature but I'm not sure cloning entire generator graphs is the best approach to make polyphonic voices. The main issue is that any new connection you make inside a polyphonic voice has to be made for every single voice copy. Maybe something in Tonic handles this but I've found in my own (non complete) development that it is better to copy all the Generators but have them use the same graph. Then you can make one change in the graph and all the voices use the new data flow.
Then again, the complexity and possible confusion of having multiple Generators use the same graph might be worse than the alternative of just updating every single voice in some voice handler.
Also, I'd like to join in this discussion if you let me know ahead of time.
Unfortunately that that isn't really how Tonic is architected. One generator or generator graph simply can't drive multiple voices - the output of each generator is synchronous. Especially for filters since they have state; I'm not really sure how a single filter could ever be used in multiple voices.
Happy to talk on this more sometime. Maybe it would be good to have a Tonic architecture talk for anyone interested.
On Friday, June 14, 2013, Matt Tytel wrote:
I think this is really useful feature but I'm not sure cloning entire generator graphs is the best approach to make polyphonic voices. The main issue is that any new connection you make inside a polyphonic voice has to be made for every single voice copy. Maybe something in Tonic handles this but I've found in my own (non complete) development that it is better to copy all the Generators but have them use the same graph. Then you can make one change in the graph and all the voices use the new data flow.
Then again, the complexity and possible confusion of having multiple Generators use the same graph might be worse than the alternative of just updating every single voice in some voice handler.
Also, I'd like to join in this discussion if you let me know ahead of time.
— Reply to this email directly or view it on GitHubhttps://github.com/TonicAudio/Tonic/issues/183#issuecomment-19481734 .
Nick Donaldson ndonald2@gmail.com
I don't think I said what I mean right. I meant you could copy the Generators so each voice has a separate filter with its separate state, but the inputs and outputs are all shared. That way when you connect an input to an output, all the generators see the change. A caveat of this is you need to run each voice fully before you start running the next one because they all use the same data stream.
I'm not sure this is possible to do in Tonic without large changes, or if you even want to have shared inputs and outputs for architectural reasons.
And I would definitely attend a Tonic architecture talk.
Ah yeah, now I see what you mean. We actually haven't worked out dynamic input patching quite yet so I definitely think some sort of grouped patching mechanism is worth considering.
I will keep an architecture talk in mind. Possibly sometime later this summer would work for me.
Cheers!
On Friday, June 14, 2013, Matt Tytel wrote:
And I would definitely attend a Tonic architecture talk.
— Reply to this email directly or view it on GitHubhttps://github.com/TonicAudio/Tonic/issues/183#issuecomment-19483285 .
Nick Donaldson ndonald2@gmail.com
This would make polyphony a bit more elegant, and would probably open up some more use cases that I'm drawing a blank on right now. See comment thread in #178.