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

I don't think Pd is a dataflow language. The signal diagrams might count as that. But the non-DSP objects are a weird kind of Rube Goldberg-machine of imperative programming. (And they can interact with the DSP objects in a diagram.)

It creates an irony where the most difficult conceptual part of Pd-- DSP programming-- gets the simplest diagrams. E.g., all objects are guaranteed to receive their inputs before they compute their outputs. While the simplest conceptual part-- sending sporadic arbitrary data to immediately compute an output-- requires special objects to keep the order of operations correct.

@ddw_music Just for fun i built this general wrapper to use an abstraction like a function. The only requirement is that it has just one inlet and one outlet. The input is sent to the place where the function is defined and the output is sent back to where the function was called. The [value function_state] is only to prevent multiple returns if the function is defined multiple times by accident.

Anyhow, below is the simple solution just using the abstraction directly.

function_demo.zip

@jancsika

Imagine you've got a single sequencer in the top level of a patch.

Somehow, from your first description, I didn't get this idea at all Basically it's the same as jameslo's second example here and my second example here -- the latter of which explicitly strips the [send] name off of a list btw.

@ingox

The simulated function via setting [send] to the caller of the "function" is possible, but it somewhat contradicts the data flow paradigm. It is important to see that in Pd, every operation is done sequentially, in a strict linear order of operations. So you are actually always in control over what is happening.

I do see the point -- 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.

Patching is just more fun.

I do find it fun in the sense of learning a different way of thinking. I don't know that I will ever really love patching in the same way that I love coding though.

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.