In a topic on Synthforum, we were discussing midifeedback in Reaper (more precise: The lack of it).
For my system I created a CSurf C++ plugin, which makes midi feedback from Reaper possible.
However, it is not without quircks.
So what CAN it do:
- It will send all parameter changes for all VSTs to the outside world
- You can send commands to the CSurf so that it changes any parameter of any VST in Reaper.
Moreover:
- You can ask the name for all plugins in the current setup
- You can ask all parameternames and parametervalues for any plugin
- You can invalidate a track so that all data for that track will be resend
and there are a few things more.
To continue with the good news:
You can communicate with the plugin in two ways:
- Through a TCP connection (This is pretty hi-speed)
- Through a Virtual Midi Port.
BTW, setting this is in the only User Interface the CSurf has.
Now, the not so good news...
First, my interface has only been tested by me and is only used in my own software setup.
That works flawlessly, but it is not enough to call this generic software. But that may change.
Second, and that is the real flaw, the CSurf must check all parameters of all plugins to note if a parameter
has changed (polling). Allthough Reaper has functions which notifies the CSurf when you turn a knob in the user interface,
it does NOT notify you that parameters have changed if you change a preset in your VST. Moreover, most VSTs don't
even notify Reaper if they change preset (most systems with their own browser don't use the SDK 2.4 spec for that anymore).
[I know Reaper has a OSC interface but that also does not report parameter changes when changing preset ]
This flaw can be handled in many ways and for now I have programmed two solutions:
The first solution looks for a configuration file in which you define which VSTs and which parameters you want to follow.
Moreover, it only looks at the first VSTi plugin per track. For me that is a perfect solution, but for a general solution it is maybe not ok.
In my second solution the CSurf reports every change in the Track Layout to the outside world. It does NOT report any parameter changes
until you send commands to the CSurf and tell it to do so (By sending a list of parameters which should be reported).
I can imagine that you would like a mix of both solutions, or maybe just ignore the whole problem and let the CSurf just report all changes.
(that may be slow, I don't know allthough I did some tests in the past).
I have to reprogram that, but I am perfectly willing to.
So, the bottom line of drawbacks: Not well tested and the response for parameter changes might be too slow.
So, if you're still here... you might want to help.
You can help in adressing both points mentioned above. You can test if you like (I'll send you the dll's. I will open up the sourcecode as soon as
I've sorted out a nice solution for the second part) and tell me what you like or dislike. Also ideas on the second flaw can be discussed.
Ohhh, and there is one more problem for you as user. I mentioned that you can send commands to the CSurf and that you get feedback from the CSurf.
Setting up the communication channel is not trivial (certainly not if you are using TCP, which is the preferred method because I think it is faster).
The second 'problem' is the communication protocol. It is all SysEx. The command for
changing parameter 1 to value 2 to VST 3 on Track 4 is as follows:
F0 25 3 18 0 19 2 F7
The protocol was invented to have a minimum of databytes, but sacrifices simplicity.
Luckely there is documentation explaining this and maybe I should change it a bit.
Still there? A few more pros and cons:
Only works for Windows (but does not use much Windows specific stuff...)
Only supports 64 Tracks
The CSurf also has some transport functions (starting/Stopping, notifying Start/Stop) and can also read/write the Track Volume settings.
The Csurf can also open and close plugins and change screensets.
(The last two options are available in a lot of extentions, maybe I should remove them to get a cleaner commandinterface)
For my system I created a CSurf C++ plugin, which makes midi feedback from Reaper possible.
However, it is not without quircks.
So what CAN it do:
- It will send all parameter changes for all VSTs to the outside world
- You can send commands to the CSurf so that it changes any parameter of any VST in Reaper.
Moreover:
- You can ask the name for all plugins in the current setup
- You can ask all parameternames and parametervalues for any plugin
- You can invalidate a track so that all data for that track will be resend
and there are a few things more.
To continue with the good news:
You can communicate with the plugin in two ways:
- Through a TCP connection (This is pretty hi-speed)
- Through a Virtual Midi Port.
BTW, setting this is in the only User Interface the CSurf has.
Now, the not so good news...
First, my interface has only been tested by me and is only used in my own software setup.
That works flawlessly, but it is not enough to call this generic software. But that may change.
Second, and that is the real flaw, the CSurf must check all parameters of all plugins to note if a parameter
has changed (polling). Allthough Reaper has functions which notifies the CSurf when you turn a knob in the user interface,
it does NOT notify you that parameters have changed if you change a preset in your VST. Moreover, most VSTs don't
even notify Reaper if they change preset (most systems with their own browser don't use the SDK 2.4 spec for that anymore).
[I know Reaper has a OSC interface but that also does not report parameter changes when changing preset ]
This flaw can be handled in many ways and for now I have programmed two solutions:
The first solution looks for a configuration file in which you define which VSTs and which parameters you want to follow.
Moreover, it only looks at the first VSTi plugin per track. For me that is a perfect solution, but for a general solution it is maybe not ok.
In my second solution the CSurf reports every change in the Track Layout to the outside world. It does NOT report any parameter changes
until you send commands to the CSurf and tell it to do so (By sending a list of parameters which should be reported).
I can imagine that you would like a mix of both solutions, or maybe just ignore the whole problem and let the CSurf just report all changes.
(that may be slow, I don't know allthough I did some tests in the past).
I have to reprogram that, but I am perfectly willing to.
So, the bottom line of drawbacks: Not well tested and the response for parameter changes might be too slow.
So, if you're still here... you might want to help.
You can help in adressing both points mentioned above. You can test if you like (I'll send you the dll's. I will open up the sourcecode as soon as
I've sorted out a nice solution for the second part) and tell me what you like or dislike. Also ideas on the second flaw can be discussed.
Ohhh, and there is one more problem for you as user. I mentioned that you can send commands to the CSurf and that you get feedback from the CSurf.
Setting up the communication channel is not trivial (certainly not if you are using TCP, which is the preferred method because I think it is faster).
The second 'problem' is the communication protocol. It is all SysEx. The command for
changing parameter 1 to value 2 to VST 3 on Track 4 is as follows:
F0 25 3 18 0 19 2 F7
The protocol was invented to have a minimum of databytes, but sacrifices simplicity.
Luckely there is documentation explaining this and maybe I should change it a bit.
Still there? A few more pros and cons:
Only works for Windows (but does not use much Windows specific stuff...)
Only supports 64 Tracks
The CSurf also has some transport functions (starting/Stopping, notifying Start/Stop) and can also read/write the Track Volume settings.
The Csurf can also open and close plugins and change screensets.
(The last two options are available in a lot of extentions, maybe I should remove them to get a cleaner commandinterface)
Het is een alternatief zoals er verschillende worden voorgesteld in deze thread: 
