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

Frank Barknecht fbar at footils.org
Fri Jun 15 18:40:04 CEST 2007


Hallo,
Patco hat gesagt: // Patco wrote:

> Hello,
> 
> Frank Barknecht a écrit :

> > All that would be necessary are a clean and documented
> >interfaces for the DSP abstractions.
> Yes exactly.
> > Things like state saving, GUIs or
> >network control then could easily be built as wrapper abstractions.
> >  
> It might be necessary to have a bridge between the wrapper and the
> DSP abs.  This bridge would find all GUIs inside DSP abstraction,

IMO there should be no GUI at all inside the actual DSP abstraction,
just a couple of documented(!) inlets and arguments.

> and construct a wrapper with all necessary GUIs concatenated into
> one dynamically made abstraction.

A bridge with automated service discovery could be nice, but I fear
that it may also be too much bureaucracy and in the end may not help,
but hinder moving forward and actually getting things done. The first
step should be to 1) abstract DSP out into abstraction and 2) at the
same time document each of them with a stupid black and white,
help-patch. 

That help-patch may be quick and dirty, but it must *exist*. Keeping
formalisms and requirements on help-patches etc. low, in the end will
lead to them actually being written, instead of just being planned.
For example every single [list]-abs has a help patch. They aren't
pretty or anything, they don't all have the same layout, but they are
there, which to me, now is the most important thing. (It took me a
while to realize this. For example many RRADical abstractions are not
documented ...)
 
And a service discovery bridge may also be built later as a decorator
abstraction itself around the original abstractions.

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__




More information about the Pd-list mailing list