On Tuesday 27 Apr 2004 11:24 pm, Jens M Andreasen wrote: We should have been a bit more explicit about this. The intention is that a DSSI synth only has one channel. It should ignore the channel on incoming MIDI events. If you want more than one channel, you instantiate more than one synth: the host does the routing and the result should be the same. I would assume that the plugin developer was sensible enough to share any shareable data behind the scenes. As Steve points out, the /midi method is optional, and it's really only intended for sending test tones. The host uses a specific API to query and select programs on the synth rather than use MIDI program changes, because it wants to know about the available set of programs and what they're called: given that the host isn't using MIDI program change, it makes sense that the UI shouldn't either. We have generally tried to reduce the number of cases where the plugin may end up with more than one code path to achieve the same result. Like most of the decisions in a design like this, you can argue this either way. We reckoned it was a bit simpler to write and understand the plugins this way, with no visible difference to the user. Chris

On Thursday 29 Apr 2004 10:50 am, Tim Goetze wrote: So are we, so anything that helps clarify the right way to handle it is welcome. The intention is exactly as you describe -- you need a way to do things like saying which soundfont, sample set etc to load. But it's the one main thing that isn't implemented yet in the sample host, plugin or GUI so we haven't the experience of ironing out the obvious problems yet. That said, these are the intentions at the moment: It doesn't. The assumption is that the host just passes on whatever the GUI selects, and it's up to the GUI (which of course is provided by the plugin author, or at least built to match the plugin) to understand the key value pairs. Of course that means if you have no GUI you can't use configure(), but the alternatives do seem potentially rather complicated. Nothing to the host, it's just passed back to the GUI. The host doesn't need to care about these during operation -- it just needs to know the last value set for each key so that it can restore state next time the "same" plugin is instantiated. LADSPA and the rest of DSSI generally don't include ways to query current settings from a plugin: for port values, programs, etc the host is expected to keep track of the current state and assume the plugin doesn't know about it until told. This way is at least consistent with that. Chris

On Thursday 29 Apr 2004 11:32 am, Tim Goetze wrote: Only if you actually need the configure() stuff, which many plugins might not. But I agree it's not exactly ideal. Better ideas welcome. I don't think OSC knows anything about "configuration" as such, it's just a delivery mechanism for passing typed arguments to named methods. Steve's really the OSC nut though: I'm just happy that it's reasonably simple and it works. Chris

[Steve Harris] OK, this makes things a little clearer. i'm still looking for ways to do without the GUI, so the question becomes: are the contents of "myfile.dat" in a plugin-specific format or is it supposed to be a common format -- something like a simple list of key<->value pairings as passed to configure()? and are DSSI plugins supposed to come with a sample commented "myfile.dat" or alternatively a data sheet explaining configuration options? tim

[Steve Harris] so gui-less application is eventually possible by running the gui for configuration, saving the state and restoring it when running headless. that or the plugin author provides configuration info. sounds fair enough, but still requires you to install X and the toolkit of the plugin's choice. i'd please like to see the RFC/header amended recommending plugin authors to provide documentation of keys and values for configure() (return values included). tim

[Jack O'Quin] you can, but you need to know what to send in the first place, i.e. the names of configuration options and their value spaces (polyphony, sound patch file location etc). to obtain a useful initial configuration you'll need to configure the plugin via the GUI it came with, or construct configuration messages from some sort of plugin conf documentation provided instead or along with the X interface. i'm inclined to think that free-form docs are sufficient. it would be nice to have a complete conf language but the effort implementing that is likely to be huge or require yet another library or both, and maybe not even worth it. tim

[Steve Harris] i like the spec as it is, but i'm not entirely comfortable with the 'disposable' attribute. for one thing, i'd not like to see the idea disposed of before it becomes used ... :) for another, with increasing adoption, 'disposable' becomes 'definite' soon enough, whether we like it or not. so far, the only weakness i see is the lack of support for GUI-less operation, which can easily be amended by making conf documentation mandatory (synthesis parameters that aren't accessed through LADSPA ports should also be documented i think). sure, you can reconstruct that info by going over source code, but i'd rather you needn't. tim

On Sat, May 01, 2004 at 12:38:43 +0200, Tim Goetze wrote: There UI's, not GUI's, thye might require X, but equally they might require a MIDI fader box, or a games console controller, or any other wacky device you can imagine. But yeah, the idea is that if you dont run the UI the plugin will still come up in the state it was last. Its not mandatory to use configure() or provide a UI, probably many can do without - eg. a piano keyboard driven pitchshifter doesnt really require a custom UI and definatly doesnt need configure. - Steve

On Thursday 29 Apr 2004 11:56 am, Robert Jonsson wrote: That's true if you are using the ALSA sequencer to deliver MIDI events. DSSI only uses the ALSA sequencer event types, it does the delivery just by passing events to the plugin at run() time (much like VSTi, except it uses parsed events rather than raw MIDI). It should be fine for non-reaitime use. We mentioned it in the RFC as one of the possible existing alternatives (under the name "libsynti"): It is probably the closest alternative to the present proposal, it addresses many of the same problems, it is working now, and it is an attractively small API. Unfortunately it is unlikely to be popular as a standard for Linux audio plugins, simply because it is in C++ and requires Qt for plugin GUIs. Since I use C++ with Qt myself, that doesn't bother me, but it's not really for me to say how far that would put off other developers -- probably quite a bit, given some of the arguments we get. Maybe someone close to the MusE API could write it up for comparison here. Chris