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

[Kyle Klipowicz]

Man, that sucks about the backup wackiness. Good thing your netpd
efforts have multiple data sources for retention!

~Kyle

On 6/15/07, Roman Haefeli <reduzierer at yahoo.de> wrote:
> (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 Ã(c)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
>
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>


-- 
-----
------------
    ----     -----
---- -------- - ------
http://perhapsidid.wordpress.com