Something I was thinking about yesterday, while adding to my [text sequence]-based abstractions:

[text sequence] is a stateful object, in that the result of [step( depends on the previous state.

What if you need the result to be handled differently in different cases?

Specifically, I'm rejiggering the data so that it outputs the time delta to the next event alongside the data list, rather than the time delta from the previous event. As a step sequencer, in pseudocode, it looks like this:

coroutine
    t = text sequence blah blah;
    list = t.next;
    #time ... data = list;  // [list split 1]
    time --> time outlet;  // withhold data now
    wait for bang;
    while
        list = t.next;
        list isn't empty
    do
        #time ... data2 = list;
        time --> time outlet;
        data --> data outlet;
        data = data2;
        wait for bang;
    loop;
end

So there's an "initializer" handling of the [text sequence] result, and then a "normal" handling within the loop.

For stateless operations like [+ 1], you can just replicate the operator for the different contexts. But because [text sequence] is stateful, you can't do that.

I could actually think of a nice, clean solution for numeric results -- I'm OK with this as it would scale up to any number of references:

But [value] can hold only a single number (why? wouldn't the equivalent of a 'variant' type be useful?), and [text] is dealing with lists.

I ended up using the [list prepend] --> [route 0 1] trick -- fair enough as the above routine uses the sequence in only two places. It might not scale when things get more complicated (for instance, in https://github.com/jamshark70/ddwChucklib-livecode/blob/master/parsenodes.sc I'm passing a stateful string iterator through dozens of functions, haven't counted them but I guess it's easily 50 or 60 places -- from a computer science perspective, a parser is not an exotic use case -- quite common really -- [route 0 1 2 3 4 5 6 7 8 9 10 11 12] oh, I give up already ).

Wondering if there are other options. It would be really nice if graphical patchers had a concept of a shared object reference, replicating the 't' variable in the pseudocode, but I guess that won't happen soon.

hjh

This thread would have saved me two weeks of work if it had come around two weeks ago. Somehow I muddled my way through it and a pd implementation of Befunge-93/Funge-98 is essentially a reality. We should have a meta thread to collect good threads such as these.

@ddw_music said:

I think that concern is somewhat mitigated by the fact that the intention here is to send to one and only one [receive], and (deterministically) this [receive] object will trigger its chain before the [send] yields control.

If there are accidentally two [receive] boxes with the same name, that would indeed be non-deterministic, but also user error.

Yes, sure. From Pd's point of view the order of operations is still deterministic if there are multiple receives. The one created first will be executed first. From a user point of view it can lead to unexpected results, for example if the patch is opened twice and the receives are not protected by $0.

For me, the most important point of this thread is to learn dataflow vocabulary for the text-programming concept of function calls.

This is a decent starting point, but more and more it will lead you astray.

For example, your initial text pseudo-code leads quite naturally to a notion of passing around references to objects, which is what Pd scalars typically depend on. That's like anathema in a diagram-based language, and it's the reason nearly nobody uses data structures in Pd aside from demonstrating cleverness. But there's nothing in the text-based programming world to clue you in to that.

Additionally, there are useful patterns in Pd that you won't discover by thinking in terms of functions. There's a common pattern of sending a message through an object chain to be filtered, a lot like a vertical version of piping data in a shell script. There's another common pattern where the same message flows through an object chain unchanged so that each abstraction can trigger its own side-effect. Finally, you could leverage ingox's "function" abstraction to create an object chain that steps through a state machine in a quite readable way. (In fact ingox's wrapper may be more abstraction than you need for your state machine since you could just make a custom abstraction with the exact kinds of inputs/outputs that you need for that specific case.)

This is how i see it:

OK, how about this...? (Maybe I actually understood something.)

I was thinking lately about "map" methods (take in a list, and output a list where some operation has been performed on every element).

That's a perfect case here, because the list operations (iteration and concatenation) are always the same, but the operation is different.

Here's what I came up with (and also added an analog to SC's Array.fill(n, { ... func ... })).

list-map.pd
list-fill.pd

... where the top right example prints "50 30 90 80 20 60". Unpack is because (inspired here by SC's do and collect) it may be useful to pass an index through.

This seems to work pretty well actually. As noted earlier in the thread, it's the user's responsibility to avoid name collision, but apart from that, this seems to fill a gap.

hjh

@ddw_music The list-abs library is worth a look.
It is entirely abstractions...... so vanilla.... and they are well named.
So well in fact that in this case it is the same as you have chosen..... [list-map]
Maybe it doesn't do exactly the same?
But all the tools are there I think.
David.

@whale-av

Ah.

So back to a core problem of Pd: many important features, that are basic operations in other languages, are external libraries in pd; external libraries are undocumented in core (which is reasonable); therefore basic operations (list-map is a basic operation...) are inaccessible from core, without forum assistance.

User impact is that I have to budget extra time for just about every class demo because I can't just look it up somewhere -- I have to wait for answers from the forum. Maybe I could search for it in 5 minutes, but a forum question might not be answered until hours later.

There really should be a list somewhere of external libraries' contents.

hjh

@ddw_music As your send inside the abstraction is static due to the creation argument it would be more flexible to just use [list-map] from list-abs and leave the send outside the abstraction.

As to your critique: There is no comprehensive list of externals as Pd is an open system, where everybody can make externals. Many are on Deken, others are just on some Github or website.

Here are some lists of externals/objects:

• http://write.flossmanuals.net/pure-data/glue/ (other areas on the lower part of the navigation)
• http://pure-data.sourceforge.net/old/documentation.php
• https://puredata.info/docs/ListOfPdExternals/
• https://archive.flossmanuals.net/pure-data/list-of-objects/introduction.html
• http://blazicek.net/list_of_pure_data_objects.html

I believe that any community effort to build a better, up to date and more beautiful list with tags, categories and more will be highly appreciated.

I'll add the new web interface for Deken:
https://deken.puredata.info/

I didn't really use it yet, but it might be helpful for finding externals and libraries.