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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
