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