[PD] Send/Receive topology design

IOhannes m zmoelnig zmoelnig at iem.at
Thu Jan 5 10:08:18 CET 2017


On 2017-01-05 09:54, Jérôme Abel wrote:
> Hi,
> 
> I wonder if there are some differences between cord and wireless
> messages to deal with musical events (synchro issues).

what are "synchro issues"?


> 
> Do you know if it is better to have :
> - [r NOTE]-->[route $1] objects inside 50 abstractions
> - or only one [r NOTE] --> [route 0 1 2 3 4 5 6 7 8 9 10 .... ] and
> cords to these 50 abstractions


the former is easier to patch. the latter will perform slightly better.

in most cases i would go for the more patchable solution (unless you are
sending a **lot** messages to a **lot** abstractions).

> 
> In term of design it is quite difficult in Pd to find the best way of
> communications compared to classical programming with "private",
> "public", "const" attributes range of variables.

i know quite a number of (what i consider) "classical" programming
languages that don't know anything like "public" or "private".

the good news with Pd is, that mostly you don't have any variables at
all (and therefore you don't have to deal with their peculiarities).

i found that it's best to "avoid" [send]/[receive] altogether and use
explicit connections whenever possible.
this evades *all* problems you might have with locality.
it also allows you to avoid all problems related to order of execution.

for practical (patching) reasons, you might still end up using [s]/[r]
(at least I do).


> 
> I feel like every messages concerning the functionnalities of an
> abstraction could be local '$0' connected only with the first upper
> level. I wonder if cascading [receive] and [route] objects would be less
> efficient than connecting once objects together but compute them 50 times.
> 

i'm sure i don't understand this last sentence.

fsdm
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170105/ff7a5528/attachment-0001.sig>


More information about the Pd-list mailing list