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__