Hi all, not sure if this is a reasonable idea - but I'll give it a try: is there any way to access a parent's id from inside an abstraction? I always forwarded the $0 value of the parent patch as an argument in my abstractions so far if needed - like [foo $0] for example ... but I wonder if I might be missing some other option to access it?

@ben.wes [iemguts/canvasdollarzero]

@oid thanks a lot for the quick response! i'm trying to stick with vanilla if possible - so i'll keep the $0 as parameter for now. but good to know that there is this solution available if i include iemguts!

@ben.wes For vanilla using it as an argument is the easiest and most sane way. A couple times I have used dynamic patching to send the dollar zero, really create sends/receives with the parents $0 in the name. You can also have an unsafe [v] or [s]/[r] shared with the parent which lacks a $0 in its name so you can communicate easily.

Imo it's better design to supply it as an argument. I'd be curious what your use-case is, since the only reason you'd need it is sending, receiving, arrays, and texts. (and in those cases you would supply the full names as arguments bc it would make the abstraction reusable in other contexts)

Another reason is that it's better to make dependencies explicit in arguments because it's self-documenting behavior: if you or someone else opens your patch later they can tell which things depend on others just by looking instead of having to dig into the internals of the abstractions.

@seb-harmonik.ar said:

I'd be curious what your use-case is

I think he is just curious. The one time I really had a use case was in a series of patches/abstractions which needed to communicate, having a parent patch for it all required endlessly reworking the parent patch to deal with how things evolved so I switched to giving everything a generic non-unique send and receive so the "parent patch" never needed anything more then a very simple abstraction. It kept everything much simpler and did not penalize me for lack of foresight, everything used the generic send/receive to register their $0 and get the parent/master $0. At least once that generic send/receive bit me but it still saved me a great deal of time and effort. The other times I avoided making $0 an argument are times when it was just testing out an idea and was taking the simplest/quickest path to test that idea before putting in the time and effort to required to rework things.

Thank you both for further adding to this discussion! Sorry for not mentioning a use case earlier - I was considering to describe it in the question, but then decided to be lazy since I thought that the question remains the same.

So I actually have 2 use cases: One is related to a simple "preset management" experiment that is made of a central object managing the presets and little preset plugins that are cross-connected (output->input, input->output) to sliders or other value controlling objects. The "manager" needs to communicate with these and also store their names and values, of course. I didn't want to give them all unique names and also didn't want to give the "manager" all their names though. So currently, all these objects (including the managing object) get the $0 of the parent and then all relevant names are created based on it. The stored names of these plugin objects are created based on the parent's $0 combined with the difference between their $0 and the parent's $0. It's a bit of a mess, but it actually works quite well. Not sure if I managed to describe it in some understandable way. But since everything is based on just the parent's $0, it would be nice to omit that in the parameters and just access it from inside the abstractions.

The other use case I had in the past is abstractions that use cloned abstractions inside of them like [clone foo 16 $0]. Then all clone instances can be connected to the main abstraction's sends/receives/arrays etc. without collisions.

In the second case, it's not a problem at all, since it works well and is reasonably understandable. What bothers me in the first case though is that a user actually needs to write the $0 as a parameter for every object which is rather annoying. But then again, it's not a serious preset manager anyway and there's better stuff available already (I mainly checked out else's preset system so far) with a completely different approach.

@ben.wes If none of the abstractions require user arguments you could create a sort of menu and use dynamic patching.

This just uses a hslider with jump on click enabled as a button. This way you can just create a master patch and a button abstraction, create all your buttons and the user can have at it. Downside is that every object is created at a set location and no autopatching but it could be an easier/quicker user experience in some situations.

Edit: Suppose that [b ] is not really needed.