...

I just can't see how there could be any problem, or, in other words, I can't see how $0 becoming "0" in messages is a desired feature or if

anyone

...

could rely on this behaviour.

"0" certainly isn't a good behaviour.

What would be the good behaviour, in this case?

...

But, if there's any concern or resistance to this, no problem, my alternative would be to create an external that would do that. but then

I'd

...

like to know here first where should I aim my efforts, if to a Pull

Request

...

to Vanilla or to an external design.

like mostly, i'm opposing. this has been discussed about 15 years ago, and my arguments still stand (mainly: consistency with dollar-parsing throughout Pd)

Yes, but there is no consistency either now. So the question would be: is the current inconsistency a productive one (do people benefit from having a 0 there), or would people benefit more from having an inconsistency that provides them with a new useful feature?

For me, I can't count how many times I had to add a [$0], or a pack or some extra workaround before a message so that I could send messages to my variables (I hardly use variables without a $0).

Joao

like mostly, i'm opposing.  this has been discussed about 15 years

ago, and my arguments still stand (mainly: consistency with dollar-parsing throughout Pd)

Yes, but there is no consistency either now. So the question would be: is the current inconsistency a productive one (do people benefit from having a 0 there), or would people benefit more from having an inconsistency that provides them with a new useful feature?

I can see the argument (no pun intended, haha) here where $1 $2 (and $0 included) mean very different things in non-messages (patch arguments where $0 is the internal/default argument) vs messages and having $0 resolve in messages as it would in objects could be quite confusing as we're mixing two worlds (and then users would perhaps expect $1 $2 and so on to resolve similarly but they don't). So the matter of consistency would be in message world and non-message world where $0 is just simply out of range in message world (as $100 would be if your incoming list doesn't have 100 atoms).

Note that this opens the can of worms of not only message boxes but also things like [text] where $0 behaves as it does in messages boxes.

For me, I can't count how many times I had to add a [$0], or a pack or some extra workaround before a message so that I could send messages to my variables (I hardly use variables without a $0).

Joao

I do face this too where I use $0 with all my [v]s and [s]s and [r]s and it does get to be a bit tedious BUT I'm not quite sure if mixing the two worlds and their rules are worth it...

I also added that feature in my fork "Spaghettis". It is very handy. For now i have not found any situation that make me regret that "inconsistent" behavior.

https://github.com/Spaghettis/Spaghettis

Mainly tested on MacOS for now. Best to open a new thread if you have more questions.

----- Mail d'origine ----- De: Alexandre Torres Porres porres@gmail.com À: Nicolas Danet nicolas.danet@free.fr Cc: João Pais jmmmpais@gmail.com, Pd-List pd-list@mail.iem.at Envoyé: Mon, 02 Apr 2018 16:18:42 +0200 (CEST) Objet: Re: [PD] suggestion: $0 in messages

2018-04-02 9:02 GMT-03:00 Nicolas Danet nicolas.danet@free.fr:

I also added that feature in my fork "Spaghettis".

what's and where's that? :)

...

For me, I can't count how many times I had to add a [$0], or a pack or some extra workaround before a message so that I could send messages to my variables (I hardly use variables without a $0).

I can't count how many times I had to loop back the outlet of a [+ 1] to the right inlet of a [f ] to build counter.

You can use [jmmmp/f+], it's prepared to avoid such repetitive tasks. Or,
you can request for a new object be part of pd vanilla, since this is an
operation that I would bet 99.9999999% of users come up to sooner or later.

Apparently, you need to figure out the creation argument first before you build a message using it. I don't see anything specially tedious about this process.

You can, but is it really necessary to add more objects for something that
could be easily solved by the language? The point isn't that something is
impossible to do now, but that it would make work much easier.

Why is nobody complaining about not being able to use the third creation argument directly withing a message? What's the fuzz about the $0?

Maybe because the $3 of a patch is most likely used a fraction of the
times compared to $0. If your patch doesn't have any abstractions, there's
no $3 to use.

From patching I know that it would be far more convenient to be able to reference the patch-local $0 variable in messages.

Perhaps in that case there should also be a [selector] object that reports the selector of a message? getting it using [route] seems unnecessarily complicated..

On the other hand, having $0 represent the selector would be the most consistent solution, because you can not get other patch-local variables or arguments in message boxes, and yet you can use $1 $2 etc. to refer to the elements of an incoming message. So the behavior of dollar signs in object boxes and message boxes is already separate and have very different uses. It almost would seem more confusing to be the same for just 1 of the dollar sign numbers, yet different for all the others.

-Seb

-----Original Message----- From: Jonathan Wilkes via Pd-list pd-list@lists.iem.at To: pd-list pd-list@lists.iem.at; Roman Haefeli reduzent@gmail.com Sent: Wed, Apr 4, 2018 1:00 am Subject: Re: [PD] suggestion: $0 in messages

Why is nobody complaining about not being able to use the third creation argument directly withing a message? What's the fuzz about the

$0?

$0 isn't part of the argument vector. It's a unique id automatically generated for a patch/abstraction which the user happens to access through a dollarsign variable.

That locality hack doesn't require that the unique id be fetched by an unused dollarsign arg. For example, you could reserve the keyword "let" such that a message box with "let token2" would get converted behind the scenes to "1003-token2".

When users for a decade have said they wanted $0 in msg boxes, they mean that they want to use Pd's notion of send-symbol locality inside message boxes. They want that instead of manually querying the value of a reserved dollarsign variable and sending that value to the relevant message box in order to get "let" behavior.

Also, since "$0" is already being used for this purpose it doesn't make much sense to try to also get "$0" to refer to the selector. You'd end up with inconsistent meaning where it fetches the selector in msg boxes but not in object boxes. Plus you can already get the selector of an incoming message with [list] whereas you cannot get an abstraction's selector (which would be handy for error reporting). So adding that inconsistency would only duplicate existing functionality without adding new functionality.

-Jonathan

Roman

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

What is wrong with [my_selector(--[list]--[$1(

for instance, [42(--[list]--[$1( will give 42 not float, similarly [symbol crabs(--[list]--[$1( will give crabs not symbol Also it seems reasonable to just have 1 object box for querying a selector, which is a main element of the pd message environment.

...

On the other hand, having $0 represent the selector would be the most consistent solution, because you can not get other patch-local variables

or arguments in message boxes, [...]

I don't understand what the word "solution" means here. If users

have repeatedly requested msg box $0 to expand to glist's ce_dollarzero, why would Pd Vanilla give $0 in msg boxes a different function that is incompatible with object box $0?

here "solution" means a good way to resolve $0 in message boxes.. I don't think what users request is necessarily the end all of reasons to implement a feature in a language..

and again, the reason that $0 would be different in object boxes and message boxes is because everything else already is different in object and message boxes

I don't understand this whole thing about getting the selector of a message to a msgbox and why this could be a useful feature. can someone give me a real world example?

when I have a msgbox like [foo $1 $2 $3 $4( I expect the input to be a list of (at least) 4 atoms which is then expanded. [foo $1( expects a list of length 1 - why should I care about the selector? if I need the type of a message for my program logic, this can already be done with [route] (with anythings to [list split 1]-->[list trim]).

so I think expanding $0 to the selector - although reasonable from a theoretical point of view - would be rather pointless in practice. I agree with people pointing out that $0 in object boxes already has nothing to do with the argument list and is an inconsistency in itself so I think it's actually quite consistent to also introduce it to msgboxes :-). needless to say that I would find it incredibly handy.

Pd users have been accepting the fact that $0 in object boxes expands to a unique canvas ID for decades now. why do some people think introducing this behaviour to msgboxes could confuse anyone? on the contrary: new users are often surprised that it *doesn't* work the same way as in object boxes.

BTW: I think it's unfortunate that msgbox allows 'anything' messages at all.

Gesendet: Donnerstag, 05. April 2018 um 17:44 Uhr Von: "Jonathan Wilkes via Pd-list" pd-list@lists.iem.at An: pd-list@lists.iem.at, "sebfumaster@aol.com" sebfumaster@aol.com Betreff: Re: [PD] suggestion: $0 in messages

...

What is wrong with [my_selector(--[list]--[$1(

for instance, [42(--[list]--[$1( will give 42 not float, similarly [symbol crabs(--[list]--[$1( will give crabs not symbol Also it seems reasonable to just have 1 object box for querying a selector, which is a main element of the pd message environment.

That makes sense.   Are you after the literal selector in this case, or the one that the documentation implies should be there? For example, if I feed a list with a single floatarg (e.g., "list 42") to [selector] does it tell me the selector is "float" or "list"?

...

I don't understand what the word "solution" means here. If users

have repeatedly requested msg box $0 to expand to glist's ce_dollarzero, why would Pd Vanilla give $0 in msg boxes a different function that is incompatible with object box $0?  > here "solution" means a good way to resolve $0 in message boxes..I don't think what users request is necessarily the end all of reasons to implement a feature in a language..   $0 in message boxes may be the most often requested feature for Pd. That certainly doesn't mean it has to be implemented.   But filling $0 with something completely unrelated is probably a good way to irritate your userbase for very little gain.   -Jonathan              _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

On 03/04/18 21:52, Jonathan Wilkes via Pd-list wrote:

When users for a decade have said they wanted $0 in msg boxes, they mean that they want to use Pd's notion of send-symbol locality inside message boxes. They want that instead of manually querying the value of a reserved dollarsign variable and sending that value to the relevant message box in order to get "let" behavior.

Absolutely. Given some of Pd's other quirks the $0 issue seems like a funny time for semantic purity. The forks have given people what they want.

Cheers,

Chris.

On 2018-04-05 13:44, Roman Haefeli wrote:

I already pointed out that dollar variables are a totally different thing in messages and objects.

they are very much the same (from Pd's POV).

...

whereas you cannot get an abstraction's selector (which would  be handy for error reporting).

What is the selector of an abstraction?

the name of the abstraction.

fgmasr dIOhannes

2018-04-02 16:02 GMT-03:00 Miller Puckette msp@ucsd.edu:

Well, I've been trying to stay out of this, but here's a thing... someone could implement a "msg" object that you could invoke like [msg 1 $0 3] to get a message with a 'true' $0 built into it. This would also work for $1, etc, so would be much smarter than changing the message box semantics.

But then the question is, how would you allow message-box-style $ substitutions? OK, we can do this:

[msg $1 #1]

which would be the exact reverse of Max's #1 convention - #1 could be the message-box $1.

I've shrunk from actually doing this, not just because it makes my teeth hurt, but also because... shouldn't this be expanded into a full-on scripting language? And what then would be its relationship with the expr family? It quickly got too deep for me to figure out what would be a good, canonical solution.

Well... if the idea was to expand Pd's message syntax, why not add #0, #1, etc... as a way to expand creation arguments in messages? It wouldn't be in reverse to Max (if that's any positive)... sure, there are backwards compatibility concerns, but it feels it was a good thing to have.

But yeah, since IOhannes' "no" and me accepting the fact the current behaviour remains so as the result of a conscious decision, I've started working on an external, and much inspired by max's message box. But not being a max user, I did know about "#1" there.

Anyway, by getting my hands dirty on it, I realized how "$1" would naturally expand to arguments, and hardly would expand to message's input (maybe possible with some ninja tricks, but maybe not even possible). Then I thought both ways could useful in a message, so it became this deal not only about "$0" anymore... and also the fact that, Ideally, there would be two different prefixes for message expansion and creation argument expansion.

So I was looking for a syntax to refer to message inputs as well. By considering the [expr] way of doing such a thing (with "$f#" and stuff), I thought a generic "$a#" ("a" for "atom", symbol or float). Though I kinda like the "#1" idea now that you mention it, haha, even though if reversed if compared to max... but yeah, something like "$a1" looks more "PD-ish", right?

In any case, I welcome any kind of feedback!

cheers

cheers Miller

On Mon, Apr 02, 2018 at 08:55:58PM +0200, Roman Haefeli wrote:

...

yawn.....

On Son, 2018-04-01 at 17:42 -0300, Alexandre Torres Porres wrote:

...

Hi, currently, if you want to use $0, you need an object cause it becomes "0" when it's inside messages.

Pd-l2ork and Purr Data implemented a way that $0 works in the same way as in objects than in messages, and I think it is a great feature, as many patches can be significantly simplified. I guess most Pd users here know what I'm talking about.

By implementing that, you would once forever prohibit the proper way to expand $0 which is expanding to the selector of the message. That's why I oppose your proposition. (Actually, it doesn't matter whether I'm opposing it or not since I don't contribute any Pd code. But I can at least point to the fallacies.)

I absolutely see the convenience of your proposition, but there would be no good explanation for it. Consider it a bad coincidence that both kinds of variables use a dollar prefix, there is nothing in common between them (expanding to creation arguments versus expanding to atoms of messages). Personally, I would totally find it convenient if Pi was an integer number, it would make so many things so much easier.

Roman

...

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/

listinfo/pd-list

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list

yes, great to say that, chris: thank you so much miller for the wonderful pure data!

hans

Am 05.04.2018 um 12:53 schrieb Chris McCormick chris@mccormick.cx:

Anyway, I'm sorry to conjure up the spectacle of another several decades of challenging software development and maintenance work. We probably don't say this often enough around here: thank you very much for Pd, Miller.

Cheers,

Chris.