Trouble might be that there are other forms of subwindows (array, text) that aren't patches. So we'd need a term for 'a subwindow that's a patch'. Maybe 'patch subwindow'? But that's so close to 'subpatch' that it would make everythig worse I think.
cheers M
On Sun, Aug 12, 2018 at 07:00:36PM +0200, Max wrote:
May I propose subwindow as an umbrella term for both abstractions and subpatches?
Both terms should be either hyphenated or not. I am fine with not hyphenating them, but as a native German speaker I might have a bias towards sticking words together.
m.
On 12.08.2018 18:45, Miller Puckette wrote:
Well, (adopting for the moment subpatch/abstraction for the larger class and one-off subpatch for the more specific one of a non-abstraction)...
I imagine that more things are true of subpatch/abstractions (they have subwindows, inlets, outlets; and their run-time semantics are identical) than are true of either subset alone (of which we may say that saving and loading, and $-argument handling act differently).
So it's convenient to have some name or other for 'abstraction/subpatch'... but if just calling this a 'subpatch' is confusing, perhaps we can think of another term.
cheers Miller
On Sun, Aug 12, 2018 at 02:23:15PM +0200, Max wrote:
Hi Miller, thanks for chiming in.
On 12.08.2018 00:54, Miller Puckette wrote:
I think the best terminology is "sub-patch" for either an abstraction or for a one-off subpatch. (But then we probably need a better term for 'one-off'; maybe 'ad hoc'?
may I ask the rationale for it?
I believe a clearly defined and consistent terminology is very important for people trying to understand the manuals and helpfiles. The definitions in 2.7 and 2.7.1 are good, and I think the terms "subpatch" and "abstraction" are good too. ** subpatch ** is like a folder structure where things can be put into and stuffed away. ** abstraction ** is exactly what it sounds like. The term doesn't try to be what a "class" is in other languages, I think that's smart.
The established definitions give us a clear distinction between externals, abstractions and subpatches.
Now I just wish the documentation would be consistent with those established terms and not adding confusion by using the terms differently.
m.
cheers Miller
On Tue, Aug 07, 2018 at 01:44:18PM +0200, Max wrote:
In the Pd documentation the word
abstraction is found 1859 times subpatch is found 2142 times sub-patch is found 45 times subwindow is found 24 times sub-window is found 1 time (that's in the html document, where it occurs 3 times hyphenated and 1 time not hyphenated)
For reference: Definitions of the terms subpatch and abstraction can be found in paragraphs 2.7 and 2.7.1 of the documentation.
The terms however are consistently used inconsistent.
in 2.7.2 "Graph-on-parent subpatches" the illustration shows an abstraction, not a subpatch. The text first talks about an abstraction and then continues: "When the sub-patch is closed, all controls in it appear on the object instead; so the number box in the sub-patch in the example above is the same one as you see in the box. "
Even weirder, there is a definition of the term "abstraction" in the clone-help.pd which goes as follows: "a patch loaded as an object in another patch" but in the same patch the clones abstraction is named "clone-subpatch.pd".
Is there something I am missing here?
m.
On 05.08.2018 12:01, Max wrote:
OK, let me try myself, please correct me:
An abstraction is a Pd patch which is used like an object in another Pd patch.
A subpatch is saved within the main patch and is constructed with [pd {name}]. Multiple subpatches with the same name may coexist.
Subwindow is the umbrella term for both of the prior terms.
If someone can confirm that the above definition is true, I will make some pull requests to the documentation/ help files since it isn't consistent. The pd~-help for example.
On 04.08.2018 14:05, Max wrote: > In the helpfiles and on this list the three words > > 'abstraction' > 'subpatch' or 'sub-patch' > 'subwindow' > > are used. could someone provide a definition of those? I suspect > they aren't used in a consistent way throughout the documentation. > > m. >