@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.
-
"Things I wish I had known when I started Pd"
-
@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.