Re: [Lmuse-developer] FLAM support

[Tim E. R. <ter...@ro...>]

On April 1, 2011 05:17:48 am Luis Garrido wrote:
> On Fri, Apr 1, 2011 at 8:45 AM, Tim E. Real <ter...@ro...> wrote:
> > Hi Luis, and list!
> > Just committed some support.
>
> Hey, Tim, that's great news, thanks a lot! I'll give it a spin this
> weekend.
>
> > But got a problem:
> > In MusE with the Caps ToneStack example (which works in RG)
> >  Flammer opens and says:
> > [Titlebar of embedded window:] "channel-1"  (That's correct, for MusE.)
> > [Text:] "Could not find a UI file for /usr/lib64/ladspa/caps:ToneStack"
> >
> > Any suggestions?
>
> According to the spec, the soname parameter should not contain any
> path info, it should be just caps.so, not /usr/lib64/ladspa/caps.so.
> If it works with DSSI is because those GUIs don't make any use of this
> parameter.
Committed fixes.
Thanks! You helped find some improper stuff.

Note when testing DSSI and OSC stuff:
Due to a bug caused or not addressed by me when I overhauled
 the audio engine, no processing seems to be happening if 
 a track is unconnected. That includes OSC messages!
So if you are testing with the default MusE project (it has a single 
 Audio Out track), make sure to connect something to it, like a
 Wave track or Audio Input track.

Also for some reason the FLAM UI controls don't sync with the
 standard MusE LADSPA GUI controls, if both UIs happen to be open.
They do if the plugin is a DSSI effect plugin, or a DSSI-VST
 effect plugin although that seems to be only one-way sync 
 and I thought two-way was working before...
Or something like that... Must check some more.
Well, anyway, it mostly works for now.

>
> > These UIs are a GREAT idea! I imagine a ready made collections of them
> > for all the popular plugins, maybe get the original authors interested.
> >
> > But what happens if multiple (competing) collections want to be
> > installed? Naming headaches, requiring an ID system?
> > And what if other DSSI-and-FLAM-like software wants to play too?
> > How can these synths/generators be aware of what each other might
> > install?
>
> GUI executables can use a suffix for that: _qt, _gtk, but also _flam,
> _foobar... I used _gui in the primer because RG allows only a fixed
> set of suffixes, but that's a RG shortcoming that should be easy to
> fix to allow for arbitrary suffixes. It is up to the host to decide
> which one to use, or even present a choice to the user. I plan to
> recommend using _flam for FLAM-based plugins, once host support starts
> to spread.
>
> > And is it reasonable to expect that a library might even have
> > library-level UIs (myplugins_gui) AND plugin-level UIs (plugin_gui), even
> > multiple versions?
>
> I think the DSSI spec precludes that, GUIs are always per-plugin.
What about dssi-vst?
I had in mind there a library which has both a myplugins_gui and 
 two or more plugin_gui.
myplugins_gui would operate on 'global' controls common to each
 plugin in the library. Is it do-able?

>
> Cheers,
>
> Luis

So here is the way I did the order of automatic UI preference for now:
FYI It all happens in PluginIBase::dssi_ui_filename().

Prefer any plugin-level UI with "_qt". 
Prefer any plugin-level UI with "_". 
Prefer any lib-level UI with "_qt". 
Prefer any lib-level UI with "_". 
Else no suitable UI file found.

Theoretically it means you could have custom UIs for individual dssi-vst 
 plugins, which overrides dssi-vst_gui. If such a thing is possible!

Well, let me know if you notice any other problems, oddities.
Will check my DSSI support some more and try to fix more stuff.

Happy weekend. Tim.