Hi Claude,
When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it
is). [snip]
Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check
whether
the message was meant to be for them or not.
[snip]
The second fix was to replace the wireless sends with hard wired patch chords.
Faced with this scenario I would probably have tried dynamic sends, so the data determines which receive gets the message.
For example:
... | [pack f f f f f f] | [ ; r-$1-$2-$3 $4 $5 $6 (
[r r-1-4-7] | [unpack f f f] | ...
[r r-27-63-49] | [unpack f f f] | ....
That would imply that you know which midi CC message gets there when since the left inlet of [pack] needs to be banged. Or it would be delayed until the left inlet receives a new message (if at all). Or you would have to bang the left inlet every time another one comes in. That would even multiply the data transfer. Last solution would be a fixed send timing every couple of milliseconds. That would multiply the average data transfer and lower the timing resolution.
And using nested abstractions you could create the receives based on $args
$args have to listen to all sent messages also. You are simply expanding the name with the $arg. When you have 10 voices all [receive]s of all 10 voices will have to listen for every [send] message to determine whether it is for them or not. Doesn't matter if the name starts with "$0-".
and if you need lots of voices you could use dynamic patching to instantiate them.
To initialize sample-voices like the ones I am using Pd takes about ten seconds. If you want to play a piano chord that has one note more than current voices are present you don't really want to wait 10 seconds, do you? And afterwards are you going to erase that voice again? This would again interrupt the audio stream.
Anyway audio calculation can be turned off with the [switch~] object. [receive] objects cannot be made inactive ever. The only way to do this would be to split up the voices over several independent patches which communicate over [netsend/netreceive] or [osc]. This makes audio communication very difficult and it would be very hard to keep all of those thousands of tables updated in all patches.
It's just simply more efficient to address the data directly by wired connections only to the destination that needs the data. Looks messy but works better!
Ingo