IMO running each synth in its own thread with many
synths going is
definitely _not_ the way forward. The host should definitely be the only
process, much how VST, DXi, pro tools et. al. work.
i think you need to scan back a year or 18 months in the archives to
where we measured this. the context switch under linux can be
extremely quick - on the order of 20-50 usecs on a PII-450, and is not
necessarily a problem. switching between contexts is massively more
expensive under windows and macos (at least pre-X), and hence the
multi-process design is not and cannot be an option for them at this time.
No, there is no real "instrument" or
"synth" plugin API. but since my
original post I have been brewing something up. its quite vst-like in
some ways, but ive been wanting to make it more elegant before
announcing it. It does, however, work, and is totally C++ based ATM. You
just inherit the "Instrument" class and voila. (ok, so it got renamed
along the way)
thus guaranteeing that no instruments can be written in other
languages. for all the mistakes the GTK+ crew made, their design to
use C as the base language so as to allow for other languages to
provide "wrappers" was a far-sighted and wise choice. OTOH, i will
concede that the real-time nature of most synthesis would tend to rule
out most of the languages of interest.
Although in light of Tommi's post (mastajuuri) i
have to reconsider
working on my API. My only problem with mastajuuri is its dependance on
QT (if im not mistaken), sorry.
If people would like to my work-in-progress, i could definitely use some
feedback ;-)
This discussion is open!
the discussion is several years old :)
you managed to touch upon the central problem in your penultimate
sentence, apparently without realizing the depth of the problem.
if a synth comes with a GUI, then the issue of toolkit compatibility
rears its ugly and essentially insoluble head once again. you can't
put GTK based code into a Qt application, or vice versa. this also
fails with any combination of toolkits, whether they are fltk, xforms,
motif etc. etc.
if the synth doesn't come with a GUI, but runs in the same process as
the host, then every synth has to have some kind of inter-process
control protocol to enable a GUI to control it.
these are deep problems that arise from the lack of a single toolkit
on linux (and unix in general).
this is why JACK is designed in the way that it is, and why it
(theoretically) allows for both in-process and out-of-process
"plugins". this allows programmers to choose which model they want to
use. i predict that any API that forces the programmer to use a
particular toolkit will fail. JACK's problem in this arena is that its
designed for sharing audio data, and does not provide any method for
sharing MIDI or some other protocol to control synthesis parameters.
besides, if SC for linux is in the offing, who needs any other
synthesizers anyway? :))
--p