The purpose of subpatches is to hide stuff. If you feel the need for creation arguments, it is a good indication that you really should be using an abstraction instead. That's what they are made for.
Like, when you need to make just 2 copies of something in a patch. Left / right pairs for stereo processing, etc. Much easier just to have 2 subpatches than save a separate abstraction file, especially if you're working on a big project with lots of files.
This is rather messy. If you have to (almost) identical patches, you should be using an abstraction instead. This is cleaner and guarantees that the instances stay in sync. If you edit one instance, do you always want to delete and recreate all other instances, like you have to with subpatches?
Also makes it easier to share things with people if you only have to share one .pd file rather than a folder with abstractions, etc.
Just share a .zip file?
If you could do something like [pd volume #0] and have that argument unique to that subpatch
Just pass some identifier that is unique to the enclosed abstraction, e.g. [myabs $0]. For example, [myabs] can then have a [r $0/init], so you can (re)init all instances from the parent patch. This is actually a common pattern.
But the main thing i have always wanted it for is for state saving.
BTW, have a look at the new [savestate] object.
Christof
On 16.08.2020 12:49, Matt Davey wrote:
Creation arguments for subpatches is something i have wanted for years. Would come in very handy in a few cases.
Like, when you need to make just 2 copies of something in a patch. Left / right pairs for stereo processing, etc. Much easier just to have 2 subpatches than save a separate abstraction file, especially if you're working on a big project with lots of files. Also makes it easier to share things with people if you only have to share one .pd file rather than a folder with abstractions, etc.
But the main thing i have always wanted it for is for state saving. If there was something akin to $0 for subpatches, then they could be uniquely identified, and uniquely tied to an enclosed abstraction. So, say you have a simple volume control abstraction ( inlet~ -> *~ -> outlet ), and you enclose that it [pd volume] subpatch which is just a graph-on-parent slider. If you could do something like [pd volume #0] and have that argument unique to that subpatch, and then put [volume-abstraction #0] inside that subpatch, then you would have unique caller / listener pairs for that subpatch only, but also have the ability to save the state of the slider in the subpatch by setting it to 'init'. So, in effect, you could create any number of [pd volume #0] subpatches, and all have them with their own independent slider values that can be saved in the parent patch. For simple examples like that, maybe not too much to be gained...can just use an inlet to the abstraction and join it that way. But would be very useful for larger patches with multiple GUI elements. Would save a lot of messy cable joining, and [route 0 1 2 3 4 5 6 7] etc solutions.