I've been programming pd for over five years and never knew this was possible.

Mark it up as "There is always something new to learn".

abstractions-as-creation-arguments.zip

• Subpatches CAN have creation arguments and it is the same one as its parent
• if the creation argument is a symbol and is the name of a .pd in the parent's folder, then that creation argument by itself IS that abstraction
• the symbol creation argument by itself will be represented with its gui
• creation arguments with relative paths ARE represented

The implication being...rather than throwing abstractions around in your patch (by name), just include them as creation arguments and use the creation argument instead of the abstraction name.

"Write once..." and less(!) right?

Peace through sharing,
S

p.s. I am 100% certain there are a lot of people who already knew this. Then, again,...
you never know when you're going to learn something.

@svanya said:

Subpatches CAN have creation arguments and it is the same one as its parent

I think this is wrong: writing $1 in any subpatch simple take the $1 from the main patch where your subpatch is located. Try to replace $1 with $2 in your main abstraction and see, you don"t get "e" when asking for $1 but still "3".

For the other points I agree, I also discovered them by practising.

@svanya said:

I've been programming pd for over five years and never knew this was possible.
Mark it up as "There is always something new to learn".

That's a positive point of view. I would say that, after 5 years, if you still discover things it might also means that pd has still some work to do on the documentation

Cheers

@60hz
Yes. My thinking was correct. But you said it much better:
Subpatches can take creation arguments as they "take the $1 from the main patch where your subpatch is located".

As to always able to learn...
One of my core beliefs is "No matter what field or great your expertise that is always more to be learned.".

Though I agree, while pd documentation is excellent in many ways, it also falls short in many others (ex. not writing the controls into the control properties, across the board).

@svanya Also check out [pdcontrol]. It is somewhat new and lets you also access creation arguments.

@svanya I think actually what you have found is that a sub-patch is just a "hidden window" within a patch.
You can use an argument as its name [pd $1] but that only changes the name shown in top bar of the window when you open it.
The name is only a label...... a convenience.
But on the bright side you have discovered how to assign a float to the name......
bright.zip
David.

Thanks for the pointers.

I am, however, way less excited about subpatches and way more about abstractions.

That they can be created by(symbol) creation arguments within the parent patch. That, I never knew.

So given, patchN.pd, bypass.pd, adsr.pd, and patchN-help.pd (or grandparent), and object [patchN bypass adsr] inside a -help, objects [bypass] and [adsr] may be generated by only adding the objects [$1] and [$2] inside patchN.pd.

Subpatches aside, that alone for me is a huge game-changer.

I can organize All my abstractions by name when I declare an object, ex. [patchN abs1 abs2 abs3] and then just write those abs as [$1] [$2] [$3].

Which greatly improves the transparency for anyone wanting to digest my code.

When they see my abstraction declaration, they will know right up front what abstractions I am going to use inside it.

@svanya This is a nice idea, anyhow for me it would seem more obfuscating than transparent to inspect some code and only find [$n] objects.

The approach also has some limits as you can only assign variables on the first level and abstractions cannot have creation arguments themselves. Or you have to write them as well in the main patch and the abstractions as [$1 $2 $3] and this would get completely confusing. Just my thoughts

What I mean is like this:

abstractions-as-creation-arguments2.zip

Which I think, for my sake at least, adds to greater transparency.

@svanya I would not do it that way personally, as like @ingox says when someone wants to open your patch to see how it works they will have to mentally substitute "$1", "$2" etc. for the objects, and have to remember what each one is as they look at your patch if they want to understand it.

what this IS useful for imo is if you have a bunch of objects with exactly the same interface and want to use arguments to choose which ones your abstraction will use. for instance, all relational objects have the same interface. Therefore I made an abstraction to pass numbers to the left outlet if they met a certain condition and the right outlet if not by using "$1" inside to be able to choose what relational object to use for the test:

then when you use the object you can use e.g. [passif == 5] to pass the numbers out of the left outlet if they are equal to 5/the right inlet, and out the right outlet if not equal, or [passif < 5] to pass out the left outlet if the numbers are less than 5/the right inlet, and out the right outlet if not less.

this could also be useful in a sorting algorithm in order to choose how to sort elements

another example might be if you had multiple objects that interpolate values, all with the same interface but with different interpolation methods. then you could do something like [myabs~ linear] to select linear interpolation, and [myabs~ cubic] to select cubic interpolation.

Two benefits, to designing this way, I thought of:

1. when debugging, how significantly it would cut down the count when doing a Find for your abstractions

and

2. when analyzing your code for precedence, the "reader"/student would no longer need to drill down to the individual level, but could stop at the parent.

Just something funny about this, since this really only applies to grandchildren....

I can't count how many times I have been at my parent's place over Christmas with my kids, my brother, and his, that I have heard my parents tell the children "Take a number!".

😁

Grandchildren (by nature?) seem to lose their identity.

I feel like I should say...

I am applying this design concept to my current project. It's a step (drum) sequencer to which this concept applies nicely.

When I share it, one large part of the readme will talk about what I learned in trying this out.

@svanya Sorry, but I have to agree with @ingox that this is going to make your patches much harder to read.
Naming a sub-patch is for convenience only...... it serves no purpose other than to remind you what is inside. The name must be typed.... yes.... but weeks later it is very useful.
Often patches are posted as screenshots and send/receive names are hidden within GUIs...... and that is a problem.

In Windows we have a chance to decode the patch because the arguments are added to the title bar of the patch window, but I am not sure that is the case in some other OS's....?
If the window is small and there are many arguments they will be off the right edge of the title bar.
So in your first post we might only know the values of the $ arguments for the patch because you have made them visible with a [loadbang]
Anyway, counting through the large number of arguments you might end up with and then mentaly applying that to the patch (just to know which abstraction [$55] refers to) could prove difficult for us grandparents while the toddlers are screaming their heads off......
Even as you write your patch you will be scratching your head. Imagine when you come back to it next year.
David.