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> > _______________________________________________ > [email protected] 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
