Sometimes when using trigger I find myself needing to break out of it before it completes, simple to work up an abstraction to handle this, but it got me to wondering why trigger does not have a right inlet to stop the sequence. Looking at the code, trigger is a for loop as expected, so it would seem to be a very simple task to add this right inlet to allow breaking out of the sequence, is there a reason trigger lacks this? Something so simple and obvious never having been done suggests I am missing something, is this not as useful as it seems? Am I missing something about dataflow?
Sorry, I forgot to reply to the list.
Hello Adam, I am not sure how you are using trigger like a for loop Can you send an example? The way I use trigger is to make sure the incoming message is output in the order I want them to (from right to left). Maybe you can use a spigot after each output. That way you could stop it from sending messages to those specific outputs.
adam johnson ulioidle@gmail.com escreveu no dia quarta, 17/03/2021 à(s) 09:12:
Sometimes when using trigger I find myself needing to break out of it before it completes, simple to work up an abstraction to handle this, but it got me to wondering why trigger does not have a right inlet to stop the sequence. Looking at the code, trigger is a for loop as expected, so it would seem to be a very simple task to add this right inlet to allow breaking out of the sequence, is there a reason trigger lacks this? Something so simple and obvious never having been done suggests I am missing something, is this not as useful as it seems? Am I missing something about dataflow?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 3/17/21 9:39 AM, adam johnson wrote:
Sometimes when using trigger I find myself needing to break out of it before it completes, simple to work up an abstraction to handle this, but it got me to wondering why trigger does not have a right inlet to stop the sequence. Looking at the code, trigger is a for loop as expected, so it would seem to be a very simple task to add this right inlet to allow breaking out of the sequence, is there a reason trigger lacks this? Something so simple and obvious never having been done suggests I am missing something, is this not as useful as it seems? Am I missing something about dataflow?
i think so.
[trigger] is not a loop¹. it's a device to guarantee order-of-execution. there are other devices to stop dataflow (e.g. [spigot]), and devices to create stoppable loops ([until]), if that is really what you need.
it's hard to say so without an actual example.
fgdmst IOhannes
¹ as you figured by looking at the code, it is implemented (in C) using a for-loop. but that doesn't make it a loop. if you look deeper, you might find the for-loop translates to CMP and JMP instructions. that doesn't make [trigger] much of a comparator or a a jumper.
I guess I was not clear, I am not using it as a loop, I was just saying that at the code level [trigger] is a for loop, so having it break would be simple to add. I am using it more as a conditional, if certain conditions are met on this output, it bangs the right inlet and stops the rest. This is easy enough to manage other ways most of the time, but it can get ugly. I will attempt to simplify my current use after work and send it on if this has not resolved by then, so far my attempts to simplify it have not been successful and the patch itself needs to be cleaned up before subjecting anyone to it, which I am currently working on doing.
On Wed, Mar 17, 2021 at 12:18 PM IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 3/17/21 9:39 AM, adam johnson wrote:
Sometimes when using trigger I find myself needing to break out of it before it completes, simple to work up an abstraction to handle this, but it got me to wondering why trigger does not have a right inlet to stop the sequence. Looking at the code, trigger is a for loop as expected, so it would seem to be a very simple task to add this right inlet to allow breaking out of the sequence, is there a reason trigger lacks this? Something so simple and obvious never having been done suggests I am missing something, is this not as useful as it seems? Am I missing something about dataflow?
i think so.
[trigger] is not a loop¹. it's a device to guarantee order-of-execution. there are other devices to stop dataflow (e.g. [spigot]), and devices to create stoppable loops ([until]), if that is really what you need.
it's hard to say so without an actual example.
fgdmst IOhannes
¹ as you figured by looking at the code, it is implemented (in C) using a for-loop. but that doesn't make it a loop. if you look deeper, you might find the for-loop translates to CMP and JMP instructions. that doesn't make [trigger] much of a comparator or a a jumper.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 3/17/21 9:20 AM, adam johnson wrote:
I guess I was not clear, I am not using it as a loop, I was just saying that at the code level [trigger] is a for loop, so having it break would be simple to add.
and i was only saying that just because something is implemented in such-and-such way should be of no concern. it's implemented in C. it would be trivial to launch rockets on the third outlet from the left as a side effect.
I am using it more as a conditional, if certain conditions are met on this output, it bangs the right inlet and stops the rest. This is easy enough to manage other ways most of the time, but it can get ugly.
for conditions use [select]. you still have to come up with an example where it gets so ugly it's hard to bear.
I will attempt to simplify my current use after work and send it on if this has not resolved by then, so far my attempts to simplify it have not been successful and the patch itself needs to be cleaned up before subjecting anyone to it, which I am currently working on doing.
what are the chances that while you clean up the patches so they are presentable you discover that whatever you thought you needed a stoppable trigger evaporates?
anyhow.
somehow i think what you want to do is like this:
| [t b b] | | | (calculate condition whether the left-branch should run) | (depending on right branch run or not)
the proper way to do this is:
| (calculate condition whether the sub-tree should run) | [select 1] | (subtree-to-run if condition above was met)
vmgsdr IOhannes
and i was only saying that just because something is implemented in such-and-such way should be of no concern.
A feature not existing because of the difficulty of adding it would be one possible answer to my question, so I checked the code before coming here and it turned out to be the expected for loop.
you still have to come up with an example where it gets so ugly it's hard to bear.
Why? I never said it is hard to bear, I said it was easy enough to work around and implied that being able to break out of trigger would make it neater and more readable, and at times it would. Most things in life would probably be unbearable if we waited until things got difficult to bear before even asking why.
what are the chances that while you clean up the patches so they are presentable you discover that whatever you thought you needed a stoppable trigger evaporates?
It is in cleaning this patch that the question arose, but I never said I needed it, I did not request a feature. I plainly stated that I suspected the fault was with my understanding and not pd. Most languages give you simple ways to break out of a sequence of events, but pd seems to treat it as jumping off a cliff. As I said in my first post, I am asking why, not how to do this, just trying to understand the logic of pd so I can use it better.
hello,
[trigger b b b b] | | | | D C B A will do to A, B, C and D. if you want to do C and D only depending of the result of B, the best "pd" solution is not to stop the trigger. You should use 2 trigger : [trigger b b] | | B A | [test result] | [select 1] | [trigger b b] | | D C
(your test and select can be replace with a single [moses] object, or a spigot, depending on the output of B)
I hope that help Cheers, Cyrille
Le 17/03/2021 à 18:29, adam johnson a écrit :
and i was only saying that just because something is implemented in such-and-such way should be of no concern.
A feature not existing because of the difficulty of adding it would be one possible answer to my question, so I checked the code before coming here and it turned out to be the expected for loop.
you still have to come up with an example where it gets so ugly it's hard to bear.
Why? I never said it is hard to bear, I said it was easy enough to work around and implied that being able to break out of trigger would make it neater and more readable, and at times it would. Most things in life would probably be unbearable if we waited until things got difficult to bear before even asking why.
what are the chances that while you clean up the patches so they are presentable you discover that whatever you thought you needed a stoppable trigger evaporates?
It is in cleaning this patch that the question arose, but I never said I needed it, I did not request a feature. I plainly stated that I suspected the fault was with my understanding and not pd. Most languages give you simple ways to break out of a sequence of events, but pd seems to treat it as jumping off a cliff. As I said in my first post, I am asking why, not how to do this, just trying to understand the logic of pd so I can use it better.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 3/17/21 6:29 PM, adam johnson wrote:
and i was only saying that just because something is implemented in such-and-such way should be of no concern.
A feature not existing because of the difficulty of adding it would be one possible answer to my question, so I checked the code before coming here and it turned out to be the expected for loop.
i see. "hard to implement" would be a bad excuse, but of course not unheard of.
you still have to come up with an example where it gets so ugly it's hard to bear.
Why? I never said it is hard to bear, I said it was easy enough to work
true. but you also said:
This is easy enough [...] most of the time, but it can get ugly.
which i take as "so ugly, it's hard to bear", because if it was "ugly but no problem" you wouldn't have worried to write your mail.
It is in cleaning this patch that the question arose, but I never said I needed it, I did not request a feature.
ah sorry, i completely misunderstood your problem then.
I plainly stated that I suspected the fault was with my understanding and not pd.
ah well. i have interpreted your statement as purely rhetorical, hiding a feature request under humble understatement. most likely i misinterpreted it that way, because i often use this device myself.
Most languages give you simple ways to break out of a sequence of events, but pd seems to treat it as jumping off a cliff.
Pd is a dataflow language, rather than a controlflow language. so there's no "sequence of events" (as in: a series of instructions that are iterated via a program counter). as a Pd doesn't have a "return"
if you want to stop the "flow of data", there are programming devices that do just that: [spigot] (and its ugly sister [change]), [select] & [route] (and its ugly brother [moses]).
As I said in my first post, I am asking why, not how to do this, just trying to understand the logic of pd so I can use it better.
reasons (excuse the gibberish)
- provide different devices for separate tasks
- make objects as functional as possible
gfmdasr IOhannes
-
adam johnson -
cyrille henry -
Francisco Medeiros -
IOhannes m zmoelnig