API for Interprocess communications

[Christoph Hart]

Do you need a real interprocess connection or do you just want two instances of the same plugin loaded in the same host talk with each other?

[Levitanus]

@christoph-hart said in API for Interprocess communications:

two instances of the same plugin loaded in the same host talk with each other

something similar

[Christoph Hart]

In this case a simple static object that is shared among all plugin instances should do the trick. What data type you need and has it to be real time safe?

[d.healey]

@christoph-hart Oh this could be really useful for creating divisi setups if each instance can know the current settings of the other instances :D

[Levitanus]

@d-healey said in API for Interprocess communications:

divisi setups if each instance can know the current settings of the other instances

I'm implementing divisi inside instance yet and would ask for not realtime-safe objects just for synchronising preferences of the library. But the idea is so sweet...

@christoph-hart said in API for Interprocess communications:

What data type you need and has it to be real time safe?

There're pros as for int array as well as for float array. Int as flags holder and float as knobs holder

P.S. Reaper, for example, has float array of size ~100000, shared between all JSFX. So, JSFX developer choosing offset and using some of this array. scary, but still works))

[Christoph Hart]

Yeah thats weird. You will most likely get a Javascript var that you can fill with any data type. Do you need a callback when sending values or is polling enough?

And David what do you need for divisi?

[Levitanus]

@christoph-hart said in API for Interprocess communications:

And David what do you need for divisi?

I think, within

@christoph-hart said in API for Interprocess communications:

Javascript var that you can fill with any data type

we would have everything needed for divisi))

@christoph-hart said in API for Interprocess communications:

Do you need a callback when sending values or is polling enough?

I think a simple timer will handle that. Of course, I'll find the use-case for some sort of on_shared_changed, but it is not necessary.

[d.healey]

@christoph-hart Not sure yet, it was just a fleeting thought. I remember LASS had a setup where you could load each divisi section up as a different patch but you had to check all the settings for each one to make sure they were correct. If the instances could talk to each other then all the setup could be automated - non-realtime stuff.

[Levitanus]

@d-healey said in API for Interprocess communications:

LASS had a setup where you could load each divisi section up as a different patch but you had to check all the settings for each one to make sure they were correct.

as I remember there was a weird logic, that translates all midi data to every instrument, and inside it choose its part. But even if it was inside multiscript, still it was realtime midi-processor. There is no way to split parts in different plugins not connected to the shared midi-data.

[d.healey]

@levitanus Yes I think you're right. It's been a long time since I used LASS

[d.healey]

I thought of another use case for this. If I load in multiple instances of my plugin and I want to purge a mic position in all instances I have to go to each instance individually and click the purge button. If I could link all the instances together and just set the purge state on one it would be much faster.