@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

@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

Miller is working on this, check it out

"To Pd announce:

A very preliminary version (0.1) of a VST3 plugin named PureVST is
available on msp.ucsd.edu/tools/purevst . As the name suggests, it runs
Pd within a VST host such as your favorite DAW.

I'm releasing it, so far, as source code and as a packaged VST3 plug-in
for MacOS (Apple silicon) . It compiles fine for linux and (I think)
for MacOS/Intel - somebody brave might want to see if it can work on
Microsoft Windows too

I'm sure there will be plenty of problems/questions/comments. Perhaps
for now it's appropriate to write these to the Pd mailing list, although
it might someday be worth setting up a different forum for that.

cheers
Miller"

@mic said:

The catch here is that LibPd can only use Vanilla.

You can use externals with LibPd though. The ELSE library runs in PlugData via LibPd.

[else/xmod2~] is the same as [xfm~]. I see the module is just a wrapper on top of. Do you really need all of these modules? It's also easy to build a cross modulation FM/PM patch in Vanilla. I show how to do it in my tutorial

I

@ddw_music I hear a lot about what SC can do that Pd can't, but that was not the discussion, far from it, as it was actually about how Pd is so much more complicated, or one might say complex, when I think it is not at all the case and sure, SC being more complex and complicated should give people something in exchange of that steep learning curve.

Not for me though.

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.

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

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.

that's not even mentioning regex matching

MAX has a [regex[ object and I thought about having something like that as an external, I just never needed, but I just see that you can offer some alternatives with externals.

Don't even try; Pd does not have the string tools.

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

if you put a hundred Pd users in a room and asked them
to make a for loop with an index, a majority wouldn't be
able to (not really their fault, because nobody really teaches
how to write a for loop)

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, I have it in my tutorial, tell people to check them I always teach my students. It's a pretty simple operation and task. ELSE also has the [loop] object...

@oid said:

any object which accepts the float selector also has a corresponding float method?

yup, which is the function that deals with it, and float, symbol, bang, list and pointer are special methods, with predefined macros to add them, others have to be specified manually. Check the source code of any object, it'll be clear.

it never tells us what a method is and how selectors relate to methods

that section does not, and the manual doesn't say much about it other than one mere usage of the term. I agree we could have some more and I could add that... it's nice to better explain what the "no method" error is... but hey, this is not being "overly technical", on the contrary, mentioning about "method" here could be arguably an unnecessary technicality in that subsection.

@porres said:

I guess this subpatch that I referenced to earlier has more examples and makes things clearer?

Well, that's in "Fig. 2.4.2 Different selectors", so I put there as well in the manual, so I wonder what is not clear about all this.

you can also use [else/xmod2~] if you want/have it.

and what modules are you using? I am working on some eurorack inspired objects and I'm also looking into what DIY2 has, it was a nice thing when it came out.

@gentleclockdivider said:

So It's not implicit but c3 is a symbol .

c3 is a symbol, the message type is not a symbol, not implicitly a symbol message type. The type of message is 'c3', the actual message is 'd3 e3', so this 'c3' message has two arguments: 'd3' and 'e3'.

I bring this up , because this is the topic

I meant I didn't understand the confusion about it.

I think pure data is a million times more complex than supercollider

Oh, don't get me started with SuperCollider geez, that thing is what I call a nightmare

Thee whole syntax of Pd is so damn simple, I can teach it quickly in a single class. The syntax of SuperCollider, on the other hand... damn,... what a PITA

There are really a couple of tricky things to learn about Pd's syntax, like the dollar sign deal, and how to deal with selectors, and that's it. And the deal is that the first thing (symbol) in a message sets the message type (feels simple, clear and straightforward to me), and you have some special data types. I really cannot see the complexity in here! I guess it becomes simple once it's all clear to you.

And I hope it is clear now

cheers

I guess this subpatch that I referenced to earlier has more examples and makes things clearer? Should I bring some of this into the manual?

Anyway, thanks for checking the docs and letting me know if they can be improved

@gentleclockdivider said:

The message c3 f3 a3 , the first selector is c3 and thus this message is an implicit symbol , correct ?

nope, there are no implicit symbols in Pd. Symbols are defines with the "symbol" selector, and can take only one argument, quote from the manual "The symbol selector can only have one symbol argument"

It's not a list because the list gatom does not understand it ., neither does the symbol gatom , so is it an unindentified message ?

nope, it is a defined message, with a defined selector

@oid said:

We have three selectors; float, symbol and list

No. that's wrong, we have "infinite" selectors. The selector is a symbol that defines the data type (as the manual says). So, any symbol that comes first in a message is the selector. There some special selectors alright, but they are not just three, but five! Another quote from the manual: These special types are: "float", "symbol", "list", "bang" and "pointer"

if it lacks one of those selectors it treats it as a method like 'set' so your [list store]

The "set" IS the selector. What you refer as a "method" is if the object understands that message selector. So it means it has a function (or "method") to deal with it. If it does not, it will say "no method for set", but it can also say "no method for symbol/float/bang", so it's the same for the special selectors as is with any other general selector. (I see you asked me to chime in later about this, well, here it is).

@gentleclockdivider said:

But the manual clearly states that the first atom in a message
is the selector , and for mesage c3 d3 e3 , the first atom is c3 .
Isn't c3 a symbol , it starts with the letter C ?

Yes, it is a symbol, hence, it is the selector of the message, so "c3 d3 e3" is a message whose selector is "c3" and the actual message is "d3 e3".

When the message is separated by commas , and send though a list ,
the console clearly shows these are seperate symbols , why then ?

they are separated because you're using commas, and commas separate the atoms. And if you sent it to print, you wouldn't see the symbol selector. But since you're passing them through [list] they are gaining a list selector. But since lists need to have two or more elements, one-length lists are converted to a symbol or float message (I think we discussed this on this thread already, and the help file of [list] discusses that).

Now, to be honest, I don't understand why you brought this up here, and why do you ask. I don't see the relation. Just let it be clear that you have 3 messages with just a symbol, and that these are selectors! What is the message then? No message, just selectors. The manual exemplifies something like this when it says about the "stop" message, let me quote it: "If a message contains only one symbol, like "stop", it is considered a selector with no actual message (i.e., no arguments) attached."

I guess the manual could have more examples of generic selectors maybe? I don't know what is exactly not clear in the manual, please let me know so I can see if I can improve it.

@oid said:

I think that excerpt from the manual kind of gets overly technical

Why do you say that? it's telling it as it is...

@oid said:

Lists were simpler things in the early days of pd with [pack] being the primary list object, there was no [list], so an object just to trim the selector would seem somewhat useless with how lists could be used and [route] doing the trim would be sensible. Quick look and [list] did not get added to pd until 0.39. Possibly a lack of foresight/planing or possibly things evolved differently than planned.

hmmm, I see, and yeah, I get that a lot with my library, which keeps growing and growing. And a lot of bad decisions I face is when I add more objects, or different objects, or want to add new features...

If I never added objects it would be much more stable and I wouldn't break things so much. It's hard to know before hand what you will want to do in the future anyway, that makes sense indeed, thanks

@ddw_music said:

Symbols aren't "the point" of [route], but why then does [route] not automatically strip the "list" tag?

What do you mean? It does strip it... sending "list dog cat" to [route] strips (or "trims") the list selector and outputs "dog cat". Or do you mean, why doesn't it have a list method and understands that you have a list and then must route according to the first element?

Well, as to why it is as it is, I just looked at the code. I had a guess that it was just overlooked, so, a bug, a mistake. But I see now there was a clear intent to trim the list selector, and, I don't know why, it doesn't make much sense to me, I have to agree. It seems it wanted to to data type routing, as it can do [route float], and also pointer, but then it just failed with the list data type.

So as I see there were some bad design choices/mistakes, but Pd is very conservative and careful on this sense, and some real and clear bugs are documented as is, check [bendin]/[bendout].

As someone who designs lots of objects, I can see how even if we try hard, we always tend to find some mistakes and regret some choices. This is why ELSE has been on "experimental" mode for almost a decade. I just fix and change the behaviour and design, but this opposite extreme is also bad and I will finally stop doing that when PlugData 1.0 is out, which might happen this year and then I'll just have to live with some screw ups.

But hey, I think that ELSE fixes and deals fine with routing elements like [route], or data types, or the whole message with [routeall]

[route] only matches to the 1st element, and passes the rest of the message. It would more properly need to handle lists... in the case of a symbol, it's kinda pointless to send it to route, as you can only have a bang output, and this is not the purpose of that object. It is the point of the [select] object though.

I don't think this is an issue for [route] at all. Having said that, [route] has many issues. It has inconsistencies (like how it doesn't trim the symbol selector). I don't debate about its bad design. That's why I wrote [route2] and I also have [routetype] and [routeall]... in [route2] it can manage a list message and route the rest.

This is not about the language concept and design, it's about the object design. I see design problems in many object, but hey, help file is there to show how the object works one way or another, even if it has inconsistencies.

@FFW why is the text all messed up and overlapping in your system? I mean, here on my mac (where I wrote it) it renders fine, I thought it was supposed to look the same everywhere. What is your system?

@whale-av said:

Maybe that could be described as a bug, as I cannot see that anyone would ever have used it for any purpose, and it can cause problems

well, just to add to the discussion, this is not a bug at all. It is a feature of Pd that is meaningless for this object, and it is also meaningless or very silly to other objects. It's just that disabling this feature for this object would be quite work, as you'd need to create a special handling of a list method.

This feature just bypasses the need of the [unpack] object. If you wanted to have a list unpacked and then distributed to both inlets of [sel], that wouldn't be a bug, just something not really meaningful or useful. There are many silly and meaningless things you could do in a Pd patch, it doesn't mean it's a bug or something.

@whale-av said:

Try things out with pd-selector.pd

hey, I see you're using [route] and [select] with many messages and trying to explain the results. What example do you have here that is not included in the help file? Also, I see you're sending a list message to [select] and to me it implies that it some how understands and deals with list message, which is not true, and is not documented either.

What happens there is what happens to any pd object when you send it a list and it doesn't expect a list method, it splits the list and distributes it to its inlets. So what you're doing is rewriting/replacing the argument in the right inlet.

This is why if you try to send 11 23 into [select me] you will get the error "inlet: expected 'symbol' but got 'float'"

@whale-av said:

Try things out with pd-selector.pd

Hi, you seem to have created some sort of abstraction that makes [route] match to list messages, huh?

Well, if that's the case, let me tell you all about [else/route2], which is also part of PlugData. I guess it can do all the things that people would expect [route] to do and this is why I wrote it.

I guess it's not clear from the description it can route to the first element of a list message, I will improve that description now.

@gentleclockdivider said:

So please stop assuming I didn't read the manual

Did you read the things I told you to right now? Are they clear? Don't they answer you? If not, how can I improve and explain it to you? what don't you get from it?

Sorry if I'm assuming wrong, but it'd be good if you showed that you read something and couldn't find your answers. And you know, sometimes we need to refer back to the docs to check something, so reading just once is not enough. You can post this on facebook, I'd answer the same thing.