Apparently, this seems to be a pretty rare thing to want to do in pd, because nowhere can I find where someone has asked this question online. I come from a programming background, so the idea of instances of an object containing unique objects seems fairly reasonable to me (to convert to pd terms: abstractions containing unique subpatches).

In C++ for example, you can pass objects into other objects as arguments, or even types into objects. So you could have class X that contains variable Y for an object. In instance A of that class, you could pass in type int, and Y would be of type int. While, in instance B, you could pass in type string, and Y would be of type string.

I know this isn't a direct 1 to 1, but how do I achieve this sort of functionality in PD?

This kinda difficult to explain, so I'll do my best. This is my situation (btw I'm using plugdata):

I'm building a cue system for a performance. I would like to create a "cue.pd" abstraction as essentially a class from which an arbitrary number of instances can be made. Each instance needs to have it's own completely custom functionality. I understand that I could achieve this by just making "cue1.pd", cue2.pd", etc or [pd cue] multiple times. But that would mean I have to create the exact number of subpatches as cues, and that's unscalable and inelegant if I were to reuse this system in the future.

I have multiple instances of a "cue.pd" abstraction within "cue_sequencer.pd", each with a number passed in as it's first argument.

Within the "cue.pd" abstraction, I assumed that if I made a [pd impl-$0] subpatch, each subpatch within each instance would be unique, as it's name is unique.

But this is not the case, as the same subpatches with different names contained within different instances of "cue.pd" have the same contents.

How would I make it such that each instance of "cue.pd" can contain it's own completely unique subpatch? Or at least achieve the same effect with a different method.

Thanks !! :3

@crttrkix You can pass arguments, but not as part of the name.
$0 is not so useful, as when you want to send messages from outside the abstraction you can get it to declare its $0 value but that becomes complicated.
So it is easier to give each instance known arguments.
Arguments are passed down to sub-patches within the abstraction.
So probably.....

I have used the first argument directly in [expr]
Since some version of Pd the $1 would be automatically escaped within the formula of [expr] and made literal, so I have escaped it again to make it a variable as required in this case.

You can have as many arguments as you wish..... intteger and string....
Inside the abstraction use [symbol $1] to loadbang a string.
I tried to make a tutorial here.... https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4

For the sub-patch it is not actually useful as the sub-patch is just a window within [cue].... so all you have done is change the name of the sub-patch.
If you want a completely different sub-patch in each instance of [cue] then use another abstraction (a patch) instead.
[cue 1 34]

inside [cue] $1 becomes 1 (in an object) and [patch$2] becomes [patch34] which you have created as patch34.pd

But if the sub-patches are identical then pass arguments from the creation of [cue]..... as many as you need...
[cue 1 34 woof lala 12 rev delay]
Inside object names they will be resolved...... and not escaped.
David.

Why would the subpatches have different contents?

You've put the same code in the subpatch inside the abstraction, so every instance of that abstractions contains the same code and subpatch.

@crttrkix
I don't 100% understand what @whale-av wrote, so this response may just repeat an idea @whale-av already gave you. But maybe not. I agree that

all you have done is change the name of the sub-patch.

So why not instead change the name of an object within your subpatch using the argument to the enclosing abstraction? The analogy isn't perfect, but it's sort of like passing a function pointer, and the weird object inside the abstraction is like an abstract superclass but for a single function. OMG that was too complicated to be helpful

@jameslo Thank you this make sense to me! I did not know you could pass arguments into the name of an object and it would actually dynamically change what object it pointed to based on name.

I implemented your method by creating a "impl-cue-X.pd" for each cue's functionality, where X is the cue number. I suppose this is the same method I was trying before, but with individual Abstractions, rather than subpatches. But it works in this case !!

This demonstrates a bit of an inconsistency in their behavior (I don't know why this is) that is good to know.

Within "cue.pd", I create an object referencing an abstraction with a dynamic name [impl-cue-$1] (which would reference "impl-cue-0.pd", "impl-cue-1.pd", etc) and a subpatch with a dynamic name [pd impl-$1]

The abstraction behaves as expected. Within the cue instance with 0 passed in as $1, the [impl-cue-$1] becomes [impl-cue-0], and for instance with 1, it is [impl-cue-1]. Because they are explicitly different files with different definitions.

However, the subpatches do not behave this way, even though they are passed in different values of $1 depending on which instance of "cue.pd" they are inside of.

[pd impl-0] has the same contents as [pd impl-1].

I'm not sure why this is, but I imagine there are plenty of internal differences between abstractions and subpatches that I do not know the inner workings of.

This solves my issue though. Thank you!!

@crttrkix I think you're still a little off WRT subpatches, and I'm enjoying the crazy c++ metaphors, so I'll continue as if you asked a question . In Pd, an abstraction is like function, and since it's in a separate file, it's like a function in a separate compilation unit that has to be linked in (or in Pd's case, loaded). But a subpatch is more like bracketed code--not that it introduces a new scope (it doesn't, e.g. $0 is the same value inside and outside of a subpatch) but that it's really just a graph that's been hidden except for its inputs and outputs. That's why [pd mySubpatch-$1] is just a renaming of the subpatch--it's just a labelled section of code.

@crttrkix "This demonstrates a bit of an inconsistency in their behavior (I don't know why this is) that is good to know.

It is just that [whatever] is an abstraction... that is another patch..... whatever.pd.... inserted into your patch.
[pd whatever] is a window within the patch that contains it..... useful for keeping a patch tidy but also to fix an order of operations and to set a different block size for resampling, and for processing audio at a different block size (right down to single sample processing).

And what @jameslo said..
David.

@jameslo This is a very helpful analogy thank you !! :3 it's helpful to understand that subpatches are essentially always contained within the "class" (or the file definition of the abstraction) rather than the instances themselves. So even if in the instances, the subpatches have different names, they are essentially still pointing to the same "bracket of code" that belongs to the patch being instantiated. This is as opposed to dynamically named objects that can point to different abstractions within each instance of an abstraction. [cue-$1-impl] can point to different files depending on what is passed in to it's parent.

I think this solution works for my use case! I'm able to instantiate an arbitrary number of cue objects that each share the same framework of functionality (that's necessary for them to be cues) without having to recreate that functionality for each cue, but have unique implementations of functionality within each cue. It's very flexible and elegant I think!

I definitely have the oop virus. I know this is sometimes unnecessary but it makes me happy to right an elegant system that is scalable and reusable.

Thanks so much for the help @jameslo and @whale-av

@crttrkix I guess a better description of what I'm trying to do is: (in C++ terms)

Create a "cue" class that implements some functions for making a cue within a cuing system, but being able to pass functions into instances of "cue" that describe what the cue is supposed to do when enabled.

Thanks again!!

@crttrkix P.S. As well as passing arguments from [cue] to the name of the abstraction it contains, you can also pass arguments to it.
i.e. [cue 1 22 33 44]
contains
[whatever$1 $2 $3 $4]
where $2 $3 $4 inside [whatever1] resolve to 22 33 44 upon creation.
David.

@crttrkix Subpatches don't get "passed on" values of anything. That's not how they work.

The name of a subpatch is just that: a name.

Everything else a subpatch inherits from the parent, $0 (identity) and any arguments.