On Fri, 2004-07-30 at 06:12, Steve Harris wrote: > > FWIW this ladspa only softsynth is something I've been itching to do for ages, > > I think it's a really good idea. Maybe it would require some specialist LADSPA > > plugins that would be needed for a softsynth, but I think this is where the > > functionality belongs, rather than in client code. > > To be brutally honest I'm not sure its needed, AMS, SSM and Galan are all > good LADSPA hosts in thier own ways. But, hey, I'm not going to > encourage anyone to not write code. It could be theres some really neat > things that haven't been thought of yet. I have a document entitled "do we really need another modular synth?" waiting to go along with the release for just this. :D In short: - polyphony this is the big one, it eliminates all but ams - performance - ams is a _terrible_ CPU hog, especially when it goes polyphonic. I assume this is because it does everthing at audio-rate. Whatever the reason, ams is too much of a CPU hog to be useful to me personally, and the audio code is so intertwined with QT I gave up on hacking it long ago. plus, I have had minor talks on the ams list about this stuff, and those developers are heading in the exact opposite direction of myself - less generic, special inter-module data paths hidden from the user (which I think is an awful idea for the record), and a special ams-specific plugin format with all the bells and whistles. I wish them nothing but the best, but their goals don't coincide with what I need. "Scratching an itch" and all that. I need a good flexible, polyphonic LADSPA-using modular synth, and one doesn't exist. So........ > > After my recent experiments I'd recommend leaving the GUI out of the picture > > for as long as possible, and implementing it in a scripting language instead > > of C++ - I find it a much more productive way of developing, plus your > > software is availible for people who don't want or can't use GUIs with no > > extra work. > > +1 > > Its a bit of extra work at the start, but I find most complex code gets > refactored in that direction eventually anyway. Done and done, thanks to you and liblo. > Not to detract from the importance of good UIs, especially in something > like a modular synth, I dont think any of the linux offerings have really > got close to the standard of things like the nord modular editor > (http://www.clavia.com/G2/editor.htm) yet - it makes a massive difference > to the usability. > > One of the key things in the nord software is the consistency and > compactness of the module UIs though - and thats going to be a lot of work > to get with arbitrary LADSPA plugins as the modules. Well.. we need a way to have LADSPA plugin GUIs... DSSI is a LADSPA-like plugin format with GUIs.... 2 and 2. I never understood why you chose to make DSSI "soft synth" specific to be honest. Can DSSI not solve this problem? I've considered taking a look at those old xml ladspa gui proposals from Paul, but I assume there's some reason noone supported them. For the record, the fact that DSSI UIs talk to the _HOST_ via OSC is very, very cool for me, because that means my synth engine can still run over the network and not deal with GUI issues, which I don't think VST can do. Anyway. on plugin GUIs are alright, but for complicated patches they simply take up too much room. I admittedly work at a lower level than your average nord user probably does though. I planned on going the galan build-your-own-custom-control-panel route - I've never actually found the "buncha sliders" LADSPA GUI approach to hinder productivity anyway, sliders work for me. GUI's would be nice though.. -DR-
