Hi, it seems common practice to use route to dispatch individual "notes" to different voices when building a polyphonic synth. But these days I'm working on a "synth" which is going to have a large number of voices (probably around 100) and I was wondering if there's a better way to route those voices other than use route with a hundred creation arguments. I though about sending every "note" information (including the voice number) to every voices and to put a test at the inlet of every voice abstraction to filter the incoming data so that only one voice actually plays the "note" but I was wondering if there was a better option, like dynamically set the destination of a send object... I did a few test but couldn't find an elegant solution by myself. Many thanks pd-list! Benoît Fortier 581 995-5622
Here's an example from my class (14-poly-routing.pd) for how to deal with this. Hope it helps
On Fri, Mar 27, 2015 at 5:56 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Hi, it seems common practice to use route to dispatch individual "notes" to different voices when building a polyphonic synth. But these days I'm working on a "synth" which is going to have a large number of voices (probably around 100) and I was wondering if there's a better way to route those voices other than use route with a hundred creation arguments. I though about sending every "note" information (including the voice number) to every voices and to put a test at the inlet of every voice abstraction to filter the incoming data so that only one voice actually plays the "note" but I was wondering if there was a better option, like dynamically set the destination of a send object... I did a few test but couldn't find an elegant solution by myself.
Many thanks pd-list!
Benoît Fortier 581 995-5622
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/28/2015 12:28 AM, William Brent wrote:
Here's an example from my class (14-poly-routing.pd) for how to deal with this. Hope it helps
altenatively use a global receiver and prepend the synth ID in the actual message.
e.g.
[3 note 64 127( | [s synthctl]
and your synth is instantiated as [synthabs 3]: [r synthctl] | [route $1] | [route note] | [stripnote] | ...
i often use [route $1 0] (and merge both), so i can address each node individually (via it's id) and ALL (using the special ID "0")
fgmsrd IOhannes
Thanks everybody, that’s what I was looking for! After I’ve done a little bit of clean up, I’ll share an abstraction which works pretty much like poly but which detects note off by receiving, in it’s right inlet, voice numbers that are no longer busy.
One question out of curiosity IOhannes : I thought of your solution but it felt to me like there was something wrong with it because it uselessly sends data to many many voices. Is my feeling justified in any way, or should I just chill out?
Benoit Fortier
Le 2015-03-28 à 03:40, IOhannes m zmölnig zmoelnig@iem.at a écrit :
On 03/28/2015 12:28 AM, William Brent wrote:
Here's an example from my class (14-poly-routing.pd) for how to deal with this. Hope it helps
altenatively use a global receiver and prepend the synth ID in the actual message.
e.g.
[3 note 64 127( | [s synthctl]
and your synth is instantiated as [synthabs 3]: [r synthctl] | [route $1] | [route note] | [stripnote] | ...
i often use [route $1 0] (and merge both), so i can address each node individually (via it's id) and ALL (using the special ID "0")
fgmsrd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/29/2015 03:14 PM, Benoit Fortier wrote:
One question out of curiosity IOhannes : I thought of your solution but it felt to me like there was something wrong with it because it uselessly sends data to many many voices. Is my feeling justified in any way, or should I just chill out?
this really depends. i personally favour approaches where "voices" are as autonomous as possible. that is, you don't need to split the implementation of the voice assignment stuff into both the "voice" and the "orchestra" (the containing patch).
my solution might be slightly less performant, but in reality i wouldn't expect any problems with todays hardware (we are talking about 100+ voices on a 2.5GHz mobile phone; if you manage to eat your CPU cycles, than it's most likely not because of excessive use of send/route).
and really using per-voice send-labels has its drawbacks as well (cluttering the symbol table; does a global broadcast of the message just like the other solution (but fewer listeners)).
so i would say: in practice, your feeling is not really justified.
gfmdsar IOhannes
Hi Iohannes, in a discussion we had a while ago you mentioned (see below) : "and really using per-voice send-labels has its drawbacks as well (cluttering the symbol table; does a global broadcast of the message just like the other solution (but fewer listeners))."
I've been wondering lately : what are the consequences of cluttering the symbol table? When do I have to start worrying about it?
Benoît Fortier 581 995-5622
Le Dimanche 29 mars 2015 9h45, IOhannes m zmölnig <zmoelnig@iem.at> a écrit :
On 03/29/2015 03:14 PM, Benoit Fortier wrote:
One question out of curiosity IOhannes : I thought of your solution but it felt to me like there was something wrong with it because it uselessly sends data to many many voices. Is my feeling justified in any way, or should I just chill out?
this really depends. i personally favour approaches where "voices" are as autonomous as possible. that is, you don't need to split the implementation of the voice assignment stuff into both the "voice" and the "orchestra" (the containing patch).
my solution might be slightly less performant, but in reality i wouldn't expect any problems with todays hardware (we are talking about 100+ voices on a 2.5GHz mobile phone; if you manage to eat your CPU cycles, than it's most likely not because of excessive use of send/route).
and really using per-voice send-labels has its drawbacks as well (cluttering the symbol table; does a global broadcast of the message just like the other solution (but fewer listeners)).
so i would say: in practice, your feeling is not really justified.
gfmdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Benoit, you might be interested in the UPP infrastructure. http://grrrr.org/research/software/upp/ I put up a couple of examples, the whole thing will also be on github shortly.
gr~~~
-- Thomas Grill http://grrrr.org
Am 27.03.2015 um 22:56 schrieb Benoît Fortier benoitfortier@yahoo.ca:
Hi, it seems common practice to use route to dispatch individual "notes" to different voices when building a polyphonic synth. But these days I'm working on a "synth" which is going to have a large number of voices (probably around 100) and I was wondering if there's a better way to route those voices other than use route with a hundred creation arguments. I though about sending every "note" information (including the voice number) to every voices and to put a test at the inlet of every voice abstraction to filter the incoming data so that only one voice actually plays the "note" but I was wondering if there was a better option, like dynamically set the destination of a send object... I did a few test but couldn't find an elegant solution by myself.
Many thanks pd-list!
Benoît Fortier 581 995-5622 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Benoit Fortier -
Benoît Fortier
-
IOhannes m zmölnig -
Thomas Grill -
William Brent