Hi list,
this is to tell you that the first version of PureMeasurement is available for download:
http://www.hoertechnik-audiologie.de/index.php?p=602
PureMeasurement is a collection of pd-patches (requiring iemlib) aimed at providing students and researchers with tools to perform acoustical measurements using audio interfaces.
Feedback welcome! --Matthias
Hallo, Matthias Blau hat gesagt: // Matthias Blau wrote:
PureMeasurement is a collection of pd-patches (requiring iemlib) aimed at providing students and researchers with tools to perform acoustical measurements using audio interfaces.
One word: WOW!
(More words as minor criticism: I would prefer local variables in the tools-patches, though. They are not necessary for the "applications", as one would normally not use two instances, but for the tools this could be common. I attached a version of pm_scope.pd where I replaced the globals with "$0-" versions.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Frank,
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?
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.
--Matthias
Frank Barknecht schrieb:
Hallo, Matthias Blau hat gesagt: // Matthias Blau wrote:
PureMeasurement is a collection of pd-patches (requiring iemlib) aimed at providing students and researchers with tools to perform acoustical measurements using audio interfaces.
One word: WOW!
(More words as minor criticism: I would prefer local variables in the tools-patches, though. They are not necessary for the "applications", as one would normally not use two instances, but for the tools this could be common. I attached a version of pm_scope.pd where I replaced the globals with "$0-" versions.)
Ciao
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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__
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
-
Frank Barknecht -
Matthias Blau