2 Sep
2011
2 Sep
'11
7:58 p.m.
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.
Cheers,
-dr