On Fri, 17 Mar 2000, Kai Vehmanen wrote:
> Hmm, I just feel that trying to put everything under the same interface -
> although maybe possible - will slow down the development. We already
> have many different approaches:
>
> - the current LADSPA model
> - realtime bounded API (memory allocation issues, realtime
> requirements, etc. - mostly unsolved)
> - GUI interaction -> GUI-specific plugin-APIs (no agreement)
> - sample-accurate, event-based API (MuCoS, as you've said, still
> vaporware)
> - ...
>
> The first one is ready (well, at least very close) for real use, but
> the rest is still pretty much an open field. Parallel development
> would mean, that we would start using LADSPA, while still continuing
> to discuss the other issues and plugin models. Sometime in the future,
> we may combine all (or some) of these APIs to one all-around API.
Just to advocate my own design: In Mustajuuri there is a plugin interface
that can has answers many of these qeustions. There are some questions
open even as it is. I know many people do dislike the C++/Qt combination
(which for me is the easiest and fastest to code combination). As a result
I do not expect everybody will like it. Anyways, people might have a look
at it (unless you already have done it). Mustajuuri integrates fair amount
of (G)UI functionality to the plugins and plugin API which has been a
good solution for my line work. Few things need more polish, but mostly
the groundwork is decent.
I have purposefully left the most demanding feedback-synchronization and
real-time instantation issues out. It would be possible to support stuff
like that (at least to some level), but I have no personal desire for it.
Hopefully I can eventually integrate the LADSPA/MuCos etc.
plugin-interfaces to Mustajuuri (and vica versa).
Tommi.
