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:
Find the best way to keep the files checked in to cvs.
Actually check it in.
Test it out.
Fix errors.
what do you pd-people think?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de