I agree. Now I've used it for a while I'm seeing one or two minor annoyances and things for my wishlist. Groups would be a useful addition to the pd-gui, along with hide/reveal. I realise groups can get complicated to manage, deleting and adding inclusively/exclusively etc. In the worst case they become a royal PITA. So while I'm thinking about this again here's another way of looking at it..
The issue it addresses is selecting objects in a very cluttered patch. In theoretical best practice you shouldn't ever end up with such cluttered patches because you would subpatch things in a timely and organised fashion. But in practice I tend to build quite a lot before getting to a position where it's time to reconcile large parts of the patch into subpatches and abstractions. What would help is a far easier and smarter way of creating subpatches, which in a way *are* "groups".
Two things would help with this. Firstly the process of creating a [pd mysubpatch] object, copying and pasting all elements into it while keeping track of all inlets and outlets could be much improved. Selecting a whole bunch of objects and simply clicking a "make subpatch" that found all terminal signal paths at the boundaries and automatically asigned [inlet/inlet~/outlet/outlet~] would be lovely.
Another would be subpatch "aliases" with a "convert to unique copy" procedure - they would behave like in-file abstractions. To be honest I don't entirely get "abstractions". Sure they speed up reuse but they only seem to really help get around the need for tables and delays to be named and the whole rather annoying $0- scoping mess. It's the fact they exist in separate files that makes the headaches. I prefer to use everything in one file to get easier management. In a way abstractions are a danger because changing them can break some other patches. Having anonymous simple delays would go a long way towards simplifying many patches, but that's another topic, however "aliases" would seem to solve a number of issues. They could be combined into the above subpatching procedure. In summary then, what I envisage is as follows:
You select some objects You click a "subpatch" option A dialog appears asking for a name (automatically filled with a unique sequential number) The new object is created with automatic inlets/outlets, and why not, wired in-situ in its current place so it can be immediately tested.
You select a subpatch and copy - a dialog asks whether you want a unique or aliased copy. An alias is identical to an abstraction with all scoping rules satisfied, but it only exists in the current file, if you edit one instance in the patch all others change too.
that's my loose change on the subject, cheers, Andy
on the vector theme, i think a group function would be handy (group several objects then select them with one click)
all the best
adam
Send instant messages to your online friends http://uk.messenger.yahoo.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, padawan12@obiwannabe.co.uk hat gesagt: // padawan12@obiwannabe.co.uk wrote:
Two things would help with this. Firstly the process of creating a [pd mysubpatch] object, copying and pasting all elements into it while keeping track of all inlets and outlets could be much improved. Selecting a whole bunch of objects and simply clicking a "make subpatch" that found all terminal signal paths at the boundaries and automatically asigned [inlet/inlet~/outlet/outlet~] would be lovely.
Great idea, that indeed would be lovely.
To be honest I don't entirely get "abstractions".
As you are a programmer, you know the difference between a code block and a function: subpatches are code blocks and abstractions are functions, kind of. The real power of abstractions is not, that they are in their own files so they can be used for code reuse. The real power is, that they can accept arguments.
People who patch without using abstractions completely miss this feature, they use a programming language without function(s).
To make this a bit less abstract: Think of the [+ ] object. You could clone it in Pd, but if you clone it as a subpatch like [pd add] with trivial content, it would only be a [+ ] that doesn't accept an argument, that is, you couldn't do [pd add 3] to make a clone of [+ 3].
However if you do an abstraction "add.pd" with:
[inlet] | [+ $1] | [outlet]
you can use this just like the real [+ 3] and write [add 3].
OTOH it is not of no importance, that abstractions are their own files and that all of them change their behaviour, if you change the one source file. Assume you made a silly mistake and used this to write [add]:
[inlet] | [- $1] | [outlet]
If you already used [add 3] in a lot of patches, then you only need to fix this error in one place, to fix all occurences of [add] everywhere. If however you have one [pd add] with does [-] and the other [pd add]s do the correct [+], than that is very confusing and error prone, though it would be perfectly legal in Pd.
It's the fact they exist in separate files that makes the headaches. I prefer to use everything in one file to get easier management.
Just change your preferences. ;) Managing external files can be easy as well. You could for example always use a subdirectory called "pd" relative to your main patch to place your abstractions. Then instead of writing [pd subpatch] you could write [pd/abstraction] and put abstraction.pd inside the "pd"-subdir. It looks almost like a subpatch, can be zipped together with the main patch and still allows to use the full feature set of abstractions.
Frank Barknecht _ ______footils.org_ __goto10.org__
That is a great description, its like a page out of the Pd textbook.
Feel like making that a PDDP patch? It would fit very well in a
later page of doc/tutroials/intro. There is a lot of content there
already, but its really poorly organized (FYI).
.hc
On Jun 6, 2006, at 11:55 PM, Frank Barknecht wrote:
Hallo, padawan12@obiwannabe.co.uk hat gesagt: //
padawan12@obiwannabe.co.uk wrote:Two things would help with this. Firstly the process of creating a [pd mysubpatch] object, copying and pasting all elements into it while keeping track of all inlets and outlets could be much improved. Selecting a whole bunch of objects and simply clicking a "make subpatch" that found all terminal signal paths at the boundaries and automatically asigned [inlet/inlet~/outlet/outlet~] would be lovely.
Great idea, that indeed would be lovely.
To be honest I don't entirely get "abstractions".
As you are a programmer, you know the difference between a code block and a function: subpatches are code blocks and abstractions are functions, kind of. The real power of abstractions is not, that they are in their own files so they can be used for code reuse. The real power is, that they can accept arguments.
People who patch without using abstractions completely miss this feature, they use a programming language without function(s).
To make this a bit less abstract: Think of the [+ ] object. You could clone it in Pd, but if you clone it as a subpatch like [pd add]
with trivial content, it would only be a [+ ] that doesn't accept an argument, that is, you couldn't do [pd add 3] to make a clone of [+ 3].However if you do an abstraction "add.pd" with:
[inlet] | [+ $1] | [outlet]
you can use this just like the real [+ 3] and write [add 3].
OTOH it is not of no importance, that abstractions are their own files and that all of them change their behaviour, if you change the one source file. Assume you made a silly mistake and used this to write [add]:
[inlet] | [- $1] | [outlet]
If you already used [add 3] in a lot of patches, then you only need to fix this error in one place, to fix all occurences of [add] everywhere. If however you have one [pd add] with does [-] and the other [pd add]s do the correct [+], than that is very confusing and error prone, though it would be perfectly legal in Pd.
It's the fact they exist in separate files that makes the headaches. I prefer to use everything in one file to get easier management.
Just change your preferences. ;) Managing external files can be easy as well. You could for example always use a subdirectory called "pd" relative to your main patch to place your abstractions. Then instead of writing [pd subpatch] you could write [pd/abstraction] and put abstraction.pd inside the "pd"-subdir. It looks almost like a subpatch, can be zipped together with the main patch and still allows to use the full feature set of abstractions.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies."
- Amy Smith