@porres said:

so I wonder what is not clear about all this.

It is a tricky thing to explain when your audience includes everything from complete layman to accomplished programmers. I can see now that it is all there and have been studying it and a few other sections trying to figure out what tripped me up and I think it is just a minor structural and terminology issues. What a selector is and does should be covered in the first paragraph instead of being split out between the first and fourth. This is the main thing the user needs to understand in this section and it should be laid out up front so anytime they refer back to this section it gets beaten into our heads. Maybe something like this?

Messages contain a selector followed by any number of arguments. The receiver of a message uses the selector to 'select' how it should proceed and handle any arguments. Selectors can be any valid symbol and arguments are anything that follows the selector and may be symbols or numbers (aka atoms). For instance "list a b c" has a "list" selector, which tells the receiver to process the arguments "a b c" as a list data type. This message is only composed of symbols but a list message can combine two or more symbols and/or floats.

You are right about keeping methods out of this section, the detailed explanation including methods should be in 2.7.3 which is almost there, just needs a few things like methods added in and probably simple definitions of things like object, class and method in context of pd. Maybe a reference to 2.7.3 in 2.4.1, "this will be covered in more depth in 2.7.3" or the like? The rest seems good to me.

I really hate doing documentation.

@oid said:

I really hate doing documentation.

It's not easy and sometimes it's quite the nightmare. I don't know why I like it

@porres said:

@ddw_music I hear a lot about what SC can do that Pd can't, but that was not the discussion...

Sure, I was hijacking a bit.

I don't care for live coding, for instance. I never needed scripting in Pd as well. Having said that, I'd love to be challenged in offering a "pd solution" to some of its things.

It's not that Pd can't necessarily -- it's rather that the weight is heavier: anArray.do { |item| ... some operations... } vs

A concrete weakness of patching is when you have a stateful object that needs to be accessed in multiple places. In a text language, this object lives in a variable, and you can use the variable anywhere in its scope. The best I can figure out for Pd is:

It's "ok" but with a bit more effort. And this effort is kind of the point -- if enough things are just a little bit more difficult, then the "it's not worth it" threshold is lower. Like, I've got a function in SC that takes an array of intervals, a root scale degree and a top-note scale degree, and it does a recursive tree search to find the most consonant (relative to the root) arrangement of those intervals coming down from the top note. In SC I get recursion and scale-degree mapping for free, making it a lot more approachable to implement (where in Pd, I'd have to implement my own recursion stack and at least search for an external for scale degrees).

You know, I stole a lot from SuperCollider into ELSE, I'm interested.

I saw that -- [resonant~] vs Ringz.ar is what tipped me off.

In Pd, loading a big audio file can glitch the audio so you need a workflow where everything is laid out in advance and that's just what you're working with

This can be solved with an external, and [else/sfload] can load big files without choking Pd by having a multi-thread mechanism.

Feature request for sfload: provide file statistics (sample rate, number of frames etc.) upon completion. If the file read is asynchronous, currently you have no way to know when it's done and no way to get access to these properties.

More serious for Pd, though, is that adding signal processors causes the entire graph to be re-sorted, and this can glitch. So if I add a poly instrument with 15 copies of a big synth, I wouldn't trust doing that on the fly.

let me try, I wanna have a better idea of what you mean

Maybe in a different thread... more than I can write up just at the moment.

Did you really run that test though? and well, not sure if I know what you mean, because if it's what I think, it this seems like a pretty basic lesson for Pd. It's on the control examples...

Of course I haven't... sure, I could be wrong. But it does come up from time to time on the forum, without referring to the control examples.

hjh

@ddw_music said:

anArray.do { |item| ... some operations... } vs

Well, if you're gonna use Vanilla objects, live's definitely gonna be harder, but I say life's too short to stick with Vanilla. Being someone who is about to reach 600 objects in his library soon, you may assume what my view is. Pd with just the vanilla objects is simply not a complete set of tools for computer music, nor enough... I don't doubt that. Pd Vanilla is simply the bare minimum at best. But even so, you can build a list iteration object with your patch above just fine and use it as an object. Or use [else/iterate] and [else/loop] like I said....

A concrete weakness of patching is when you have a
stateful object that needs to be accessed in multiple places.

I don't think I know what you mean here, really. How is this not like using [value]? Or the "send" message to "float". Anyway, I bet one can think of an external solution for this. I'd like to try it if I get it. I also think of [else/retrieve]...

Anyway, your examples are not clear to me, but the discussion interest me. I wanna get what is deal with recursiveness, for instance, but hey, we're hijacking the thread

Feature request for sfload: provide file statistics
(sample rate, number of frames etc.) upon completion.

new version already does that

I wouldn't trust doing that on the fly.

no, Pd is not for Live Coding (something else i don't care for)

Maybe in a different thread...

sure, go ahead please

@ddw_music said:

The best I can figure out for Pd is:

In that situation I would say that [pd my-stateful-thing] should have a send method. But [value] is also good if floats, if symbols/lists then an abstraction which works the same as value but holds any sort of data is trivial, probably some externals which do that as well.

Regarding your live-coding dialect, would be curious to see it if you shared it anywhere. Not much for live-coding but it would be interesting/informative to see how you went about things. Most of what I do in pd is designing languages, it is not so bad but you have to go about things differently than you would in other languages, instead of designing a dialect of pd I design a language including the audio generation aspects, SC style server/client or a VM. Pd is a low level language and you need to treat it as such, work to its strengths instead of fight its weaknesses.