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

[Roman Haefeli]

sorry for double posting, but it seems, that it is not only me who didn't receive that mail:


to make a start, i put these two abstractions together (with according
helpfiles):

[tr808-bd~]
[tr808-cp~]

(which are part of my try to rebuild all 808-instruments in plain pd,
but unfortunately i lost most of the instrumenst during a harddisk
backup, which made me so depressed, that i made this song:
http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 )

you can get them here:

http://www.romanhaefeli.net/software/pd/dsplib.tar.gz

i still don't know, what is the best way to get them into cvs. will
someone collect all the works and include them? i do actually not have
writing access to cvs. 

roman


On Fri, 2007-06-15 at 18:40 +0200, Frank Barknecht wrote:
> 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




	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de