Counter Patch Confusion
Attached is counter.pd , which implements an iterative loop. However it doesn't work as I expected. When started with the bang, the Count value inits to the Max rather than the Init value, and then counts down to the Init value.
I don't see how the Count value would decrease at all, since the only active operator is [+ 1]. And I don't see why the Count would not be inited to the Init value, or how it is inited to the Max value, or why its counting would stop at the Init value.
Here are some counters that should help.
There were some execution order problems with the counter you posted. A trigger object solved the problem.
Those patches are interesting, and I'm examining them.
But can you explain why my patch behaved differently from what I expected? Specifically what order of execution is causing, for instance, the value to decrement, when there is no decrement operation in any order?
It's because you connected the [print] after the [+ 1]. The connection placed first will be computed at first as well.. So recreate the [+ 1]-connection or use a [t f f]..
You have created an infinite loop that usually can produce stack-overflows if you don't stop it beforehand. Just change the [5( to [500( or so, to see what I mean.
But I don't know why the numbers are printed out in reverse order, or if that has to be like that.. maybe it's a bug..
Anyways, normally one would use [until] for things like that.. no stack-overflows all sunshine..
Thanks for the insight.
I found the execution graph explained:
However, in _Pd Documentation 2_ section "2.6.2. persistence of data":
http://www.crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s5.3
"Among the design principles of Pd is that patches should be printable, in the sense that the appearance of a patch should fully determine its functionality. "
That means the execution order influenced by connection creation order violates that design principle, since the creation order is not "printable" or otherwise indicated in the GUI. It seems more like a bug that has become convention. If many patches depend on that bug, it's now a feature, that violates the design principle and is pretty bad anyway.
Also, why is the execution order of object output from rightmost outlet to leftmost? It's counterintuitive (among LTR readers, which is the only text justification Pd supports). Again, I wonder how many patches depend on that ordering.
>>That means the execution order influenced by connection creation order violates that design principle, since the creation order is not "printable" or otherwise indicated in the GUI. It seems more like a bug that has become convention. If many patches depend on that bug, it's now a feature, that violates the design principle and is pretty bad anyway.<<
i totally agree! the best way to avoid this trouble, is to always use trigger objects to make the execution order absolutely clear.
>>Also, why is the execution order of object output from rightmost outlet to leftmost? It's counterintuitive (among LTR readers, which is the only text justification Pd supports). Again, I wonder how many patches depend on that ordering.<<
It makes total sense to have INLETS triggered from right to left, with the leftmost inlet 'hot'. For example, consider the humble float object [f ]...
if you send a value to its right inlet, then that value is simply stored, and waits for a bang to the left inlet. This makes sense, because you always want the left inlet to be the 'active' one in your chain, to keep things nice and tidy.
so, it makes sense for inlets to be triggered in this order, and therefore, it also makes sense that outlets would follow the same convention as inlets.
Good points: now the RTL order seems intuitive, given that the L inlet is the "hot" one.
But on the execution order influenced by the connection creation order, that seems like a bug worth fixing. Do you know how I submit patches that fix bugs in pd-extended (Linux)? To pd-extended, or to pd-vanilla? I'd ask on their dev list first whether a patch would be accepted, or whether the bug is now entrenched as a "feature".
Hi Matthew,
Execution order defined by connection creation order is definitely a feature and not a bug. If you think about it, if you don't use trigger ordering then how is Pd going to know which connection to execute first? Yes it is ambiguous in the GUI because the GUI is fairly simple, but the intended workflow is to use [t] to enforce ordering.
Submitting a patch is not usually in the sense of a Pd patch, unless you want to show a reproducible bug. A patch is usually a change in the code base to fix issues or add features, in Pd's case this is written in C.
yeah, it's not a 'bug' in that sense. It is actually a 'feature' as Jwif points out.
still, for your own patching, pretty much everyone with experience in pd will tell you that it makes life a LOT easier by explicitly forcing execution order with [t] - even in cases where it might not even appear to matter.
@Jwif said:
Hi Matthew,
Hi 
.
@Jwif said:
Execution order defined by connection creation order is definitely a feature and not a bug. If you think about it, if you don't use trigger ordering then how is Pd going to know which connection to execute first? Yes it is ambiguous in the GUI because the GUI is fairly simple, but the intended workflow is to use [t] to enforce ordering.
It seems to be a bug. It violates the sensible design principle of the GUI indicating all the properties of every object. Without a [trigger] ordering the execution, Pd should (according to the design princple) order the execution the way it does now, but without respect to the connection creation order. So exclusively by RTL ordering of outlets (hot vs cold rules), starting with the "least deep" (zero or fewest inlets connected to another object) object. Where there are multiple least deep objects, the GUI would require a [loadbang] or other disambiguator, using the topology to indicate the ambiguity or unambiguous start object.
The bug leaves the ambiguity either undetermined (unless using some tool to examine the serialized patch in its storage file), or requiring a [trigger] object which could be omitted - or included redundantly. Since the patches often execute DSP and other considerable CPU/memory load, minimizing superfluous execution objects is a good idea. Especially now that Pd is expanding its platform to mobile, embedded and other constrained devices.
The fact that the bug is old enough that there's a lot of code dependent on it (or at least coded to avoid its consequences) doesn't mean it's not a bug. The violation of the sensible design principle makes it clearly a bug, and the clearer coding practice available with it debugged makes it a fixable bug. However, as usual in "bug features", ensuring compatibility with the existing code is essential. But since the [trigger] object would make the code work the same, and without the [trigger] object the code's execution order is basically undefined (because examining the serialized file is not part of regular patching practice), debugging it seems both beneficial and feasible, therefore worth doing.
@Jwif said:
Submitting a patch is not usually in the sense of a Pd patch, unless you want to show a reproducible bug. A patch is usually a change in the code base to fix issues or add features, in Pd's case this is written in C.
I know; I'm referring to rewriting the source code of the Pd engine, not connecting a graph for Pd to execute. I'm an experienced programmer, as well as a beginner patcher.
@mod said:
yeah, it's not a 'bug' in that sense. It is actually a 'feature' as Jwif points out.
still, for your own patching, pretty much everyone with experience in pd will tell you that it makes life a LOT easier by explicitly forcing execution order with [t] - even in cases where it might not even appear to matter.
I think the "printable graphs" design principle is a good one, and superfluous [trigger] objects eat CPU and other bandwidth, while missing necessary [trigger] objects can lead to the kinds of buggy patches that I started this thread with. I'll spend more time learning about Pd theory and practice before deciding whether to try debugging it. But I've seen so many bugs adopted as features get eventually debugged in my 35+ years programming that I won't be surprised if people don't want to part with it.
there does seem to be some truth in what you say about [t] eating cpu. here is a quick patch i made to add 1 + 1, a million times.
with a [t b b] object in the chain, i get results of 140/150 ms, but without the [t b b], i get 110/120 ms
the thing is though, that i have to instantly send 100,000 messages through a [t b b] before i can even register an observable spike in usage. (and only when i send a million messages, can i see the difference between a construct containing [t] and one without it)
Usually, to send that many messages instantly, you would use the [until] object, which i think is in itself quite unoptimized for such cpu intensive usage. So, the amount of cpu overhead consumed by 'superfluous' trigger objects is going to be almost totally negligible, compared to other places where there are bottlenecks and performance barriers.
if you've got coding experience and ideas, then you'd probably be best to chat with the guys on pd-dev mailing list, i'm sure there are heaps of things that still need looking into. Those guys will have a better idea of what's going on, i reckon.
this forum is more for just general patch sharing, troubleshooting, brainstorming, that sort of thing. for issues relating to the source code of pd itself, then i think that maybe the pd-dev list would be the best place to start. In regards to this issue of execution order and connections, i think you'll probably be correct that there will be a big reluctance to change, but there might be other things that can be looked into.
@mod said:
there does seem to be some truth in what you say about [t] eating cpu. here is a quick patch i made to add 1 + 1, a million times.
with a [t b b] object in the chain, i get results of 140/150 ms, but without the [t b b], i get 110/120 ms
I ran it on a P4/4.3GHz with some other procs (another Pd-e instance, a shoutcast stream) and got 170ms without the coordinating [trigger] and 230ms with it. That's over 35% longer for the "documenting" superfluous [trigger]. I'd say that in constrained devices (or alternately where heavy patches constrain a device), the extra [triggers] are a significant limit.
If the connection creation order didn't violate the "printable graphs" design principle, there wouldn't be as much value in extra [trigger] (and perhaps other) objects that consume sometimes valuable performance (and make graphs more complex).
@mod said:
the thing is though, that i have to instantly send 100,000 messages through a [t b b] before i can even register an observable spike in usage. Usually, to send that many messages instantly, you would use the [until] object, which i think is in itself quite unoptimized for such cpu intensive usage. So, the amount of cpu overhead consumed by 'superfluous' trigger objects is going to be almost totally negligible.
It depends on the application. Where most of the app is DSP, those objects are (presumably) tightly coded and optimized. Most of the patch logic is merely assigning the engine's dataflow between loops. Moving data among allocated memory is pretty efficient. But where the patch has a lot of control logic, lots of extra [trigger] objects (or a few executed in loops) is going to eat CPU/memory resources.
I'm coming to Pd from procedural programming, though I have DSP experience from across the past 20 years so I get it. I'm looking at coding apps in Pd that are perhaps no DSP at all, just because the dataflow paradigm is so interesting. Or apps with logic complexity typical of a usual procedural app without DSP, then applying it to DSP. My DSP experience is rooted in such old devices that I'm concerned with saving resources from the get-go. And I'm interested in using dataflow for targeting tablets and mobiles with constrained UIs and computing resources (and constrained user profiles). So an optimization attitude is my starting point.
Maybe I should just code a lot of patches and see what everyone else takes for granted.
I guess the initial thought (of Miller) was that the gui should be a non-essential part of the actual pd programming paradigm. It's just a human assistance layer on top of the actual execution engine, and has therefore never be given lots of attention. I've been (only) developing code for 15 years and one thing I've learned is that in real-world situations (vs academic) it's often interesting to be pragmatic about how to implement something (why put in place a nifty design-pattern when you could do the same thing maybe in 10 lines of procedural logic, depending on the scope of the application of course). The use of [t] has never bothered me and always struck me as being rather logical. After creating quite some patches it has become second nature. It's also a very simple concept in its own, when you have more than one line coming from 1 outlet, just enforce the correct order of execution, no more, no less.
Good luck with it.
D.
|] [] |.| ][|-| -- http://soundcloud.com/domxh
@domien said:
I guess the initial thought (of Miller) was that the gui should be a non-essential part of the actual pd programming paradigm.
...After creating quite some patches it has become second nature. It's also a very simple concept in its own, when you have more than one line coming from 1 outlet, just enforce the correct order of execution, no more, no less.
It seems to me that since [t] is optional, many patches will be written without it, their connections created in the order necessary for proper execution. But later, even the original coder will forget that order, and when editing the patch won't see which of several possible orders is actually implemented. That can be disambiguated by adding [t] at that later time. But what about when you simply mistake which order is implicit, and your changes are bugs in the context of the actual execution order? I already get a fair amount of "inlet: expected 'float' but got 'list'" errors that I can't easily trace to which object's inlet is getting the wrong type. Especially when a complex patch includes many layers deep abstractions within abstractions.
That's why the "printable graphs" seems a sensible design rule. Also separating the GUI from the execution is a very insightful architecture; Visual Basic inseparable from its IDE is a curse. The libpd project and the network objects give Pd application architectures a compelling simplicity.
Maybe it's because Pd's engine is so powerful, especially for audio DSP, that most patches aren't nearly as complex as most useful procedural applications. I haven't seen many patches that are capable of real spaghetti (and meatballs if laid out clumsily. But again, apps with some complex control logic or dataflow will be more prone to stumbling over hidden dependencies like connection creation ordered execution. That artifact forces coding session state into execution session state in a way not apparent at execution time. Pd's ability to "live code" means that the creation order from the earlier editing session forces a distinction between the two editing sessions that interferes with the directness of live coding.
Maybe another useful tool would be a GUI widget that would show the execution order without execution, or at least label the connections from each outlet object to each inlet object in execution order. But then, the Pd GUI doesn't even indicate the difference between Edit mode and Execute mode (AFAIK).
@domien said:
Good luck with it.
D.
Thanks. Pd does seem to have a lot of GUI crudeness that the Pd community has accepted, prioritizing making audio and other applications instead. But this one seems worth patching, since it's not just a matter of style but of essence. However, I'll see what kind of priority I put on patching it, after I go the path everyone else took to accepting it and focusing on more interesting applications. I'm just wrestling with data structures now, and lots of seeming changes I'd like in how that's done. Just another know-it-all immigrant who needs to learn the language before rewriting the Constitution 
.
Hey, I just can confirm that it's a feature, and that you savely can leave the triggers out. That even is no problem for the graphical layout as long as you place "first things" to the right. ..Then it will rather look like Max...
(That's what I do for years now, and I never had problems with it!!)
Despite Max which uses "right objects first", Pd uses "first connections first". Since that's not as strict as within Max, my pd-patches (especially bigger ones with loops) don't look like a messy nugget in the end! Because I use "local" instead of "global" r2l-order, that means per outlet! (something close to "b)" )
Actually we or someone can make a real feature out of it now since there are GUI-plugins:
I thought about something like numbering the cables:
..[blablabla]
../|\
./.|.\
3 2 1
Now if you add another one you can give it a number like 2.5, and it will automatically be sorted between "2" and "3", and finally it will be remapped to integers.. like: 1, 2, 2.5, 3 => 1, 2, 3, 4
And it could be possible to resort cables just by changing the appropriate number!!
I have two other methods on my mind for showing the order:
a) "Spectrum": Just colorize (colourise) the cables from red (=first) over green to blue (=last), or do the same not with rgb but grayscales..
Use some kind of "post-outlets" or "localised order". That's hard to explain but easy to imagine, I promise!
It's like... uhmmm.. ok:
.. [obj]
.. /|\
./ | \
[] [] []
| | |
It's like this, so it's inbetween the trigger and single objects. If you want to resort a coble you just change its position in this local area. Maybe think of it as being an electrical circuit with real wires..
..cause this "patch" is just for making it clear. In the end this should be implemented in every outlet. And just act as a graphical tool (without eating up CPU)
Of course one can use eg. the "spectrum" and "numbers" at the same time..
The thing that annoyed me most with these [trigger]s is, besides the useless CPU-hunger (it's even faster to use "[f] [f]" instead of "[t f f]" ...and with "[f] [f]" one even gets some buffers (...2nd inlet ya know..) ) , that changing the order of cables just sucks!
Imagine you have a [t b b b b b b b b b b b b b b b b b] that eg. does bang some math with tables.
Now if you want to add some more math (so you need another "b") you would have to delete the whole object and reconnect it, just because of and extra "b", since the outlets extend to the right, but order of operation goes to the left! (right!?! )
Now instead just use a with multiple connections:
..,just add cables to the left and you are done: **
..|\ /|\
In my opinion the triggers are the only things that make pd rather feel like a toy than a programming-language.. but since triggers existed before the GUI-plugins, maybe they "were" useful. (btw. [namecanvas] still is!)
Like 2 years ago I have already posted something about this:
http://puredata.hurleur.com/sujet-4943-visualizing-connection-order
But now with those GUI-plugins it might be easier...******
As Flipp mentioned Pd uses creation ordering instead of spatial ordering like you see in Max. This is how it was designed and I'm fairly certain 'it's a feature' would be your reply on the mailing lists.
The issues that arise from this design choice however are another matter. I agree with you that it promotes ambiguity and confusion as the logical ordering is not obvious, but I would say that it's up the programmer to ensure that the code is readable. (Most) other languages allow you to write sloppy code and it isn't considered a bug.
Personally I love [trigger] and use it religiously on any outlet that needs more than one connection. By forcing this habit I can ensure that my code is 100% readable every time I go back to it, and I feel it also helps reduce unnecessary bugs.
That's not to say that creation ordering isn't flawed, there are definitely downsides.
Given that using [trigger] is apparently universally considered necessary proper practice, and that it's impossible to tell execution order in even slightly complex patches without [trigger] unless you inspect the saved patch file, would changing the execution order to ignore connection creation order ever break any patches? Wouldn't making execution order follow only what's visible in the graph (RTL, depth first) surprise only the original patcher who can remember their original patch creation sessions? Everyone else would see just one of the possible ambiguous execution orders hidden in the stored patch, but the one where the creation order followed RTL/depth-first.
Or are people relying on patches to execute in creation order, that they can see later only by inspecting the file or manually remembering their own earlier sessions? Or maybe some patches are manually commented to indicate the creation order?
hi matthew, i think that any patches relying on patching order have just been written without considering the execution order, and will probably mostly be working due to pure luck, or the fact that execution order doesn't matter in their case.
i don't think there are any (sane) people out there who would actually make patches relying on invisible connection order.
perhaps an exception might be the 'live programming' / dynamic programming crew, who need to get stuff done as quickly and simply as possible, and can be sure of their connection order...but even then, it would be pretty rare.
..
I think the main issue, is that pd patches are extremely simple when opened as text. There is the initial entry for the canvas, perhaps some graph-on-parent info, subpatch info,...
but then everything else is just objects/messages and their connections.
if you want to go with RTL or depth first connection order, it adds another level of complexity to the process of loading a new file. The current system just scrolls through your patch, and sets up whichever connection pops up first. This may not be perfect, for reasons we're all agreeing with, but that's why there is the [trigger] option - which does carry a very minor cpu tax.
However, if you look at that test patch i posted before, you need a million instantanious computations to even see the effect. In the vast majority of cases, you are only going to use a handful of trigger objects every few milliseconds or less, so the cpu saving from not using [trigger] would be really really minimal, pretty much non-existant.
AND one could even argue that by using the [trigger] object, the patch is going to become neater, and therefore easier to follow / understand, and therefore critical patches can be more easily optimised.
Oops! Looks like something went wrong!
