[LAD] IR: Lv2 reverb (without the GUI..?)

David Robillard d at drobilla.net
Fri Sep 2 16:59:39 UTC 2011

On Fri, 2011-09-02 at 17:50 +0100, Harry van Haaren wrote:
> Hey All,
> I'm faced with a problem that I can't see an easy way around regarding
> the use of the IR reverb plugin.
> I'm running the GUI in a seperate *process*, and doing all lv2
> communication over OSC. For the most part this is easy,
> the problem rears its head when one want's to use a plugin whose UI
> requires "instance-access".
> Basically, the IR plugin GUI needs access to the Lv2_Handle. But I
> can't provide that due to the OSC communication.
> So I've concidered "spoofing" a plugin on the UI side, and keeping it
> up to date with what the "real" one is doing in the Engine.
> Bit ugly, and if the UI has instance access, will it still call the
> normal "port" events..? Because otherwise I'm lost with trying to
> get at the UI data.
> The other problem is that loading a "sample" into the IR convolution
> happens in a pretty strange way: there's 3 Control Input ports, and
> together they make up a 64bit file hash.
> I understand the reasons behind this decision, and I'm not trying to
> criticise the implementation, I'm just not sure how I can send a
> certain file to these ports to make it work...

The IR plugin uses instance-access as a kludge because there is not a
good port-based communication mechanism powerful enough to do what it
needs to do (e.g. send 'load file' type events).

This is a known problem, and making such a mechanism is a high priority.
Until that time, IR is basically unusable in a process separated host
(among other problems).

The (truly awful) hash thing can and should be replaced with the use of
the newish persist and files extensions immediately.



More information about the Linux-audio-dev mailing list