|
|
|
10-09-2016, 04:03 PM
|
#1
|
Human being with feelings
Join Date: Jan 2008
Posts: 506
|
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.
|
|
|
10-09-2016, 10:21 PM
|
#2
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
|
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
|
|
|
10-09-2016, 11:13 PM
|
#3
|
Human being with feelings
Join Date: Jan 2008
Posts: 506
|
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
|
|
|
10-10-2016, 05:08 AM
|
#4
|
Human being with feelings
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
|
Quote:
Originally Posted by Guod3
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.
|
|
|
10-10-2016, 09:57 AM
|
#5
|
Human being with feelings
Join Date: Jan 2008
Posts: 506
|
Quote:
Originally Posted by Xenakios
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?)
|
|
|
10-10-2016, 12:29 PM
|
#6
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
|
Quote:
Originally Posted by Guod3
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
|
|
|
10-10-2016, 03:31 PM
|
#7
|
Banned
Join Date: Sep 2015
Posts: 1,650
|
Quote:
Originally Posted by Guod3
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.
|
|
|
10-10-2016, 04:37 PM
|
#8
|
Human being with feelings
Join Date: Jan 2008
Posts: 506
|
Quote:
Originally Posted by mschnell
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
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
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/
|
|
|
10-10-2016, 09:43 PM
|
#9
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
|
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
|
|
|
10-11-2016, 12:02 AM
|
#10
|
Human being with feelings
Join Date: Jan 2008
Posts: 506
|
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.
|
|
|
10-11-2016, 03:18 AM
|
#11
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
|
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
|
|
|
10-11-2016, 03:28 AM
|
#12
|
Human being with feelings
Join Date: Jan 2008
Posts: 506
|
Quote:
Originally Posted by mschnell
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.
|
|
|
10-11-2016, 08:01 AM
|
#13
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
|
Quote:
Originally Posted by Guod3
No one buys (or "carries") anything
|
BOM = $0, Weight = 0g
Hard to believe..
-Michael
|
|
|
10-11-2016, 04:26 PM
|
#14
|
Human being with feelings
Join Date: Jan 2008
Posts: 506
|
I think boost is a contender. If there are others I'd be interested to hear.
|
|
|
10-12-2016, 05:00 AM
|
#15
|
Human being with feelings
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
|
Quote:
Originally Posted by Guod3
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.
|
|
|
10-12-2016, 07:00 AM
|
#16
|
Human being with feelings
Join Date: Jan 2008
Posts: 506
|
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.
|
|
|
10-13-2016, 05:18 PM
|
#17
|
Human being with feelings
Join Date: Jan 2011
Location: Ottawa, Canada
Posts: 293
|
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
|
|
|
10-13-2016, 05:44 PM
|
#18
|
Human being with feelings
Join Date: Jan 2008
Posts: 506
|
Quote:
Originally Posted by DrFrankencopter
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
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.
|
|
|
10-13-2016, 09:53 PM
|
#19
|
Human being with feelings
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,690
|
Quote:
Originally Posted by DrFrankencopter
none of these are really cross platform though, ..
|
Sockets are. Even literally, as they can used between two boxes connecting Windows and OSX.
-Michael
|
|
|
10-14-2016, 04:32 AM
|
#20
|
Human being with feelings
Join Date: Jan 2011
Location: Ottawa, Canada
Posts: 293
|
Quote:
Originally Posted by mschnell
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
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 03:36 AM.
|