[PD] announcing PureMeasurement

[Matthias Blau]

OK OK OK, I shall give it a try.
Thanks, Matthias


Frank Barknecht schrieb:
> 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