I think you're extrapolating from your particular use case.
I would say most people use $0 for private variables/resources. In this case the very point is that those are not accessible from outside. If I do want to make things accessible from the outside, I wouldn't use $0 in the first place...
On 02.12.2021 14:25, Antoine Rousseau wrote:
Without the "$$" syntax, I wouldn't see the problem...
encouraging the use of $0 in messages, without allowing to easily substitute with [another way to identify the abstraction] $1?..
Le jeu. 2 déc. 2021 à 13:18, Christof Ressi info@christofressi.com a écrit :
So I think it's better to keep the $0/$n symmetry. I think having a "message" object is a better idea [than $$'s one] What I like with the $$ idea, is that it would provide a simple way to merge creation arguments with variable arguments, i.e compose a message with both the abstraction arguments and the incoming message elements.
I have to say I quite like the "$$" idea as well, assuming that we can take the risk of breaking a few patches (if any). I don't think it's a good idea to add a new object just for this functionality. For me this would create unnecessary complexity (you have to learn yet another object).
I'm not sure either. To me, both $0 and $1 etc. can be used to identify an instance of an abstraction. IMO $0 is the quick way, but has the limitation to make it (nearly) impossible to access members from the outside. That's why it often happened to me to rename an instance [myAbs] to e.g [myAbs myabs1], then to replace $0 in [myAbs] with $1, so I can easily access [myAbs]'s members from the parent - from anywhere in fact (Actually, nowadays I tend to use as few $0 as possible). If we could use $0 in messages, then the last operation would be more complicated (cause you couldn't simply substitute $0 with e.g $1).
I agree that if we get the "$$" syntax, then it makes more sense to use "$$0" for the $0 argument! Without the "$$" syntax, I wouldn't see the problem... One downside of using "$$0" is that it wouldn't be compatible with Pd-L2Ork / PurrData.If they have already diverged significantly, we probably don't have to care, but otherwise... _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
If you would like to test if $0 works inside messages as originally suggested by Alexandre, you can try pd-l2ork. This is what it has been using for quite some time now, although the use cases of $0 inside a message remain relatively sparse. Another consideration is that there is a bit of a CPU overhead in dynamically allowing $0 to be expanded.
Best,
Ico
Hi Ico,
I already made my own PR a few years ago: https://github.com/pure-data/pure-data/pull/347
Another consideration is that there is a bit of a CPU overhead in dynamically allowing $0 to be expanded.
AFAICT, my implementation actually *saves* a little bit of CPU because I cache the $0 value once in the message box constructor and then pass it explicitly to the new binbuf_doeval() function.
the current message box implementation calls binbuf_eval() which would query the $0 every single time (and we don't even use it :-)
Christof
On 02.12.2021 17:10, Ico Bukvic wrote:
If you would like to test if $0 works inside messages as originally suggested by Alexandre, you can try pd-l2ork. This is what it has been using for quite some time now, although the use cases of $0 inside a message remain relatively sparse. Another consideration is that there is a bit of a CPU overhead in dynamically allowing $0 to be expanded.
Best,
Ico
Ivica Ico Bukvic, D.M.A. Director, Creativity + Innovation Director, Human-Centered Design iPhD Institute for Creativity, Arts, and Technology Virginia Tech Creative Technologies in Music School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu
ci.icat.vt.edu http://ci.icat.vt.edu l2ork.icat.vt.edu http://l2ork.icat.vt.edu ico.bukvic.net http://ico.bukvic.net
On Thu, Dec 2, 2021 at 8:34 AM Christof Ressi info@christofressi.com wrote:
I think you're extrapolating from your particular use case. I would say most people use $0 for private variables/resources. In this case the very point is that those are not accessible from outside. If I do want to make things accessible from the outside, I wouldn't use $0 in the first place... On 02.12.2021 14:25, Antoine Rousseau wrote:
Without the "$$" syntax, I wouldn't see the problem... encouraging the use of $0 in messages, without allowing to easily substitute with [another way to identify the abstraction] $1?.. Le jeu. 2 déc. 2021 à 13:18, Christof Ressi <info@christofressi.com> a écrit :
So I think it's better to keep the $0/$n symmetry. I think having a "message" object is a better idea [than $$'s one] What I like with the $$ idea, is that it would provide a simple way to merge creation arguments with variable arguments, i.e compose a message with both the abstraction arguments and the incoming message elements.
I have to say I quite like the "$$" idea as well, assuming that we can take the risk of breaking a few patches (if any). I don't think it's a good idea to add a new object just for this functionality. For me this would create unnecessary complexity (you have to learn yet another object).
I'm not sure either. To me, both $0 and $1 etc. can be used to identify an instance of an abstraction. IMO $0 is the quick way, but has the limitation to make it (nearly) impossible to access members from the outside. That's why it often happened to me to rename an instance [myAbs] to e.g [myAbs myabs1], then to replace $0 in [myAbs] with $1, so I can easily access [myAbs]'s members from the parent - from anywhere in fact (Actually, nowadays I tend to use as few $0 as possible). If we could use $0 in messages, then the last operation would be more complicated (cause you couldn't simply substitute $0 with e.g $1).
I agree that if we get the "$$" syntax, then it makes more sense to use "$$0" for the $0 argument! Without the "$$" syntax, I wouldn't see the problem... One downside of using "$$0" is that it wouldn't be compatible with Pd-L2Ork / PurrData.If they have already diverged significantly, we probably don't have to care, but otherwise... _______________________________________________ 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
Em qui., 2 de dez. de 2021 às 13:19, Ico Bukvic ico@vt.edu escreveu:
although the use cases of $0 inside a message remain relatively sparse.
I say it's very common. Whenever we need "$0" for a send name, a table name or using messages as sends ;)
it is quite common to see [f $0] going into "$1" in messages, then we have a bang into [f ] and we need to click it instead of just clicking the message... it's messy...
On 12/2/21 18:35, Alexandre Torres Porres wrote:
Em qui., 2 de dez. de 2021 às 13:19, Ico Bukvic ico@vt.edu escreveu:
although the use cases of $0 inside a message remain relatively sparse.
I say it's very common.
that's funny. from my perspective (and i don't know anything, really) it *seems* that ico is speaking from the POV of someone who has been working with msgboxes that expand $0 for some time, whereas alex is mostly talking from a "wishlist" perspective.
as such i find it intersting that the two of you come to radically different conclusions about how *actually* useful that feature really is.
Whenever we need "$0" for a send name,
then i tyically use [send $0-foo], where there's no msgbox involved at all.
a table name
then i tyically use [array define $0-foo], where there's no msgbox involved at all.
or using messages as sends ;)
ah indeed. [; $0-foo init(
can't say i miss this much (but ymmv).
the *only* reason why i ever wanted to use $0 in a msgbox is for interacting with [soundfiler].
fmsd IOhannes
Personally, I often use $0 in large "initializer" message boxes:
[;$0-foo 10
;$0-bar 50
;$0-baz 10
etc.(
I like this better than creating dozens of individual [s] objects. The workaround is to use $1 instead and pass the $0 from a [float] object, but yeah...
It's also an issue when I want to create a message like this:
[read media/$1-$2.wav $0-buf-l $0-buf-r(
I basically have to append $0 to the incoming list and offset all dollars by 1:
[read media/$2-$3.wav $0-buf-l $1-buf-r(
It's just unnecessary mental overhead.
Of course, I could do this instead:
[list append read media/$1-$2.wav $0-buf-l $0-buf-r] -> [list trim]
But I find this ugly and unnecessary.
Whenever we need "$0" for a send name,
then i tyically use [send $0-foo], where there's no msgbox involved at all.
The message box syntax is often more convenient:
[;$0-array const $1(
Of course, I could just as well write
[const $1( -> [s $0-array]
but people are lazy :-)
IMO it is a real pain point. Otherwise this topic wouldn't come up again and again...
Christof
On 02.12.2021 23:09, IOhannes m zmölnig wrote:
On 12/2/21 18:35, Alexandre Torres Porres wrote:
Em qui., 2 de dez. de 2021 às 13:19, Ico Bukvic ico@vt.edu escreveu:
although the use cases of $0 inside a message remain relatively sparse.
I say it's very common.
that's funny. from my perspective (and i don't know anything, really) it *seems* that ico is speaking from the POV of someone who has been working with msgboxes that expand $0 for some time, whereas alex is mostly talking from a "wishlist" perspective.
as such i find it intersting that the two of you come to radically different conclusions about how *actually* useful that feature really is.
Whenever we need "$0" for a send name,
then i tyically use [send $0-foo], where there's no msgbox involved at all.
a table name
then i tyically use [array define $0-foo], where there's no msgbox involved at all.
or using messages as sends ;)
ah indeed. [; $0-foo init(
can't say i miss this much (but ymmv).
the *only* reason why i ever wanted to use $0 in a msgbox is for interacting with [soundfiler].
fmsd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
On 12/2/21 23:34, Christof Ressi wrote:
Personally, I often use $0 in large "initializer" message boxes:
[;$0-foo 10
;$0-bar 50
;$0-baz 10
etc.(
I like this better than creating dozens of individual [s] objects. The workaround is to use $1 instead and pass the $0 from a [float] object, but yeah...
i tend to prefer [list append $0] (or [symbol $0-buf] if in can be more specific) over [float $0], keeping the type of $0 opaque.
but anyhow, i personally have stopped using those large initializer mgxboxes long long ago - probably *because* they don't expand $0; but probably also because:
(or nearby) rather than with a msgbox "somewhere else". . if there's multiple init-states, i'd just go for a file-based state saver, and solve the problem entirely different.
It's also an issue when I want to create a message like this:
[read media/$1-$2.wav $0-buf-l $0-buf-r(
well yes. that's te [soundfiler] use case i acknowledged.
Whenever we need "$0" for a send name,
then i tyically use [send $0-foo], where there's no msgbox involved at all.
The message box syntax is often more convenient:
[;$0-array const $1(
Of course, I could just as well write
[const $1( -> [s $0-array]
but people are lazy :-)
how much lazy?
i find the latter more readable than the former for anything but idiosyncratic sending-msgboxes like [; pd dsp 1( so i'm totally fine with having an additional multiky-stroke (afaict it's really only a single Ctrl+1 that youhave to type more. and on my german keyboard i prefer typing "s" over ";")
IMO it is a real pain point. Otherwise this topic wouldn't come up again and again...
does it? there are obviously *some* people who feel a real pain and articulate it. it seems the Pd-list community is not very much into likes (and i myself are not on fb so i don't know what is happening over there), but your PR received 3 thumbs up. this is not exactly bad for our upvotes, but... maybe the pained people could just head over and upvote.
mgfsa IOhannes
I mean, it's definitly not the biggest pain point, but still. The problem is that all those (minor) inconveniences sum up eventually.
But maybe it's just my personal annoyance and most Pd users don't have a problem with it. Also, Miller really doesn't like this feature, so I probably should just give up :-)
On 02.12.2021 23:51, IOhannes m zmölnig wrote:
On 12/2/21 23:34, Christof Ressi wrote:
Personally, I often use $0 in large "initializer" message boxes:
[;$0-foo 10
;$0-bar 50
;$0-baz 10
etc.(
I like this better than creating dozens of individual [s] objects. The workaround is to use $1 instead and pass the $0 from a [float] object, but yeah...
i tend to prefer [list append $0] (or [symbol $0-buf] if in can be more specific) over [float $0], keeping the type of $0 opaque.
but anyhow, i personally have stopped using those large initializer mgxboxes long long ago - probably *because* they don't expand $0; but probably also because:
- if there's only a single init-state, i initialize within the object
s (or nearby) rather than with a msgbox "somewhere else". . if there's multiple init-states, i'd just go for a file-based state saver, and solve the problem entirely different.
It's also an issue when I want to create a message like this:
[read media/$1-$2.wav $0-buf-l $0-buf-r(
well yes. that's te [soundfiler] use case i acknowledged.
Whenever we need "$0" for a send name,
then i tyically use [send $0-foo], where there's no msgbox involved at all.
The message box syntax is often more convenient:
[;$0-array const $1(
Of course, I could just as well write
[const $1( -> [s $0-array]
but people are lazy :-)
how much lazy?
i find the latter more readable than the former for anything but idiosyncratic sending-msgboxes like [; pd dsp 1( so i'm totally fine with having an additional multiky-stroke (afaict it's really only a single Ctrl+1 that youhave to type more. and on my german keyboard i prefer typing "s" over ";")
IMO it is a real pain point. Otherwise this topic wouldn't come up again and again...
does it? there are obviously *some* people who feel a real pain and articulate it. it seems the Pd-list community is not very much into likes (and i myself are not on fb so i don't know what is happening over there), but your PR received 3 thumbs up. this is not exactly bad for our upvotes, but... maybe the pained people could just head over and upvote.
mgfsa IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Init message boxes and sends are a clear place where $0 expansion is beneficial. The reason why I don't use those in pd-l2ork anymore is because pd-l2ork has had for quite some time universal preset system (preset_hub and preset_node objects) that can pinpoint just about any basic object or an array even in situations where you have multiple instances of the same abstraction and differentiate between them. This means that a variable that exists in two identical instances of the same abstractions will each be identified as unique and different. Note that in the K12 beginner mode, that is unique to pd-l2ork, every abstraction has one or more presetable variables and users are not only able to but strongly encouraged to create multiple instances of each of those abstractions without having to worry about any of this (in that mode effectively every abstraction is treated like a basic object).
Best,
Ico
Em qui., 2 de dez. de 2021 às 19:12, IOhannes m zmölnig zmoelnig@iem.at escreveu:
On 12/2/21 18:35, Alexandre Torres Porres wrote:
Em qui., 2 de dez. de 2021 às 13:19, Ico Bukvic ico@vt.edu escreveu:
although the use cases of $0 inside a message remain relatively
sparse.
I say it's very common.
that's funny. from my perspective (and i don't know anything, really) it *seems* that ico is speaking from the POV of someone who has been working with msgboxes that expand $0 for some time
I have been too, but in my ELSE library, with my [message] object introduced in beta19 (now it's at 45), which is basically a message box, but inside an object box. I've had for more than two years now few years now and use it all the time. I also designed this cause I saw the need. Hence, I proposed the inclusion of the object as an alternative here.
then i tyically use [send $0-foo], where there's no msgbox involved at all.
Messages are good because you can have multiple addresses inside a single box and still control the order they're sent. In order to use [send] like that, you need a [trigger], plus the messages, plus the [send] objects. And if one of the messages you're sending uses "$0", well, then you also need a [float $0] and "$1" inside the message...
I know Pd doesn't need this if there's no way to do it unless we have, it's just very very convenient and useful...
a table name
then i tyically use [array define $0-foo], where there's no msgbox involved at all.
We don't need it also in [table] or even when we create a garray... the problem is with sending a message with the table name around, such as using it to change/set the table name of [array size], or every other object that you can set the array name...
the *only* reason why i ever wanted to use $0 in a msgbox is for
interacting with [soundfiler].
yup, including [soundfiler]
but there is more, setting send names with "$0", setting variable names with "$0", [text] names...
In Data strructures, when we need to traverse a subpatch name to a pointer, if it's local, again we need it. There are several examples and use cases.
can't say i miss this much (but ymmv).
I guess I design and work with lots of abstractions, so it's "$0" everywhere. And even when I'm not doing that, my habit is to always use "$0" cause I never need patches communicating with each other, and I can open similar patches that are variant of each other and they're all local...
cheers
fmsd IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list