[PD] pduino rewrite

[Ingo]

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