On Jun 15, 2007, at 3:08 PM, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
without designing to much, how this collection could look like, there are might some little conventions, that we could make up (these are meant as proposals):
- finding a naming scheme, maybe using a prefix like dsp_****
(similar to the list-abs).
I think, this might be done later with a simple directory-prefix. If the help-files themselves use the objects without any dir-prefix, then the name could be decided later and they would still be useable with standard methods of setting only the -path.
I didn't use a directory prefix, but instead a hardcoded prefix for [list]-abs mostly because many of them are impossible to use without the prefix anyways since they nameclash with existing objects like [list-moses] vs. [moses]. So "import list" doesn't make any sense for them. But for the dsp-collection I think, a directory prefix would make sense.
- using messages like 'frequency 123' to set parameters, which are
routed inside the abstraction. with such a design, only one inlet
for an arbitrary number of parameters is needed.Yes, that could be a kind of "good practice" recommendation. I do this in my personal abstractions a lot, where I now use the attached "dispatcher" to automate the creation of the necessary [route frequency] and [s $0-frequency] chains plus a tiny help-feature. (Requires pd-0.40 and up because of $1-$2)
I really like the idea of a standard library of DSP objects. I think
that one thing that can really make this project that much better is
having a clearly defined, usable, and clean common interface for this
library. I think it would be nice to use some inlets, rather than
just one inlet and a bunch of special messages.
So there could be defined classes of objects (synths, filters,
effects, etc.), and each would have a standard interface. So all
synths would have frequency and amplitude inlets, for example.
Another key part of this is using standard values for each thing.
For example, with filters, they can be specified using Q and f point,
or f and filter order (1st order/6dB, 2nd order/12dB, etc.), or other
techniques. Ideally, there would be a standard filter interface for
this standard lib.
Then for non-standard things, I think makes sense to use the messages
to the first inlet. Or perhaps the first three inlets would always
be the same thing, then the others would be available for special
parameters.
Also, standard units are important. For example, I think that the
pitch/frequency inlet should accept values in Hz and the amplitude
should always be between 0-1 like the rest of Pd. There was some
discussion about this last year:
http://lists.puredata.info/pipermail/pd-list/2006-03/036800.html
just my two bits...
.hc
- the helpfile should at least describe the available parameters and
their default values.
Yes++.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__ <dispatcher-help.pd> <dispatcher.pd> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin