Hello,
Newbie question, but a frustrating one I haven't been able to solve on my own yet.
I can send a message, e.g. [gain 0.1] to [route gain] which gets through nicely. But after packing a symbol and float (from an OSC message), resulting in [list gain 0.1], this gets rejected by [route gain]. What am I not understanding here, i.e. what am I doing wrong?
Thanks!
Steve

@stevewhite
Out of pretty much a lucky try I figured out I should just remove the 'list' with [list trim] before sending it to [route].
It seems pretty dirty to me, so if there is a cleaner way, I'd love to hear!

@stevewhite "Out of pretty much a lucky try I figured out I should just remove the 'list' with [list trim] before sending it to [route]."

I believe this is documented as the correct way.

hjh

thats true, otherwise you can send it through [route list], which isnt the wanted result.

I've always thought of this bit of arcana as a way distinguish between, for example, "gain 0.1" as a command vs the list of atoms that comprise that message, similar to how "symbol bang" isn't an actual "bang". Is that right? If so, what's a compelling example of why this distinction is useful and necessary? I can't think of a vanilla object that takes both on the same inlet but behaves differently depending on which it receives. I thought maybe the list manipulation stuff would, or netsend, but no.

@jameslo i made this example recently that makes use of [route float] (i do not think it is compelling ).
parsingScript.pd
sometimes it makes sense to route atom types and not a certain symbol or number.
i also think it is the only object where it makes sense (perhaps [sel] would make sense too, but you can simulate a [sel bang] easily with [route bang]).

@Jona Well, OK, [pipe] is a compelling example of why one would want to route float, because floats are what the pipe acts on, but "flush" and "clear" are commands to the pipe. But I don't think there's something like that for lists vs commands with 2 or more atoms. For route & select, I get that if you're going to allow one atom type then you might as well include them all. But I don't understand why list and pack explicitly prepend the list selector when no other object seems to leverage the distinction. Which is why I frequently forget about having to use [list trim].

Apologies to @stevewhite if I've hijacked your thread

@jameslo I agree. I think the atom concept is flawed and could have been solved better. A concept like JavaScript has it where types can be implicit would have suited Pd better. But this is a core feature, so we just have to live with it.

@jameslo Or suggest you idea here: https://github.com/pure-data/pure-data

@Jona A concept with implicit types would break many old patches, so i don't think it will ever come or it would be a fork that is not compatible with Pd. A solution could be to create some new objects that don't care about the type, so a new [route] and [list] and [symbol]. Don't know if this is reasonable.

@ingox that makes sense (perhaps the best to live with it?). could it be that the most current github issue is related? https://github.com/pure-data/pure-data/issues/990

"sidenote: i think the entire idea to use symbols (s, f, pointer,...) to denote the type is somewhat broken in the first place. but it's been there since before some of my students were born. i guess we will never be able to change it."

@Jona Yes, this is somewhat related as the whole concept of default values in Pd is also flawed in my opinion. In other languages you can have empty variables and you can check if a variable is empty. That would be handy in Pd too.

On the other hand it may also be a matter of opinion. There are strict languages where you have to explicitly define the type of your variables and "loose" languages like JavaScript where the language does type conversions for you.

Pd's concept is somewhat inconsistent in some places, but you can work around those issues in most cases. It is just a little bit inconvenient sometimes.

Anyhow, in many cases [list] can help, as it does type conversions.

[something(
|
[list]

gives "symbol something".

@Jona @ingox Just to be clear, I'm not suggesting any changes--this language existed almost a decade before I started using it and I know how hard it is to change APIs even when there is only one stakeholder. I was just hoping there would be some vanilla object that differentiated its behavior on the presence of a "list" selector so that I would never again forget to trim it. Maybe this discussion served that purpose.

But I can't resist piling on. The silent substitution of 0 for all division by zero operations is outrageous by normal language standards. But again, don't go changing! Stay beautiful, PD!

BTW, I wouldn't be surprised if the strong typing in Java, c#, c++, and c has saved me hundreds of debugging hours, so I wouldn't be in favor of a duck-typed PD. The irregular, spaghetti-ish nature of these visual dataflow languages is freedom enough, thank you.

@jameslo said:

The silent substitution of 0 for all division by zero operations is outrageous by normal language standards.

That is true. [expr] does give an error though...

This could actually be changed. Maybe this deserves a github issue.

@ingox The big no-no for me is how list....... which after all is just a tag to let a left inlet know to distribute the list across its inlets....... is limited to a list that starts with a float.
A list that starts with a symbol is handled completely differently..... with an assumption that it is not a "real" list.
So for example [route float symbol list] applies that rule and breaks the message handling.

Even message boxes will handle a float as $1 but not a symbol unless there is an explicit list tag.....
route-help.pd (bottom left..... my favourite).
It seems float is implicit.
Symbol can be once run through an object....... but sometimes needs to be defined.
And list will always be a mess defined so narrowly.
David.

@whale-av Haha, great overview over the inconsistencies of Pd's atom system. I agree with all you said.