Actually, packing an id before the actual data and using a route object to distribute all separate destinations from one single [receive] -> [route] -> parameters would do the trick. Maybe that's what you meant? I just cannot picture a [route] object with up to 500 outlets, yet.
But there might be ways to organize it using a small number of [receive] and a small number of [route] and sub-[route] objects. However, it would take just as much time to rewrite an existing patch like this as it takes to hardwire the sends. I still think that these considerations need to be made when starting to write any kind of code because problems only start showing up when it's almost too late. Once the patch gets kinda huge fixing will become very time consuming. Optimizing any code to the least amount of parsing data/messages around is the key for doing any complex patches. Ingo > -----Ursprüngliche Nachricht----- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Ingo > Gesendet: Freitag, 16. September 2011 16:42 > An: 'Claude Heiland-Allen'; pd-list@iem.at > Betreff: Re: [PD] pduino rewrite > > 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 > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
