Is this correct? I thought 'symbol' was just a tag that shouldn't alter the behavior of the data.

0917-sym-route.pd

hjh

@whale-av [list] does convert [all( to [symbol all(.

@ingox Yes...... top right in the screenshot above.
David.

@ingox Yes...... the same rule applies as for [route] ...... a tagged list of one symbol is converted to symbol.

Time to do a thorough analysis of [select] then......... but there is a lot more to unwrap because symbols and floats can...... sort of..... be mixed as arguments if tagged.
And worse (although sometimes useful I suppose) a second atom of a list goes to the right inlet of [select] when there is only one argument........ so [list all no-go(
...... but [list all 25( works as the creation argument is a symbol so cannot be changed to a float.
David.

@whale-av Yes, sure.

My opinion is that the whole selector system is dubious. [abc( should just be a symbol.

But since it is how it is, [list] gives the opportunity to use simple messages in your patch and convert them to symbols or else when they enter an abstraction. [list] together with [route] can make a simple filter after the inlet to get control over what is coming in to an abstraction.

I got confused by two seemingly contradictory comments here:

ingox: "In that case [sel all stop] can help. But it cannot deal with [all(..."

Obineg: "sending 'foo' to [select foo] works as expected"

From these, I'd have to conclude that one of the following is true:

A- a message consisting of a single untagged symbol doesn't match in [select], and the second quoted comment is mistaken (neither "all" nor "foo" would match);

B- most symbols match in [select] (hence "foo" would be ok) but there's something special about "all" that select doesn't like.

"A" seems more plausible... but ingox's remark could also mean that "stop" is ok while "all" is not (B)...?

[list] --> [select] is a useful trick.

It's a bit tricky that [route values...] matches the first item (which it kinda has to) while [route types...] matches the type of the entire message. That threw me off at first. It sorta makes sense though.

hjh

@ddw_music
does not work

@ingox said:

My opinion is that the whole selector system is dubious. [abc( should just be a symbol.

Yes. "all" is not special...... it is just that any single atom text is treated as text unless tagged as a symbol. A great source of confusion and changing that would be good.......
But it is not special....... it will trigger a bang through [route all] just like any other single atom text...... but will not trigger [sel all].
At the moment a single atom text will [route] and produce a bang........ but for it to trigger [select] it must first be tagged as a symbol........ crazy....

The other sources of problems can be that an automatically tagged list........ a list starting with a float..... can require a [list trim] before being passed on...... although for the user there is no indication that the message has had the list tag added.
And that a list of two symbols although routed correctly loses the symbol tag for the second atom when passing through [route] because it has become a singleton and reverted to text.... ...... That issue would also be addressed by your suggestion.

So yes....... a singleton text should be a symbol....... and can still be a selector that will trigger a bang.

Consistency between objects needs addressing and the selector system would be fixed I think.
And single atom text being a symbol might be all that is required, if any single atom is treated as a selector in the same way as any first atom is currently and [list] is made consistent between atom types.

We have had this discussion previously...... https://forum.pdpatchrepo.info/topic/12794/route-list-vs-array-problem/15

But nothing can actually be done without a serious plan....... we are wasting our time except when we document these anomalies.
The elephant in the room is the millions of patches already in existence.
If we can work out how to make the changes we would like....... without any changes to those existing patches being necessary..... then we will have a proposal for the list....

That might be possible........ but I think that the current inconsistency of the triggering of a bang will put a spanner in the works.
So maybe only alternative objects..... [routeNEW] [selectNEW] etc. would be possible while continuing with the old message system..
David.

[ab cd( should also just be a list.

But it is not and i have accepted that Pd has its quirks. I look on the bright side. It is so bright that my eyes hurt.