--- Paul Davis wrote:
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.
But could something change throuh 18 months? sigh...
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.
Yes. I was asking about C API mostly.
>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 ;-)
But anyways. I would really love to look at what you have.
Is this only a specification or you have a reference implementation?
This discussion is open!
the discussion is several years old :)
But could something change in several years? sigh...
Still no API.
Isnt it was a great idea behind the LADSPA
"simple API _now_ is better than several years old discussion"?
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.
So what? Isnt it just a two-three more API functions?
Damn! I never wrote any audio application ever,
and I dont want to create the ninth or tenth possible winner
instrument/synth API for linux.
So I see no reason for me to say "okay I can do it".
So I ask all of you guys once again:
What should we (I) use?
We already have some possibilities
-- MusE LADSPA extensions,
-- nick can finish his work,
-- MAIA
-- mustajuuri's API
....
why dont we use what we have?
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? :))
Which SC are you talknig about?
--p
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com