11 Oct
2010
11 Oct
'10
12:21 p.m.
On Sun, Oct 10, 2010 at 07:31:08PM -0400, Jeremy wrote:
Yes, this will be a new plugin API, support libraries for both
plugins and hosts will be provided, but I'm not going to actively
promote it as a replacement for anything existing.
It's not designed to be 'simple' - plugins and hosts *must* support
a minimal functionality much wider than LADSPA or LV2. For example
plugins must have a dedicated GUI, there is no such thing as a host
constructing a GUI from e.g. control port descriptors - these are
not even visible to a host. If a plugin supports multichannel use,
this must be provided explicitly - the host can not just replicate
the DSP code. There are many other differences, and some of them
have far reaching consequences.
This may well discourage 'novice' programmers, but that is to some
extent intentional. I want this format to be used only for plugins
that conform to some minimal quality standards. So it's not meant
to provide an easy way to create a wrapper around some DSP code you
don't even have to understand.
I'm creating apps such as REV1, AT1 and some others as test cases.
The specs are being reviewed and modified regularly as a result.
Ciao,
--
FA
There are three of them, and Alleline.
processors
that will eventually be released as plugins in
a 'rack' type of host. The GUIs and some of the internals are
already designed to fit into that format. When that happens,
the rack will have 'total recall' (session and snapshots),
and each plugin type will have presets (per user).
Does this mean you are going to release specifications for a new plugin
format? Or will this be specific to your code?