[PD] Trigger question

IOhannes m zmoelnig zmoelnig at iem.at
Thu Mar 18 11:35:09 CET 2021


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




More information about the Pd-list mailing list