30 Jul
2004
30 Jul
'04
4:36 p.m.
On Fri, 2004-07-30 at 05:57, Steve Harris wrote:
Loading. LADSPA that is.
Cheers,
-DR-
P.S. Forgive my ignorance of DSSI which is probably glaring. I'll do
some learning
On Thu, 2004-07-29 at 15:26, Dave Robillard wrote:
Well... this is a big one, worthy of the almighty bulleted list:
(this should probably be on LAD. oh well)
-- I'm not sure I agree with this "move the synth into the app" thing..
it reminds me a little too much of the super-integrated commercial audio
applications on windows. If MuSE and similar apps just had intuitive
GUIs for running their audio through jack apps, maybe they wouldn't need
to assimilate everything and attempt to become Cubase. The way things
are now, someone can write a neat MIDI filter app, or jack app that
mangles audio, and it's instantly usable by everyone. If the "Cubase
approach" becomes the norm, this will go away - put it in MuSE (or
whatever) or forget it; which is a much, much higher bar to set for
potential developers. That's a shame really.
I don't see any benefits of moving all the synths into sequencers, only
drawbacks.
That said, that's simply my opinion that coincides with how I like to
make music - I happen to really like the flexibility of this system
(alsa seq, jack, patching apps together, etc.) and think LADCCA was/is a
good solution to the session problem, if it was only used more.
However I can respect that not everyone shares my opinion. (No flamewar
please). I plan on looking into DSSI more closely, but mostly because
it would like a more flexible plugin format to use IN my synth. The
idea of having it run AS a plugin never occurred to me.
I suppose it would be possible, maybe. Is it possible to write a DSSI
plugin that runs LADSPA plugins (loads libraries and whatnot)? If so,
it's a possibility to implement as a DSSI plugin.
But it would be a pretty large effort, and all the flexibility that
comes from the synth being 100% OSC controlled goes down the tubes.
It would be possible (really easy actually) to write a DSSI plugin that
controlled this synth (it could be a full modular GUI and everything),
but the synth would still be a seperate app (the plugin could control
it's jack routing though). That's probably not good enough though eh?
So, what features are important to you in a
synth? What annoys you
about the current crop of linux synths?
Only that the mostly work only as jack clients, not as DSSI/MuseSoftsynth
plugins. I can see that a modular synth would be hard to make work in
these systems (because ofthe automation complexity), but a frozen version
of a particular setup could be made to appear as a muse/ssi synth. I understand that DSSI and Muse softsynth APIs are not
widely used (2 DSSI
hosts, and 1 Muse that I know of), but more synths would propote more host
support.
The first "D" in DSSI is a little disconcerting. How much effort should
I/we really invest in DSSI? I think the "GMPI on the horizon will fix
everything" attitude hurts DSSI quite a bit. GMPI is the Daikatana of
the linux audio world.. will it ever exist?
Anyway, to wrap it all up, I will look into DSSI. Whether it's to add
support for hosting DSSI plugins, or allowing the synth to be a DSSI
plugin itself remains to be seen. I personally think we have a far
greater need for a better plugin format for envelopes, oscillators,
_SAMPLERS_, reverb, etc. than the ability to have whole apps act as
plugins. We don't need that, we have jack. (IMO)
Already
planned (* = working right now):
* Low latency realtime operation via Jack
* 100% LADSPA plugins, not Yet Another Internal Plugin Format
- (DSSI and perhaps VST are being considered)
Do you mean working as, or loading?