Re: [DSSI] how about a 1.0?

[Sean B. <smb...@jp...>]

Hi all,

On Dec 13, 2006, at 9:44 AM, Chris Cannam wrote:
> Host-provided threads don't seem as urgent as they did, as I think the
> necessity came from problems with an older pthread implementation (I'm 
> about
> to do some testing with Whysynth on a new machine so I might regret 
> those
> words -- we'll see).

I've been getting (infrequent but) good feedback on WhySynth, so the
plugin-created background thread doesn't seem to be breaking things.
IIUC, dssi_convolve also creates a separate worker thread.  Perhaps it
isn't a issue anymore?

> Does DSSI need MIDI output
> and transport info enough to make the effort of putting them in and
> documenting them properly worthwhile, when weighed up against the 
> possible
> future alternatives such as LV2?  Is it worth returning to those 
> things now,
> or do we have nothing to lose from just relabelling the current API as 
> 1.0?

Folks in the synchronized bleeps crowd could do some pretty cool stuff
with transport info, and I think we were pretty close to a useful 
implementation.
MIDI output wasn't as clear; I don't think the potential applications 
are
understood very well.

In looking at the state of DSSI a couple months back, I noticed that the
only two plugins to implement run_multiple_synths() are hexter and
fluidsynth-dssi.  The only hosts to correctly implement it are
Rosegarden, jack-dssi-host, and ghostess.  All the other hosts I saw
either limit a r_m_s()-using plugin to a single concurrent instance, or
punt in some even less useful way.

But I can't say I blame them -- for hosts like Om/Ingen and Pd, that
process a complex synthesis graph one node at a time, r_m_s() is
at best a pain in the ass and at worst, simply impossible.

I've also still never thought of a useful way for a plugin to offer both
run_synth() and run_multiple_synths(), since the plugin has no
way to know which the host will call, and the setup for each function
is inevitably different.

run_multiple_synths() is ubercool when you need it, but if I were to
pick out the single factor that most complicates hosts, and therefore
most slows the adoption of DSSI, this would be it.

One option: add to the API some way for the host to tell the plugin,
before the DSSI_Descriptor gets returned, whether it would prefer
run_synth() or run_multiple_synths().  Then a plugin could choose
which to offer, host authors would feel less pressure to implement
r_m_s(), and Om users could have multiple concurrent hexter
instances in their graphs.

Another option: drop run_multiple_synths() altogether. Maybe in
conjunction with the move to LV2.

Anyhow, that's what comes to mind in response to your question,

-Sean (shaking a little more salt on that crow.)