@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...

@gentleclockdivider I think that excerpt from the manual kind of gets overly technical, depends on how earlier parts of the manual handle things. Technically, everything in your patch is either a float or a symbol but selectors tell objects how they should treat it and if the object does not see a selector it recognizes it prints an error to the console. Selectors are not types, more like methods and I sort of used "selector" as type and made methods separate. The symbol selector has one argument, a symbol and each object treats the first item in a message as the selector to tell it how to deal with its arguments.

Perhaps @porres or another dev will chime in on selectors vs methods in pd, both are used in the help files, are they interchangeable? Should they be unified or distinguished better? That excerpt muddles the distinction, if there is one.

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

Because those are three separate messages each being sent to [list] in order from left to right, [list] is one of the objects with no methods and applies the appropriate selector to the data it receives. Try that with an object which has methods like [list store], won't work, you will get three errors.

To be fair , I think pure data is a million times more complex than supercollider or anything else I have worked with

for years I had that same feeling about pd, spending some time in vanilla pd with no externals helped a good deal, got me over the hurdle with understanding the quirks of pd and dataflow.

@oid said:

@gentleclockdivider said:

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

No, it is just a message, to be a symbol it would need the symbol selector. We have three selectors; float, symbol and list, when an object gets a message it checks for those selectors to make sure it is getting the correct type of data, if it lacks one of those selectors it treats it as a method like 'set' so your [list store] knows it should set its internal state instead of operate on the data and produce output. The alternative would be to have reserved words which you would have to escape or add a selector to, so if you wanted a [list] to store the message [set 1 2 3( you would have to do [list set 1 2 3( or [\set 1 2 3(. The pd way avoids reserved words which means we don't have memorize a long list of reserved words, just the three selectors and the mostly consistent ways they are handled.

Next , the message c3,f3,a3 , three messages after each other each with a symbol identifier

None of those have a symbol selector, those are just three messages. You can run those through a [symbol] instead of a [list] and for this sort of thing that is a good idea, explicitly states that it is a symbol so you don't have to trace the patch to figure out what is going on.

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 ?
When the message is separated by commas , and send though a list , the console clearly shows these are seperate symbols , why then ?

To be fair , I think pure data is a million times more complex than supercollider or anything else I have worked with

Manual :
quote

Messages contain a selector followed by any number of arguments. The selector is a symbol that defines the message type. The arguments are anything that follows and may be symbols or numbers (aka atoms). For instance "list a b c" has a "list" selector, which defines the "list" data type, and "a b c" is the actual message. This message is only composed of symbols but a list message can combine two or more symbols and/or floats.

unquote

@gentleclockdivider said:

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

No, it is just a message, to be a symbol it would need the symbol selector. We have three selectors; float, symbol and list, when an object gets a message it checks for those selectors to make sure it is getting the correct type of data, if it lacks one of those selectors it treats it as a method like 'set' so your [list store] knows it should set its internal state instead of operate on the data and produce output. The alternative would be to have reserved words which you would have to escape or add a selector to, so if you wanted a [list] to store the message [set 1 2 3( you would have to do [list set 1 2 3( or [\set 1 2 3(. The pd way avoids reserved words which means we don't have memorize a long list of reserved words, just the three selectors and the mostly consistent ways they are handled.

Next , the message c3,f3,a3 , three messages after each other each with a symbol identifier

None of those have a symbol selector, those are just three messages. You can run those through a [symbol] instead of a [list] and for this sort of thing that is a good idea, explicitly states that it is a symbol so you don't have to trace the patch to figure out what is going on.

@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]

@gentleclockdivider When you need to turn a list into a message remember that the only difference between them is the list has a list selector so [list prepend set] -> [list trim] will do the same and save you from endlessly having to add and remove dollar arguments from your [set $1 $2 $3...( messages as your list length changes, and it also works with listbox since it also has the set method.

If you are dealing with lists, uses list objects even if you are trying to turn that list into a message, it will make life easier and often you find you don't even need the message, the list objects will handle it all. Despite being able to click on them messages are not actually UI objects, hence their not showing up in GOPs, they are for constructing those internal messages which lack selectors like all those methods for [list store] and why they produce an error if you click on one with a dollar argument in it and needing a list or symbol selector in them when you want to use them for a list or a symbol.

How can I actually see the routed list in a list box without using list store ?

If you look into the help file of the list box, you'll see that the list selector is always needed if the list starts with a symbol. So you need to convert whatever you wanna see to a list message, and the help file of [route] uses the [list] for that.

So, it should be obvious that you simply can't send a non list message to the list box. If you're asking how should it work without [list store], well, you can't, you need something. If you want an alternative to it, what is the problem with it? What else would you like and why? And if you expect somehow to send a non list message to list box, you simply can't and this is a very basic Pd thing, dealing with its data types. So use just use [list] or whatever...

As for the dollar sign thing, it's also another very basic Pd thing that concerns the management of selectors and data types, and it is treated throughout the documentation, one of which is the help file of [list].

So yeah, this is yet another request on my part to kindly insist yet once more, after many times, that you take your time to read the manual and help file of objects if you want to work with Pd. You've been using it for quite some time and you have too many questions that could be simply be answered if you took the time to read tutorials, the help files and the manual.

And simply don't expect Pd to be the same as MAX, they're different pieces of software (there's even a section in the manual that tells about their differences - it's section "2.11. Pd vs. MAX"). While you're at the manual, check "2.4.1. Message types (selectors) and numerical precision".

As for the help files, I told you to check the help file of all these involved objects, the list box, the [route] object, and the [list] object, which has a [pd about-lists] subpatch that should answer your question.

The help file of message boxes also talk about dollar expansion and has a section that explains all this in a subpatch called [pd dollar-variables].

The fist chapter of my Live Electronics Tutorial is "01-Pd.Quickstart" and gives you a good and quick overview, you should look into subsection "2.Syntax". This comes as part of PlugData, which you're using. I realized now that the 'control tutorial' does not have a good example about this, so I will add it. You should read that too anyway.

So yeah, I'm not really answering your question, but I'm telling you where you can find answers, and please understand my situation. I wrote a tutorial of my own, I revised and rewrote all the help files, I revised, wrote new sections and rewrote most of the Manual. I revised the tutorials, all in the hope that people would read them and find answers and not ask such basic questions over and over. And also so me or others wouldn't have to keep explaining the basics. Others can come in and teach you if they want to, but I'll just reinforce that you really should do that.

This is ok when someone just got here, is a newbie, and wants some guidance, like pointers to the documentation, but it's been a while you joined the community, and you're doing a lot of work, and you seem to resist and simply not do the basic homework. Personally, I feel this is abusing our desire to help others, but that's just me.

So please, just read the (blip) manual. And if you're still confused, if you haven't found what you need, if it's misleading somehow, I'd be more than glad to explain it to you and improve the documentation.

I'd love to hear from you things like "hey, I read this help file and I couldn't see something about xxxx", or, "I didn't find anything about message types in Pd, where can I read and check?". You know?

cheers

I'm currently not in any condition to reply coherently, but my thought was that either you assume that a non-numeric leading atom is a selector or a symbol. Max (taking the OP's word for it because I'm Max-ignorant) assumes it's a symbol, and Pd assumes it's a selector. So it's just a choice that inconveniences those who think it should've been the other way. Please let me know how I'm wrong!

Edit: for instance (feeling irrationally emboldened by this example I just thought of), think about the set message for symbol boxes. If the leading "set" was interpreted as a symbol, then you'd lose the the "set" capability unless you added a new (potentially inconsistent) language construct.

PLEEEZE, I'm not arguing that Pd is consistent, I'm just sayin' that there are hard choices to make in language design.

@gentleclockdivider List and symbol objects apply their selector to anything sent through them, the exception being [list store]'s right inlet which has to deal with methods like [set 1 2 3(. The selector tells the object how it should deal with the incoming data. You can just use [route - kick hat] instead of [select] and have it work just like in the Max/MSP version but then you will need a [list trim] after your [list store] to strip the symbol selector. Or you can just put a single [symbol] before the [select] and just run everything through it including the [list store] which is safer than individual as needed [symbol]s, won't have to worry about selectors at all this way.

Sometimes pure data is really doing my head in and feels so counterintuitive
At the leftt there are three message boxes "-" "kick" and "hat " ..in Pure data world these are are (implicit)symbols.
The select module however does not identify these because there is NO symbol selector , this feels so counter intuitive .
When sending a list through a list store and retrieve the individual elements , a symbol selector is automatically added since the select module accepts these