[PD] [PD-dev] REQUEST: Passed parameters into subpatch

[Christof Ressi]

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.
>
>
>
>
>