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

0917-sym-route.pd

hjh

@ddw_music the "selector" is simply the 1st element of a message. Sometimes they are hidden, or implied (as in many "float" messages)
see here for a discussion: https://github.com/pure-data/pure-data/issues/1302
(the help file for [route] has already been updated for the next release regarding this)

@ddw_music The old extended route-help explained the 3 modes for [route]...... route-help.pd in the "inlets" section.
And there was a bit more info in all_about_route.pd especially that the list header is stripped and so [route list] followed by [route list] will fail for the second.
But mixing data types in a single [route]..... i.e. [route 5 woof] will not work as expected..... so unsupported.
David.

Thanks.

Since this abstraction is already using cyclone, I ended up with this:

BTW the lack of [gate] in vanilla is one of those nagging "why the .... does Pd want to make things harder than it has to be" questions for me. IMO [gate] is as fundamental as [route]. (Yes, I know you can simulate [gate] by [list prepend]ing a number and [route]ing... but then, as I've been advised elsewhere, [list] ops incur a cost by copying... which I suppose you could avoid by multiple [spigot]s but that doesn't say much for usability.)

hjh

@ddw_music In that case [sel all stop] can help. But it cannot deal with [all(, so that could be protected against by using [list] before the [sel]. I also think that the whole selector concept is inconsistent and messed up.

sending "foo" to [select foo] works as expected, but in case you expected to route "foo" with it.... no. the first list element is always cut off, so [route foo] will just output "bang".

Yes, I think I covered all those bases in the posted patch (including the conversion of e.g. "all 123" to bang, rather than 123).

I wonder, though, what is the reason for [select] to choke on "all."

hjh

@ddw_music I think it is because [select] only works for floats and explicit symbols.

However,

[list]
|
[select all stop]

works.

@ingox To be auto-tagged as a list the list has to start with a float.
See [pd special_cases_of_lists] and then the part at the bottom left......... route-help.pd
You will see that as a list passes through [route] the list header is removed but if the list starts with a float it is always a list and goes through as such to the second [route].
Somewhere it is documented that a list that starts with a float is treated as a list even without the list header.

I think I added that help-file to the forum in May last year..... frustrated by [route] like @ddw_music
It's a bit messy though.
David.

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