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.

http://www.pdpatchrepo.info/hurleur/counter.pd

@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.

@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.

i don't think there are any (sane) people out there who would actually make patches relying on invisible connection order.

...I do. But I'm not that insane, so I make the connection-order visible while patching (via object-positions etc.).
In most cases that ends up with a r2l-order, as I said..
...And I hope that the invisible order can be made visible with plugins ...some day... NEED HELP with that!!!

Now if I'd start using triggers, I would use them every time there is something that has a certain order, or needs it.. But if I don't from time to time, isn't that sloppy as well?!?

I just did some crazy math with soundtables (=long). Eg. a "special mean" or a convolution or whatever.
In general mathematical operators are an integral (or sum) over the product of a kernelfunction and the actual function one wants to change...
So for example imagine you have a table with just 10 sec. of audio (~ min. 441000 samples (up to 1920000, with better hardware...)) and your kernel is (only) 1000 samples long. So in the end there have to be done like ~1000*441000 (max {192000/44100*} 1000*1920000) computations PER OBJECT!!
This certainly is nothing for realtimeprocessing, but if I had the choice I'd rather want to wait just eg. 1min. instead of 2mins.. (maybe a little exaggerated for this example but not impossible)
Dont you think it's a good idea to save as many objects as possible in such a case?!?

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.

Well, it depends on what you see as optimisation...
If you create something that is meant to be used, I think optimisation means making it as slim and fast as possible.
If you want to look at it, it should better be looking good...
...I have seen patches where triggers are used on the one hand, but then the objects are spread everywhere around the canvas on the other hand, like "Why should I even care - I use triggers already"..
Trying to read that isn't comfortable at all.
Generally more freedom is certainly a feature not a bug! And certainly one needs to be able to handle it. I think that's not only true for pd, anyways..
As Jwif said, in most programming languages it's up to the user to not write sloppily styled code.

Finally just let me say: "Triggers are crutches"

I gonna sketch out a patch with possible GUI-plugin-solutions, sooner or later.
But since I don't know how to really write them,
IS THERE SOMEONE OUT THERE, who is able to write a "quick and dirty" GUI-plugin??? ...that's TCL/TK, isn't it?!
One of the best things about plugins (as well as [trigger]s) is that one doesn't have to use them! So, even more freedom for everyone!

@Flipp said:

Well, it depends on what you see as optimisation...
If you create something that is meant to be used, I think optimisation means making it as slim and fast as possible.
If you want to look at it, it should better be looking good...

I understand your objections against the use of triggers, but what you're saying here really doesn't make much sense to me. Given the enormous processing power all actual cpu's have, i can't really believe people are still patching to save cpu consumption. We're all writing code to be executed by computers, and computers don't really care about coding styles, as long as it compiles it's fine. But then there are runtime errors which compilers can't catch and can end up in very long debug sessions. Then it's up to human beings to read the code, and i can assure you that humans absolutely benifit from a clear coding style. Given that pd is such a great application, with a very nice community spirit where everyone can download, dissect and study from others, i think code that "looks good" is crucial.