Hi, I made an abstraction which allows you to get $0 value of any opened patch.

You can simply create [setdollarzero $0] on one patch and create [getdollarzero] on other patches to get the $0 value.

I hope someone finds it useful.
Download : getdollarzero.zip

@cuinjune great, a few small fixes: getdollarzero.zip

@ingox Thanks. Have you checked the latest version of the patch I uploaded?
I'm sorry but I don't really understand why your fix is needed.
Could you please explain it to me?
The above is mine. and below is your fix. Thanks!

@cuinjune the value gets overwritten by a second example patch.
Open example.pd twice, open the childs, click on the bangs inside the childs.

@ingox You are right! I fixed it and re-uploaded my patch.
Thanks a lot for your brilliant fix!

@cuinjune here is a simpler version: getdollarzero.zip

Also be careful if want to close a spigot but it's a float going through the spigot. It will overwrite [0] and the spigot will stay open. Better to use a message [0( will always close the spigot.

@ingox Your simpler version can be problematic if the abstraction uses [getdollarzero] with [loadbang] and if the abstraction's [loadbang] triggers [getdollarzero] earlier than [setdollarzero]'s internal [loadbang], the [getdollarzero] will output 0.

You can test this by opening the example file and try recreating the [setdollarzero $0] and save and restart the patch, you will see [getdollarzero] didn't work in the beginning.

@ingox said:

Better to use a message [0( will always close the spigot.

You are right, there was a mistake in getdollarzero.pd file so I fixed and re-uploaded it. Thanks!

I try to avoid using message box when possible since processing through message boxes takes slightly longer than using object boxes such as [float], [symbol] and [list].

@cuinjune You are right. But a similar thing can happen with the previous versions, because the spigot in setdollarzero closes after the first request and if a child is created later, it won't get the $0. Maybe a solution would be to close that spigot only after a delay 0 or so...

Edit: or maybe i am wrong on this, being a little confused today...

Yes, i think i was wrong on this, your version should work fine

@ingox Yes, I just tested it by changing object creation order and it all seemed to be working fine.

I too have been pretty confused today.
It is always difficult to create something that works flawlessly.

But it was fun and also a good practice.
Thanks a lot for your help

@cuinjune @ingox Sorry to throw a spanner in the works. Saving a test patch containing copies of your example patch (and re-opening) destroys the order of creation. You cannot rely upon the order of creation being maintained...
I am now certain that passing the $0 value through arguments is the only safe option.

test.zip
David.

@whale-av Thank you for testing this. I completely agree. Passing $0 down through creation arguments should be established as the one reliable best coding practice (apart from using inlets and outlets).

That said, the above method should work if and only if you have [setdollarzero $0] in the mother patch. Than you can (manually) open the mother patch multiple times and still have separation. But you should not include mother patch as abstraction inside another patch.

Clearly, it is better to just use creation arguments.

Just to show that it still may be possible: test.zip

This uses delays to open and close spigots at the (hopefully) right logical time so every instance gets the right $0.

i would still recommend using creation arguments, as this is a bit hacky and may be not as reliable...
(Although it should be reliable as i am pretty sure that the order of creation actually is being maintained. It is still possible to break this if you have two [setdollarzero $0] after one another in the creation chain without a [getdollarzero] in between.)

@whale-av Thanks for your testing and finding the bug!
@ingox I tried your patch and it looks like a very creative solution!
So I made a new version inspired by @ingox's approach.
It is based on an idea that child patches always get assigned a higher $0 value than its parent canvases when patches are firstly loaded.

I haven't fully tested this yet. but it seems to pass @whale-av's test at least.
Download: getdollarzero.zip

EDIT : I found out it only works properly when you first start the patch. It doesn't work correctly when you create a new [getdollarzero] and try to use it immediately. It requires a restart which is a bit inconvenient. But I think the original patch also has this issue.

This one allows you to get $0 value of different levels of parent canvases by setting unique names.
For example [getdollarzero root] can get the $0 value of parent patch where [setdollarzero $0 root] is at.

Download : getdollarzero(multi-level).zip

@cuinjune It seems to work...... but it is a huge amount of work compared to just passing down arguments. Would I trust it...... I don't know without thorough testing......
And then it is still harder work to make the value useful...... using it in objects.... you cannot "match" it even in logic, as it's value is unpredictable.

As you said earlier... "fun and also a good practice"..

One up-vote for not giving up!
David.

@whale-av Thanks for the up-vote!