> > a softstudio; it's pretty far already and > > the first public release is scheduled Q1/2003. > > for Linux, obviously? ;-)
Yes. Linux, GPL. MONKEY is about 30.000 lines of C++ at the moment. I still have to make a final architecture revision based on some issues reading this list has evoked, and prepare the whole thing for release. > > First, I don't understand why you want to design a "synth API". If you > > want to play a note, why not instantiate a DSP network that does the job, > > connect it to the main network (where system audio outs reside), run it > > for a while and then destroy it? That is what events are in my system - > > timed modifications to the DSP network. > > because a standard API is needed for a dynamically loaded plugins! > LADSPA doesnt really cater for event-driven processes (synths) Yes, I understand it now. In principle, audio and control ports could almost suffice but sample-accurate events sent to plugins are more efficient, and allow one to pass around structured data. I shall have to add something like this to MONKEY. Right now it supports LADSPA via a wrapper - the native API is pretty complex - although creating a nice GUI based on just information in a LADSPA .so is not possible, mainly due to lack of titles for enums. > For a complete contrast, please look over > http://amsynthe.sourceforge.net/amp_plugin.h which i am still toying > with as a(nother) plugin api suitable for synths. I was hoping to wait I like this better than the more complex proposal being worked on, except that I don't much care for MIDI myself. But I also realize the need for the event/channel/bay/voice monster because it is more efficient and potentially doesn't require plugins to be instantiated while a song is playing. I don't think one API can fit all sizes. -- Sami Perttu "Flower chase the sunshine" [EMAIL PROTECTED] http://www.cs.helsinki.fi/u/perttu
