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
hello frank and everyone
you just did what i wanted to do: continue this thread under a new
topic. you also just said, what i wanted to say:
-pure dsp-abstraction would be the first step (guis might be made on top
of them afterwards for different purposes)
-every abs needs a help-patch (which i agree, that this is essential)
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).
- 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.
- the helpfile should at least describe the available parameters and
their default values.
then:
kyle wrote:
> 3) Find the best way to keep the files checked in to cvs.
>
> 4) Actually check it in.
>
> 5) Test it out.
>
> 6) Fix errors.
what do you pd-people think?
roman
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
