30 Jul
2004
30 Jul
'04
2:36 p.m.
On Fri, 2004-07-30 at 06:12, Steve Harris wrote:
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........
Done and done, thanks to you and liblo.
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. 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. 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-