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

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

Oh yes I use route - text define etc..and am aware of the list trim feature
It's just that these small differences between max and pure where imho Max feels easier to use .
Why does max select object just accepts messages like kick ,- ,hat etc...?

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 What would happen if someday the devs decided to add methods to [select]? it would end up breaking any patch which used [select] to match symbols without the symbol selector. You have to pick a path and stick to it or you end up with objects with exceptions and we have to memorize all those exceptions or constantly get bitten by them.

Under the perspective of writing the code, making the object convert a non symbol message to a symbol is kind of a pain in the ass, and this was done on some occasions as an exception for convenience (like sending something to a [symbol] object's left inlet).

having a data type for symbols and lists make sense, as these are special data types..

How can I actually see the routed list in a list box without using list store ?
Using the symbol just shows the first element ,
In max , we can just use the right inlet of a message box
I coul d use the set $1 $2 $3 $4 etc.. message but that's a lot of typework



And just noticed that set $1 $2 $3 $4 discards the first element

I mean , does anyone understand why some of the thing just don't make any sense to me

@gentleclockdivider Put a [list] before your [set $1 $2 $3 $4 $5(
David.

@whale-av said:

@gentleclockdivider Put a [list] before your [set $1 $2 $3 $4 $5(
David.

And apparently that's also the solution to my previous question .
So what comes out ouf the route if it's is not a list , becasue we need to insert a list object to see it in the list box ?
I just keep struggling with these small things like forever

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

@gentleclockdivider said:

I just keep struggling with these small things like forever

Try reading what I told you to check out. If you still have questions, let's talk.

@porres said:

So

I did read the manual , read the bang book , miller s puckette electronic music journal , Kreidler etc..
Please don't think I just glanse over certain sections , it's just that certain parts are used more heavily then others .and other areas are easier forgotten when not in rotation/practised ,, an some parts (selector identifier ) are still a bit of a grey area to me .
So please stop assuming I didn't read the manual , I would have never been able to make the stuff of the past year without reading the manual ( and I am talking purely about scheduling and events , not audio dsp )
I respect all the hard work you have done and still do ( mutable port is awesome 0 ) , you have made your point countless times ( and I won't be posting on facebook anymore )
I have no problem helping people out ( did that for decades on the reaktor forum ) , I ve been helped countless of times on the supercollider forum ( yes I did read the immense manual ) no one made a problem out of it .
For some reason you have a problem with it , I stopped crossposting like you suggested but you can't make me stop asking questions , be it here or on discord , and No I won't crosspost ( since you're everywhere you will probably notice )

@gentleclockdivider This might help...... tag.zip
Try things out with pd-selector.pd
I called the [route] problem a "bug" in the zip, but that is not the case. It is awkward to deal with though.
It was work in progress a while ago.
[rawprint] is one of my "must have" externals. It prints detail of the atoms comprising a message.

You will see in that patch at the bottom left that a message [list me 10 woof( will not behave as you might expect ....... because the first atom in the list (me) is a symbol.... so [list] is sometimes necessary... as @porres says in the previous post...
David.

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

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

@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'"

@porres I cannot remember to tell the truth as it was a long time ago. Yes, I believe what started my "investigation" (learning session) was finding that a list could be distributed across the inlets....which surprised me for this object.
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.
David.