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.

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

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

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.

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

abstractions-as-creation-arguments2.zip

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

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.

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.

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

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.