@ddw_music

it's painful when you have to add an outlet in the middle of a t object. Really awful

This is where your intelligent patching comes in handy. Select the trigger, control+k to disconnect it, add the outlet, select the trigger and all the objects it connects too, drag a wire from the first outlet to the first destination, hit shift, release, connect the inlet, done. You can also get things to patch in different orders by going from different outlets to different destinations. It helps to get in the habit of not making massive triggers with 32 bangs, break it up, also ordering your patch to reflect the trigger will make the intelligent patching easier and more predictable, the object the first outlet goes to is right beneath that outlet and the object the second outlet goes to is beneath it and so on, sometimes it can not be helped but a [t a] can be placed to help keep order and bend wires when needed.

Sometimes things which are painful in puredata are relatively simple if you just open the patch in a text editor or use the various command line tools like grep, sed, bash, etc.

@oid

OK, the videos are helpful, thanks. (Although -- vimeo positions its playback bar right over the mouse and key icons -- so it's a little difficult to read.)

Maybe some of the interface has changed? Fan-in and full connect are shown in the first video (0:30) without using any modifier keys, but I found that they need shift.

It helps to get in the habit of not making massive triggers with 32 bangs

I've never done this. I would push things down into subpatches long before reaching that point.

also ordering your patch to reflect the trigger will make the intelligent patching easier and more predictable, the object the first outlet goes to is right beneath that outlet and the object the second outlet goes to is beneath it and so on

I would guess that I'm more fastidious than most about lining up connections. Patchers are already less readable than code -- arranging them poorly makes them impossible to work with.

Related to that point about ordering the objects: Why does ctrl-t connect the rightmost outlet to the leftmost inlet? Can't think of even one time I would have wanted this.

hjh

@ddw_

Related to that point about ordering the objects: Why does ctrl-t connect the rightmost outlet to the leftmost inlet? Can't think of even one time I would have wanted this.

Never having used the shortcuts that surprises me too.
Is it an admission that for English speakers the right to left order is not intuitive?
Or is it because of the order of creation of the number objects?
David.

@ddw_music If you move the mouse cursor off of the video the playback bar should auto hide and clear your view. I have no idea about ctrl-t on fanned out connections, there must be some sort of logic, can not believe this has just been over looked for all these years. There is also a "less intelligent patching" video for when you have issues with pd trying to be too smart with the intelligent patching, don't recall what all was in that one, but perhaps it deals with this quirk and it is just pd being too smart. It is in the 'made with pd' section of the pdpatchrope.info main page or can be found with a google search.

@whale-av said:

Never having used the shortcuts that surprises me too.
Is it an admission that for English speakers the right to left order is not intuitive?

Right to left is an easy rule to learn (which follows easily from the principle that left inlets are more likely to be hot, though Max breaks this rule in places).

What surprises me is that it's a nearly ubiquitous rule but this editor feature violates it.

Or is it because of the order of creation of the number objects?

The video shows the same strange behavior. That would be a remarkable coincidence if I had accidentally created objects in the same order as the video... But I might be retest with different orders later.

With the information available to me now, it looks like a bug.

@oid: "there must be some sort of logic, can not believe this has just been over looked for all these years"

The same behavior is plainly visible in the video, so it's been overlooked for at least as long as that video has been published.

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.