For me it would be the use of variables [v myVariable] instead of send/receive to floats.
Or this https://forum.pdpatchrepo.info/topic/13166/querying-whether-an-array-exists-or-not/17
-
"Things I wish I had known when I started Pd"
-
You can call abstractions with paths.
[dirctory/abtraction]
, even absolute paths[/home/oid/Downloads/abstraction]
and things like~
for home and..
for parent directory are honored. -
Bringing this thread back for one that just bite me good, that there is no certainty in which order [receive} and [value] objects get what you send them. While I knew this, I did not understand it, I just seriously broke a massive patch with a minor edit and every attempt at fixing it just breaks things worse, While using [send], [receive] and [value] can make for a neater patch, over use of them can cause problems since they do not let you see creation order.
-
@oid said:
Bringing this thread back for one that just bite me good, that there is no certainty in which order [receive} and [value] objects get what you send them. While I knew this, I did not understand it, I just seriously broke a massive patch with a minor edit and every attempt at fixing it just breaks things worse.
Oh yeah, that's a good one.
One [s] - multiple [r] is analogous to multiple cables coming from the same outlet. The rule of thumb that I taught in class a couple of weeks ago is -- if all of the cables or [r]s are going to cold inlets, then it's probably OK, but if any of them is hot (even one), better use [t]. E.g., in the scheduler abstraction I posted some days ago, there's one [s $0-tempo] and two [r $0-tempo]s (one for a [delay], the other for a [timer]). This is OK because "tempo," for delay and timer, updates state and doesn't trigger output (= cold). But if there's output, then I guess for safety I would have to [t ...] and have multiple [s]'s with different names.
I hadn't thought of the case of multiple objects sending to the same [value]. I can see ordering becoming thorny. (Incidentally, I added a [getvalue] into my abstraction set which will pass only "bang" into the [value] -- particularly for my sound file abstractions, the [value] objects should be read-only!)
hjh
-
@ddw_music Sending to {value] is really what got me, they were getting their bangs before their new values arrived. I I had just copied part of the patch into a sub-patch to clean things up, this moved that bit to the end of the patch and caused the problems. If I had realized what had happened earlier I would have just moved the sub-patch in a text editor but I tried to fix things in pd and made it a hopeless mess. I have now adopted using sub-patches to structure order creation and using wires between them for all timing critical information, this means I can edit the subpatch and keep everything in that sub-patch in the proper place in the chain regardless of my editing. I knew about the order creation for sends and receives and the patch worked perfectly before that edit which changed nothing about the physical patch, I just did not understand the long term consequences and what would happen when I change things a year down the line. Wasted a few hours and ended up redoing the patch from the ground up, but it is greatly improved and more robust regarding minor edits years down the line breaking it and even if they do I will only have to deal with a small subpatch as I no longer have all the sends to communicate between the sub-patches. Lesson learned.
-
(slightly OT) I think [send], [receive] and [value] having settable order would be cool but I don't know how difficult it would be bc it's integrated w/ the symbol table.
Maybe it would be doable w/ some proxy.. then the proxy can get the symbol receive and send it to all of the same receive name objects in the right order. -
@oid Yes..... a common problem.
The most complex patch I built contained this to maintain the order and keep my hair on my head.
David.