Hi,
I wonder if there are some differences between cord and wireless messages to deal with musical events (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
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.
The $0 would be the "private" attribute for example. In practice, I mixed local and non-local variables inside patches, but if I would like to change the name of messages, add or delete them I need to look inside every abstractions and edit each. I wonder if there is good tips about that.
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 hope it is clear.
Thx,
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
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.
Another solution here would be to put the ID numbers inside the send and receive objects. Ie this in the parent:
|
[t b f]
| |
| [makefilename %d-channel]
|
[send]
and this in the abstraction:
[receive $1-channel]
Le 05/01/2017 à 12:48, Liam Goodacre a écrit :
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.
Another solution here would be to put the ID numbers inside the send and receive objects. Ie this in the parent:
| [t b f] | | | [makefilename %d-channel] |
[send]
an other solution is to use the new [clone] object. You can do things like this very easily, and i think in an optimized way.
cheers c
and this in the abstraction:
[receive $1-channel]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
cyrille henry -
IOhannes m zmoelnig -
Jérôme Abel -
Liam Goodacre