[PD] DSP abstractions [was: netpd ...]

[Hans-Christoph Steiner]

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 at 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