[PD] announcing PureMeasurement

[Frank Barknecht]

Hallo,
Matthias Blau hat gesagt: // Matthias Blau wrote:

> thanks for the criticism. I once thought about using $0. However, as I 
> understand it, $0 creates a unique number in abstractions only, not in 
> subpatches. In fact, when I use your modified pm_scope and copy it, then 
>  $0 gives the same number for both instances. Am I missing something here?

You're not missing something: $0 is unique per abstraction, $0 is the
same across subpatches in the same patch. Instead of just copying the
subpatch, pm_scope with $0 is intended to be used as an abstraction
now and you can just open two instances of it (or create two instances
of it using [pm_scope] [pm_scope]. If you replace [r~ in1] with [r~
$1] this can be made even more fancy and you can use: 

[pm_scope in1] 
[pm_scope in2]
[pm_scope $0-in3]
...

(Then make it "graph on parent" and you have reprogrammed Cyclone's
[Scope~] as a graphical abstraction.)

> Opting for subpatces instead of abstractions is a personal preference: I 
> love it when everything is contained in just one file. Try to look at 
> things you did 5 years ago on a completely different system, and you 
> know what I mean.

No, I don't. ;) 

Now, seriously: Abstractions are a very important thing to use and an
immensely powerful concept offered by Pd. 

They play a totally different role compared to subpatches. For example
abstractions encourage code reuse: You can use one abstraction to do
different things depending on the caller arguments. Apart from the
pm_scope example from above, you could just take a look at the
list-math.pd patch I posted yesterday: This is only possible with
abstractions and it would be totally tedious, error-prone and most of
all very boring to do with four subpatches.

Subpatches are simply there to make things a bit clearer and cleaner,
but not using abstractions severly limits the possibilities of what
can be expressed in Pd. It's like trying to program C without
functions or LISP without recursion.

That's why I like to encourage everyone to use the full potential of
abstractions and it's why I try to explain abstractions very early on
when doing Pd workshops. (Because IMO understanding how to use
abstractions and how to use the trigger-object are *the* two most
important things to get right when learning Pd.) 

Having to store abstractions in their own files generally is no
problem if you organize things a bit. For example one could put all
abstractions used in a patch in a subdirectory and then call them with
the directory name. Then it also is possible to use descriptive
namespaces, e.g. have one subdirectory for analysis abstractions, one
for I/O abstractions etc. and then use objects like 

[analysis/fourier 64]
[analysis/fourier 256]
[IO/scope 400 300]
[IO/voldac~ log]
[IO/voldac~ lin]

and so on. This is quite clean and I don't see any disadvantage with
organizing things this way compared to using subpatches. 

Well, this was long and I hope I didn't sound too much like a
preacher, but I really believe in abstraction. ;)

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__