Let's have a sharing thread -- "things I wish somebody had told me when I was first starting with Pd."

My #1: Basic list operations of iteration and incremental "fill." It took me probably half a year to discover the [list] operators and be able to use them reliably for these two absolutely essential procedures. (It turns out that these operations aren't so difficult after all, but it took far too long to figure it out.)

hjh

Oh wait, I get it -- it's not the order of object creation; it must be the order of connection creation. And I'm pretty sure I had followed the video and used fan-out to make the connections.

In that case, fan-out is not following right-to-left -- if I had shift-dragged to the leftmost number box, it's probably making that connection first and filling in the others later. That would explain why t would be hitting the left one first.

EDIT: Confirmed, that's exactly it. If I shift-drag to the rightmost target object, then the connections are created in right-to-left order, and "triggerize" then accurately reflects that order. (So then the issue is that the video models the behavior of shift-dragging to the leftmost object, without explaining that this will give you a connection order that you didn't expect.)

hjh

I'd like to add to this that, after 1 and 1.5 years, I think I finally turned the corner on pd methodology. Today I was able to load multiple soundfiles into numbered arrays (by index, [array$1() and save the file size and sample rate in a [text] for retrieval at playback time, and without a lot of the false steps from a few months ago. That's been a long time coming.

That's a long way of saying thanks for the help over these months -- I complained a lot. I'll complain less about pd methodology (though there's still a lot of room to complain about documentation...).

Thanks again for patience and assistance --

hjh

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

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.