--- 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
