Re: [linux-audio-user] Your synth wishlist?

I'm going to reply to a few emails in one go here and then drop out of the thread, because I don't think this is on-topic for LAU any more. If you want to reply further it might be worth taking it to LAD (or even the dssi-devel list on SourceForge -- so far unused -- though I don't think that's really the right place for philosophical discussions about the nature of plugins, more just for practical implementation stuff). On Friday 30 Jul 2004 7:22 pm, Dave Robillard wrote: I agree with it in certain instances. I think a synth plugin format is very appropriate for "small" synths, or for synths that (like most VST instruments) are designed to produce a particular recognisable sound. If you have a decent standalone JACK host as well (and the DSSI example host is not quite good enough yet -- it doesn't do a very good job of dejittering the timing of incoming events) then you have all you need to write a simple plugin and have it work all ways. That's the thing I really like -- the possibility of writing it once and using it in many different ways, which using a plugin API permits. I don't however particularly think you should attempt to make a real modular synth into a DSSI plugin. Anything where the GUI is designed to do serious editing work, rather than just tweaking a few values, is IMHO probably not a great fit. Using external soft synths (JACK/ALSA style) for a sequencer like this is at the moment rather hard to do in a user-friendly way, for various reasons (some of which are outlined in the DSSI RFC). It's great to be able to do it at all, but it's better to have a choice. I just don't think that will happen. Even as a developer of one of the other Cubase-alike applications, I think there's just too much flexibility there: the fact that Rosegarden plugs into a JACK graph so you can use and sync it with freqtweak, Ardour, jack-rack, JAMin etc is of huge benefit to users of Rosegarden just as it would be to any other application. This communication ability is an area in which Linux apps are better than Windows ones, and that benefits all kinds of applications equally. Not "all" the synths. But there are definite benefits to users of sequencers of having synths that can plug tightly into them. Yes, I think so, just as you can write LADSPA plugins that load LADSPA plugins. My view is that for writing plugins, there's rather little effort involved (other than the work you'd be doing to write the synth anyway). DSSI hosts are much harder to write, which is the way it should be. I personally have no great interest in waiting for GMPI just so I can have synth plugins in my sequencer, but GMPI should certainly offer some more interesting stuff (e.g. DSSI lacks any way to invoke notes at frequency rather than simple MIDI pitch, etc). Because it originally arose from a desire to use soft synths in plugins, because we wanted to constrain the requirements to things likely to be useful for straightforward synths, and because it was easier to describe and (if you like) sell the idea than if we called it an extension of LADSPA. There's just too much flameage in extensions of LADSPA. DSSI is a take-it-or-leave it thing that just happens to have LADSPA plugin technology in it. No reason. Although actually you could probably also create pure LADSPA plugins and use DSSI-style GUIs with them with a suitably aware host. I _think_ that Rosegarden 0.9.9 will happily start up a DSSI GUI for a LADSPA plugin as well as a DSSI one if it happens to find one -- I haven't tested it, but the code shouldn't care what sort of plugin it is. Chris