Old 10-09-2016, 04:03 PM   #1
Guod3
Human being with feelings
 
Guod3's Avatar
 
Join Date: Jan 2008
Posts: 506
Default Inter plugin communication? (cross platform)

I'm writing a simple VST2.4 plugin where the idea is that each instance sends low bandwidth midi (notes, small sysex messages) to a multiclient hw midiport (not enabled in the host).

During plugin startup each instance will acquire a unique midi channel and id that it will use in outgoing communication (it's midi out only). So a shared resource would be accessed by each plugin instance on setup and teardown to coordinate this.

Is there a go-to cross platform library that fits this outline?
From what I've outlined high performance should not be a criterion.

Thanks for any suggestions or comments.
Guod3 is offline   Reply With Quote
Old 10-09-2016, 10:21 PM   #2
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
Default

Why ?

IMHO it would be as well a lot easier to do as moer versatile and more "standard", to use normal system-independent means (i.e. Midi out and in routed via the VST host) for such purpose than to try to hide the inter-instance communication from the user.

-Michael
mschnell is offline   Reply With Quote
Old 10-09-2016, 11:13 PM   #3
Guod3
Human being with feelings
 
Guod3's Avatar
 
Join Date: Jan 2008
Posts: 506
Default

The application is a hardware based midi monitor. The user simply drops the VST in instrument tracks they want monitored, sets some optional properties of display style etc, then are done. All routing and allocation etc, is handled behind the scenes.

I think I have a contender:http://www.boost.org/doc/libs/1_62_0...erprocess.html
Guod3 is offline   Reply With Quote
Old 10-10-2016, 05:08 AM   #4
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by Guod3 View Post
The application is a hardware based midi monitor. The user simply drops the VST in instrument tracks they want monitored, sets some optional properties of display style etc, then are done. All routing and allocation etc, is handled behind the scenes.

I think I have a contender:http://www.boost.org/doc/libs/1_62_0...erprocess.html
Boost interprocess is for cross process communications, so might be overkill for communicating between multiple plugins within a single process.

Why not just use a global variable in your plugin...? (Global variables are shared between plugin instances in the same process.)
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 10-10-2016, 09:57 AM   #5
Guod3
Human being with feelings
 
Guod3's Avatar
 
Join Date: Jan 2008
Posts: 506
Default

Quote:
Originally Posted by Xenakios View Post
Why not just use a global variable in your plugin...? (Global variables are shared between plugin instances in the same process.)
That's great to know, and will definitely help me get started with this!

As things develop, I can make it more robust. The boost libraries seem elegant. I suppose a user monitoring midi on multiple hosts simultaneously is unusual (but possibly useful).

Are there more common situations where plugin instances run in separate processes? (Hosts other than REAPER perhaps?)
Guod3 is offline   Reply With Quote
Old 10-10-2016, 12:29 PM   #6
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
Default

Quote:
Originally Posted by Guod3 View Post
The application is a hardware based midi monitor.
Of course there are lots of ways to do inter-process communication.

But if you say it "hardware" it would need a standard PC interface anyway, so why not just access this interface (e.g USB or TCP/IP) from the plugin with the standard OS API ?

-Michael
mschnell is offline   Reply With Quote
Old 10-10-2016, 03:31 PM   #7
snooks
Banned
 
Join Date: Sep 2015
Posts: 1,650
Default

Quote:
Originally Posted by Guod3 View Post
Are there more common situations where plugin instances run in separate processes? (Hosts other than REAPER perhaps?)
Bitwig runs plugins in their own processes. You can do this in Reaper too, but it's not on by default.
snooks is offline   Reply With Quote
Old 10-10-2016, 04:37 PM   #8
Guod3
Human being with feelings
 
Guod3's Avatar
 
Join Date: Jan 2008
Posts: 506
Default

Quote:
Originally Posted by mschnell View Post
Of course there are lots of ways to do inter-process communication.
Yes, this is the topic and I've asked for suggestions on how, or what way

Quote:
Originally Posted by snooks View Post
Bitwig runs plugins in their own processes. You can do this in Reaper too, but it's not on by default.
IIRC there is a choice in Bitwig as well. But this reinforces the need for robust IPC.

Quote:
Originally Posted by mschnell View Post
But if you say it "hardware" it would need a standard PC interface anyway, so why not just access this interface (e.g USB or TCP/IP) from the plugin with the standard OS API ?
Yes, as I said there will be a Midi port opened to talk with the monitor HW.
In any case there is a need for IPC (the plugins are sharing a resource in application specific ways, ie the monitor HW).
BTW;the hardware is based on the Midibox platform:http://www.ucapps.de/
Guod3 is offline   Reply With Quote
Old 10-10-2016, 09:43 PM   #9
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
Default

If you want a platform independent way of IPC TCP/IP sockets might be a way to go, as pipes, shared memory, and other things are implemented differently in different OSes. Moreover TCP/IP can be used to access external hardware ini a platform independent way.

But It you want "Midi", I still don't see an advantage above using the VST Midi interface, that can do inter VST communication in a platform independent standard way (thanks of Reaper's VST bridging feature also independent of 32/64 Bit issues) .

-Michael
mschnell is offline   Reply With Quote
Old 10-11-2016, 12:02 AM   #10
Guod3
Human being with feelings
 
Guod3's Avatar
 
Join Date: Jan 2008
Posts: 506
Default

The boost Interprocess library offers a range of communication mechanisms that is cross platform, follow the link if you're interested.

The project is developing a midi monitor using the (Midibox Hardware Platform) MBHP which offers excellent USB and uart midi comms on a variety of embedded targets with heaps of peripheral options. I'd invite anyone interested to take a look!

The VST instances are sharing a resource (the monitor) and have to communicate to make this work. Eg. Another instance is displaying notes in "red" already, so a new instance has "red" shown as unavailable in the colour chooser of its GUI, etc, etc.

I can't say it clearer than that.
Guod3 is offline   Reply With Quote
Old 10-11-2016, 03:18 AM   #11
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
Default

Seemingly this is supposed to be an "DAW internal Midi stream probe" using external hardware.

I admit that I fail to see a decent use of that, regarding that the user needs to buy and carry some hardware device.

-Michael
mschnell is offline   Reply With Quote
Old 10-11-2016, 03:28 AM   #12
Guod3
Human being with feelings
 
Guod3's Avatar
 
Join Date: Jan 2008
Posts: 506
Default

Quote:
Originally Posted by mschnell View Post
Seemingly this is supposed to be an "DAW internal Midi stream probe" using external hardware.

I admit that I fail to see a decent use of that, regarding that the user needs to buy and carry some hardware device.

-Michael
The point of the project is a hardware device. The VST plugin allows close deep integration with DAW. No one buys (or "carries") anything, Midibox is DIY, open source community for enthusiasts. This has gone way off topic.
Guod3 is offline   Reply With Quote
Old 10-11-2016, 08:01 AM   #13
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
Default

Quote:
Originally Posted by Guod3 View Post
No one buys (or "carries") anything
BOM = $0, Weight = 0g

Hard to believe..
-Michael
mschnell is offline   Reply With Quote
Old 10-11-2016, 04:26 PM   #14
Guod3
Human being with feelings
 
Guod3's Avatar
 
Join Date: Jan 2008
Posts: 506
Default

I think boost is a contender. If there are others I'd be interested to hear.
Guod3 is offline   Reply With Quote
Old 10-12-2016, 05:00 AM   #15
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by Guod3 View Post
I think boost is a contender. If there are others I'd be interested to hear.
It was a bit unclear in your original posting what you actually want to do. I took "inter plugin" to mean communication between plugin instances running inside one process. Then using simple global variables should be enough. (With all the usual precautions for multiple threads access etc...)

If you have things running in multiple processes, then you will of course need something like Boost's interprocess library. Cockos's WDL library also has a shared memory implementation, but when I've tried using it, it has turned out a bit complicated and messy because IIRC there's no official example on how to use it. (When used correctly, it should work out OK, though, since it is after all also used for Reaper's plugin bridging...) Networking done on localhost is also a classic solution for interprocess communications.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

Last edited by Xenakios; 10-12-2016 at 05:06 AM.
Xenakios is offline   Reply With Quote
Old 10-12-2016, 07:00 AM   #16
Guod3
Human being with feelings
 
Guod3's Avatar
 
Join Date: Jan 2008
Posts: 506
Default

The use of global variables for plugins running in a common process is great to know. I should be able to get the basic functionality right using that. Then perhaps work on making it all more robust and versatile. For example being able to run the monitor on tracks running in different hosts on the same machine connected by say rewire could be good to have.
Some criticism has been made in this thread in regards to my concept of a hardware monitor. However the methods and ideas could also be used in a custom visualisation window in the same host. Ableton has this seemingly basic limitation that you can only ever see one midi editor window at a time!!!
The boost library seems straight forward reading about it but I'll see how that pans out. I imagine there are lots of examples and information on localhost networking.
Guod3 is offline   Reply With Quote
Old 10-13-2016, 05:18 PM   #17
DrFrankencopter
Human being with feelings
 
Join Date: Jan 2011
Location: Ottawa, Canada
Posts: 293
Default

It's been a while since I wrote a vat plugin, but I think that global variables will work for plugins loaded in one DAW application (provided separate instances are not launched as separate processes), but it will not cross from one VST host to another (e.g Reaper and Reason running on the same machine).

Perhaps take a look at data_seg() (on Windows)...I've used it to get audio from one host to another, and make busses. Alternatively, shared memory, or memory mapped files, or good ole Sockets. Unfortunately none of these are really cross platform though, but the basic concepts can carry over from one OS to another.

Cheers

Kris
DrFrankencopter is offline   Reply With Quote
Old 10-13-2016, 05:44 PM   #18
Guod3
Human being with feelings
 
Guod3's Avatar
 
Join Date: Jan 2008
Posts: 506
Default

Quote:
Originally Posted by DrFrankencopter View Post
It's been a while since I wrote a vat plugin, but I think that global variables will work for plugins loaded in one DAW application (provided separate instances are not launched as separate processes), but it will not cross from one VST host to another (e.g Reaper and Reason running on the same machine).
Initial experiment shows that in Reaper, the plugin instances get created in order of track number. The fact of globals being shared amongst instances was welcomed news to me! I'll enhance to true IPC later...
Quote:
Originally Posted by DrFrankencopter View Post
Perhaps take a look at data_seg() (on Windows)...I've used it to get audio from one host to another, and make busses. Alternatively, shared memory, or memory mapped files, or good ole Sockets. Unfortunately none of these are really cross platform though, but the basic concepts can carry over from one OS to another.
The boost Interprocess library offers cross platform using many of these techniques. In cases, the underlying mechanisms between OS's have differences but the library offers the possibility of writing one source code.
Guod3 is offline   Reply With Quote
Old 10-13-2016, 09:53 PM   #19
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
Default

Quote:
Originally Posted by DrFrankencopter View Post
none of these are really cross platform though, ..
Sockets are. Even literally, as they can used between two boxes connecting Windows and OSX.

-Michael
mschnell is offline   Reply With Quote
Old 10-14-2016, 04:32 AM   #20
DrFrankencopter
Human being with feelings
 
Join Date: Jan 2011
Location: Ottawa, Canada
Posts: 293
Default

Quote:
Originally Posted by mschnell View Post
Sockets are. Even literally, as they can used between two boxes connecting Windows and OSX.
Sure sockets enable the Internet; but the implementation is different on MacOS and Linux with their BSD sockets versus windows and its winsockets. Not huge differences...like I said the same basic concepts can be used, but with some differences in implementation depending on the OS.

Cheers

Kris
DrFrankencopter is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:36 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.