feature request: linked instances about bschaffl HOT 13 CLOSED

Haha, definitely don't use OSC for this type of thing, that was a pretty rookie mistake :)!

I ended up using the JUCE SharedResourcePointer, which isn't too compilcated, so you could probably roll your own (or just copy their implementation, under GPL).

The basic design pattern was to have a SharedData class (one instance shared by all the plugin instances) that stores the parameter values for each "mix group" and the IDs of the plugin in each mix group, and a Controller class (each plugin instance gets it's own) that listens for parameter changes, and passes data back and forth between the SharedData and the rest of the plugin.

My implementation is all in this directory, please let me know if you have any questions, or if there's any way I can help!

from bschaffl.

Thanks for your tips. I also thought about it for the whole day. Although we use different tools (you JUCE, me directly targeting LV2), I ended up with similar ideas as you described. It's quite clear that it must be sth. in the global context of the plugin (not in an instance). One idea (very similar to yours) is to globally share the plugin data. The other one would be a simple std::vector containing pointers to all active plugin instances. Anyway both approaches will only work for hosts which do not sandbox the plugin instances.

But first of all I will have a more detailed look to your code to understand the way you gone.

from bschaffl.

Thanks a lot for looking into this!

I use B.Schaffl in almost all my music now!

from bschaffl.

... also not supported yet: shape.

I tested it in ardour6 and carla2.3. Jalv will not work as jalv only hosts one plugin instance. Of course, you can start different instances of jalv (each hosting one plugin instance). But this is sth. different. And this will not work. As each jalv instance individually loads the plugin file (and its individual shared data).

The time lag is expected if you think about control routing:

1. Drag a slider in the master GUI. But is GUI is usually called 20 to 60 times per seconds. = 15 to 50 ms latency.
2. GUI sends data via the host to the DSP. DSP run() stores the data to the shared data. DSP run() is usually called every 5 to 20 ms depending on your settings (buffer_size / frame_rate). += 5 to 20 ms latency.
3. If the slave is routinely called before the master, the slave can get the updated shared data only in the next call of DSP run(). += 5 to 20 ms latency.
4. And the slave DSP has to send the data to the slave GUI. += 15 to 50 ms latency.

from bschaffl.

Challenging. At least for me. I never tried to get access to different instances of the same plugin. Maybe via (ugly) global variables? I'm not sure. Any other ideas? I remember there was a (bit) similar request by @iurie-sw about the plugin instance ID in the LV2 devel mailing list.

from bschaffl.

Great that you seem to like the idea!

Going by the commit messages, CHOWTapeModel did it via OSC at first and at the moment they do it through a shared resource pointer.

Hope that helps. If not, maybe @jatinchowdhury18 can chip in?

from bschaffl.

Now I found some time to get an overview about how CHOWTapeModel handles shared data. It is programmed in a clear way. I like it. And it is similar to my idea.

The pitfalls are beyond the use of shared data. The main problems would be the LV2 control_ports I used for all the sliders (read only from the plugin side) and the backward compatibility if I have to switch to LV2 parameters (read and write, but limited support by the hosts). Thus, my solution wouldn't be as smart & slim as those by @jatinchowdhury18 .

from bschaffl.

Something like this: 7389f41 ?

It's experimental, yet. Just a preview. Not all features are implemented. Like state:save and state:restore (required for close & reopen plugin). And it might be a bit buggy. I still have to optimize signal routing. If I would have planned the implementation of such a feature before, I would have done signal routing between DSP and GUI in a less complicated way than I did. And now I the shared data routing on top.

from bschaffl.

Cool! Thanks a lot! :)

As you said: close and reopen messes things up.
Also: it works in Ardour, but when I open the plugin twice in jalv.gtk, it does not link.
Not that I think it will be used like that, but it might be useful debugging info for you.
There is a bit of lag between the master and slave. Doesn't matter, just reporting.

I've found no other bugs yet.

from bschaffl.

State save / restore added in e5fc336 .

Now working on storing the shape into the shared data.

from bschaffl.

Some of the reported lag problems are fixed in 01b3623 . One less data transfer step.

from bschaffl.

And finally shape added to shared data in 48b43a3 . Some testing before release 1.4.0 is needed. @magnetophon , let me know if you find some bugs.

from bschaffl.

Perfect; thank you!

No bugs so far, I'll keep you up to date!

from bschaffl.