I am stumbling on an issue which is nearly a deal breaker using Reaper. I have an Akai MPD32 remote controller device which have 3 banks of 8 endless knobs and want to use them for navigating or zooming purposes, mainly. Each of these knobs can be set to send NRPN messages. So, in example, taking the first knob (set as Channel 1, MSB : 000, LSB : 052), I get messages that are structured as following, according to Reaper Event list :
The problem is that, no matter the combination of settings used in the 'Keyboard/MIDI/OSC' dialog, trying to remote control the 'Transport/fast forward a little bit' or 'Transport/Rewind a little bit' action, I notice that Reaper only detects the following message :
MIDI Chan 1 CC98
From which, I am not able to set the involved knob as a bidirectional one in order to perform forward/rewind action, as Reaper always ask if I want to override the shortcut of one of the two actions that I want to be controlled by this knob. More clearly, it seems that we are unable to set a knob as a bidirectional endless one, using the CC96/CC97 values.
Can someone confirm and/or suggest a workaround for this ?
Yes, unfortunately NRPN (or any method that combines multiple messages) is not supported to control Reaper's action or plugin automation.
The only workaround so far is involving some pre-processing of the data before it arrives in Reaper, basically tripping off the NRPN messages and only use the Data Button messages - which you have to tweak as well, so that they are coming in to Reaper as the same CC number but with values conform to one of Reaper's "relative control" methods (eg value 1 for increase and value 127 for decrease).
But that's for a single rotary... to get multiple rotaries to work, your pre-processing would need to determine the CC number for inc/dec by the NRPN values...
There seem to be only very few control surfaces using the NRPN messages, (I can only recall your AKAI device and - I believe the Alesis ION), but nevertheless, Cockos should have mercy for the few and implement support.
I was still hoping that I was missing something more or less well hidden. Well... Anyway, expecting such a confirmation, I already made a feature request here : http://forum.cockos.com/project.php?issueid=5115, which is more or less the same as my first post here, hoping to get a feedback from Reaper bakers : let's see how things go.
About your link, I have already seen this thread and, as it involves Applescript and 'Midipipe' (guess this one is a Mac utility..), I didn't look more at it : I shall look at all this in a more 'in depth' way.
It's really frustrating to see that NRPN messages are so seldom supported by the hosts available, nowadays. I had the same problem with Cubase but found a workaround (see here : http://www.steinberg.net/forums/view...298954#p298954), far from satisfying, but at least, I can use 16 of my knobs as bidirectional endless ones.
This is really missing in Reaper, IMO : I was hoping that I could get rid of the Cubase clunky 'Generic remote' definitions. Sadly, it's not the case...
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
On Windows, you could try to create a similar workaround (i.e. converting relative NRPN to 'regular' relative MIDI CC#) using Pure data or perhaps GlovePIE.
Btw, I'd absolutely love to have something like those generic remote definitions from Cubase in REAPER. Clunky, well perhaps they are. But at the very least they *do* provide feedback to MIDI controllers. And REAPER still can't quite do that out of the box.
On Windows, you could try to create a similar workaround (i.e. converting relative NRPN to 'regular' relative MIDI CC#) using Pure data or perhaps GlovePIE.
Btw, I'd absolutely love to have something like those generic remote definitions from Cubase in REAPER. Clunky, well perhaps they are. But at the very least they *do* provide feedback to MIDI controllers. And REAPER still can't quite do that out of the box.
Hi, Banned
Could you give me more precisions about 'Pure data' and 'GlovePIE' ? Worth a check, I guess.
Beside this, the whole Cubase 'Generic Remote' definition concept is, indeed, very well thinked and useful at a first glance, BUT (provided that you already experienced them with Cubase) :
- Have you try to add or remove any track in your project ? The whole thing becomes a mess...
- Have you try to decipher the cryptic labelling of any VSTis parameter when there is one involved in a definition ? I just can't...
- Have you try to use the 'Ctrl-NRPN' option of the 'MIDI status' column to precisely use such incoming messages ? It's simply broken : Cubase just doesn't react when choosing it, from which, the workaround I had to find in the hard way...
Still looking for a host that allows a concise and efficient remote controlling of its own commands and VSTis/FX used, actually...
You can use this script in midi2osc. It is a generic MIDI->OSC conversion script, it handles NRPN. The nice thing is that it should work out of the box (well, you have to specify the MIDI device of course), and that it preserses the 14-bit resolution of your controller.
Note: in the meantime, midi2osc turn into OSCII-bot but I did not find the time to update the script yet.
You can use this script in midi2osc. It is a generic MIDI->OSC conversion script, it handles NRPN. The nice thing is that it should work out of the box (well, you have to specify the MIDI device of course), and that it preserses the 14-bit resolution of your controller.
Note: in the meantime, midi2osc turn into OSCII-bot but I did not find the time to update the script yet.
Hi, Jeffos
Thanks a lot for this. Will try to see how I can adapt it to my specific issue and let you know here if I get any problem using it, as I'm absolutely not familiar with Reaper OSC implementation.
Sorry, but your .cfg file with Midi2OSC doesn't work : attached is the result I get, trying to use it (Midi2OSCWindow.png). Also attached, is my midi2osc.cfg, renamed as a .txt file : I only tweaked the following lines...
- @input ones, leaving only two , corresponding to my 2 remote devices.
- @output one : I first tried to change the port number to 'EC00' which matches the port address displayed in the preferences 'MIDI devices' page for the MIDI output of my E-Mu 1616m that I use : it doesn't work. Values such as '8000' or '9000' aren't working either...
- nbinputs (set to 2, as I have two remote controlling devices).
So, several questions are remaining :
1) Where should Midi2OSC and its associated .cfg file be installed (path...) ?
2) How this utility is supposed to be launched : I guess manually, before launching Reaper, but who knows... ?
3) What are the EXACT formats of the parameters needed in the following lines, especially the devicenameforcode, IP and port numbers ?
4) How does Midi2OSC is supposed to guess the involved input ports addresses ?
5) At what is corresponding the '10 formats' message displayed in the Midi2OSC screenshot ?
That akai looks very cool!
As to the 6 byte midi messages......I feel ur pain! Me and banned have gone around this in 2012. In the end I chose midi translator pro to do what u want to do.
I converted a hui control surface....ALL 6 byte messages.....to a Reaper well supported 3 byte midi protocol...MCU.
I also have a very simple oscibot script that a friend helped me with that gets midi feedback from reaper..one parameter. Oscibot is in a "beta" form right now I think. Not well documented,but I hear its a lot like js. When my friend was helping me w this script, I had in/out issues w my script that were finally resolved,and it works great. I say this to say hang in there,maybe,u might be one line away from akai nirvana!
But I know for sure, that using midi translator pro, you would have that thing speaking in tounges in a weekend! And I would be glad to help. I get no commission from bomes..the maker of midi translator pro...I just been there done that.
The path where u install oscibot doesn't mater. I load it b4 reaper..don't know if it matters. U do need to setup a osc control surface in reaper.
IMHO...if u are more comfortable with midi than u are with ..say..python...u are much better off going w bomes midi translator pro. The ONLY downside is that its not free. 60 bucks if iremeber correctly. For me it was one of the best bang for the buck. I could go on w details, but I always sound like a fanboy or something.^^
Well, Translator pro, why not ? But, spending more than Reaper licence cost itself, to be able to remote control Reaper commands which need NRPN messages looks like an overkill, IMO.
So, I'm just hoping that Jeffos will be able to give us more precisions about how to set efficiently Midi2OSC for this purpose. This, while also hoping that Reaper bakers will finally find a way to implement natively NRPN message support for remote control in it.
@input will be your midi input. @output: is a "network" output for osc (localhost here).
for @input, you have to enter the device name (as reported by its driver, not an alias) in the cfg file, I mean this name:
so for ex:
Code:
@input in1 "MPD32"
^^ I don't know those VMK-188/MPD32 devices at all, just for the example!
Quote:
Originally Posted by cubic13
1) Where should Midi2OSC and its associated .cfg file be installed (path...) ?
2) How this utility is supposed to be launched : I guess manually, before launching Reaper, but who knows... ?
3) What are the EXACT formats of the parameters needed in the following lines, especially the devicenameforcode, IP and port numbers ?
4) How does Midi2OSC is supposed to guess the involved input ports addresses ?
5) At what is corresponding the '10 formats' message displayed in the Midi2OSC screenshot ?
Thanks in advance...
It'd be better to update this script for OSCII-bot but.. on top of my head:
1) where you want, the cfg file must called midi2osc.cfg and must reside in the same dir than midi2osc.exe (OSCII-bot is friendlier)
2) yes before
3) @input: see above, for @output: your current - @output localhost "127.0.0.1:9109" - looks ok, make sure you have enabled OSC with this port 9109 and ticked "allow binding messages etc" in REAPER > preferences > controle surfaces
4) device name as reported by the driver
5) 10 possible output messages with normalized floating point arguments (including NRPN for ex: "f/midi2osc/in/2/ch/16/nrpn/100")
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
I'm not sure, but it seems that conversion of NRPN to 'regular' CC# would suffice to solve cubic13's issue, correct?
I (still) haven't gotten around to checking out OSCII-bot, but it seems that that OSCII-bot can also do MIDI to MIDI? Does REAPER 'see' OSCII-bot as a MIDI device on Windows? In other words, conversion to OSC may not be needed here? (Perhaps confusing: "bidirectional" does not refer to feedback to the remote device in this context, but that one control knob sends different messages depending on which direction it is turned, i.e. clockwise/anti-clockwise.) Still, I guess Jeffos' previous script should be a nice starting point for having OSCII-bot solve the issue.
Thanks for your precisions and sorry for the late answer. I indeed was wrong with the naming of my ports : I managed to launch successfully Midi2OSC with the following input port names :
@input in1 "E-DSP MIDI Port [EC00]"
@input in2 "E-DSP MIDI Port 2 [EC00]"
So, I guess that i'm on the right track. But sadly, Reaper persists at only detecting 'MIDI Chan 1 CC98' when using my MPD32 endless knob. So, I guess that i'll have to carefully look at the .cfg script to find what is misbehaving. Will keep you informed about it, if I find something, but if you have any clue...
Thanks again !
@Banned
The problem is that, trying to use the knob to navigate with the 'fast forward a little bit'/'Rewind a little bit' and using for this a 'regular' CC message, such as CC85 (undefined, according to the MIDI specifications), it works only until I hit the 127 value of the knob. To make it works again, I have to rotate it at the opposite direction, which is not exactly what I want : I expect a bidirectionnal behavior of my endless knobs.
At this point, I'm wondering if I will not have to program an .eel script that will do the needed conversions on the fly, if possible...
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by cubic13
@Banned
The problem is that, trying to use the knob to navigate with the 'fast forward a little bit'/'Rewind a little bit' and using for this a 'regular' CC message, such as CC85 (undefined, according to the MIDI specifications), it works only until I hit the 127 value of the knob. To make it works again, I have to rotate it at the opposite direction, which is not exactly what I want : I expect a bidirectionnal behavior of my endless knobs.
At this point, I'm wondering if I will not have to program an .eel script that will do the needed conversions on the fly, if possible...
Wait, I think I don't quite get that: if you have an *endless* rotary knob, how come it would stop at 127 (or 0)? I would expect it to just keep sending Data Button Inc (96) events with value 1?
Btw, I just adapted Jeffos' script for use with OSCII-bot v0.2, you may want to check it out here. It won't solve your problem straight away; at least some further parsing/conversion of the NRPN data coming from your controller would be needed in any case. Jeffos' script simply parses all incoming MIDI data (including NRPN messages), converts it to OSC messages, and sends it out. If I would better understand what is needed, I may be able to help you create a workaround based on this script.
Wait, I think I don't quite get that: if you have an *endless* rotary knob, how come it would stop at 127 (or 0)? I would expect it to just keep sending Data Button Inc (96) events with value 1?
Btw, I just adapted Jeffos' script for use with OSCII-bot v0.2, you may want to check it out here. It won't solve your problem straight away; at least some further parsing/conversion of the NRPN data coming from your controller would be needed in any case. Jeffos' script simply parses all incoming MIDI data (including NRPN messages), converts it to OSC messages, and sends it out. If I would better understand what is needed, I may be able to help you create a workaround based on this script.
Hi, Banned
The problem is basically this one (see the first post of this thread for more detail) : among the 5 messages sent each time I turn an endless knob set as an NRPN one by my MPD32, reaper only detects the CC98 one in the 'Keyboard/MIDI/OSC' input which allows you to set a remote command for any Reaper action. From which, I can't use any CC96 or 97 part of the message to control a Reaper action.
And, trying to set my knob as 'regular' CC one (I took the CC85 example), I stumbled quickly on the 0-127 boundaries limitation. My previous post was about this precise configuration.
Again, what I'm looking for is to be able to use, say (let's not be difficult at this point...) 8 of my 24 endless knobs (one of the three banks I have at disposal) to work as endless bidirectional ones for zooming, navigating, nudging, etc. Cubase also doesn't manage well this but, at least, I made 16 of them (the two first banks) work with a workaround, using different MIDI channels. Being able to set two different commands (using two lines in the Generic Remote Definition) for the same knob/controller actually allows the bidirectional action, this with the CC96/CC97 detection that Reaper seems unable of.
To be more clear :
Knob 1 ---> Ch 1 ---> CC96 (clockwise action) -----------------> zoom in
Knob 1 ---> Ch 1 ---> CC97 (counter-clockwise action) ---------> zoom out
Knob 2 ---> Ch 2 ---> CC96 (clockwise action) -----------------> nudge +1 frame
Knob 2 ---> Ch 2 ---> CC97 (counter-clockwise action) ---------> nudge -1 frame
.
.
.
Knob 16 ---> Ch 16 ---> CC96 (clockwise action) ---------------> (other action which requires more than the 128 steps limitation of a 'regular' CC message)
Knob 16 ---> Ch 16 ---> CC97 (counter-clockwise action) -------> (other action which requires more than the 128 steps limitation of a 'regular' CC message)
Hope it helps and thanks for the adaptation already done !
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Yeah, I think I understand your problem: when REAPER gets a bunch of CC#s, it only sees one in its 'learn' dialog. What I don't really get yet, is what would exactly be needed for a workaround.
I would think we can intercept those NRPN messages, then convert them to different, regular, but relative CC messages, and send those to REAPER (via a virtual MIDI cable, I guess), so you could 'learn' them to those specific bindings in REAPER without problems.
If I would know exactly how the data should look to work, I may be able to achieve that. I'm just not sure what exactly would work with those specific actions. Need some testing...
Yeah, I think I understand your problem: when REAPER gets a bunch of CC#s, it only sees one in its 'learn' dialog.
Exactly ! And the problem here is that Reaper only detects the CC98 part of the NRPN messages sent by the MPD32 (these, again, being fully compliant to the official MIDI specifications and I can't change the MPD32 behavior ; I can only change on it the MIDI channel, CC99 and CC98 values of the bunch of NRPN messages sent). So, I guess that something has to be done to use this one combined with different MIDI channels.
Quote:
Originally Posted by Banned
What I don't really get yet, is what would exactly be needed for a workaround.
I would think we can intercept those NRPN messages, then convert them to different, regular, but relative CC messages, and send those to REAPER (via a virtual MIDI cable, I guess), so you could 'learn' them to those specific bindings in REAPER without problems.
If I would know exactly how the data should look to work, I may be able to achieve that. I'm just not sure what exactly would work with those specific actions. Need some testing...
There would be two solutions that don't seem to be doable with Reaper :
1) The ideal one (the one that would allow NRPN messages to be used at their full potential) : a detection of any CC99-CC98-CC96/CC97 combination to be able to set things like this, in example :
2) The way I use Cubase with the workaround I found, using different MIDI channels (in Cubase, the 'native' NRPN detection function is broken : it simply doesn't react using it) :
Knob1 ----- Ch1 ----- CC96 (clockwise action) ---------------> scrub to the right
Knob1 ----- Ch1 ----- CC97 (counter-clockwise action) -------> scrub to the left
Knob2 ----- Ch2 ----- CC96 (clockwise action) ---------------> nudge +1
Knob2 ----- Ch2 ----- CC97 (counter-clockwise action) -------> nudge -1
.
.
.
This one would, at least, allow me to use 16 (as much as MIDI channels available) of the 24 knobs I have at disposal as endless bidirectional ones.
Sadly, Reaper doesn't detect any CC96/97 message used as NRPN, which means as a parameter Incr/Decr command. The problem is to make a conversion to get Reaper to act as if it could, this, with the ability to use the same knob for two similar actions (scrub right/left, nudge +1/-1, etc.). The more I look at it, the less I see a solution, but I do not master the ReaScript language, yet. So, maybe a little hope is left...
Problem is that, no matter the CC used as 'regular' one, I always stumble on the following issue : at a point the knob stop to act when reaching one of the 0 or 127 boundaries. I have to turn the knob at the opposite way to make it act again.
So, among the two solutions that you suggested, I think that the second one would be better : I just tested different combinations of CC85 in absolute/Relative 1,2 or 3 modes to control the Transport: Scrub/jog (MIDI CC relative/absolute only) command. Using any 'Relative' option, it's even worse : at a point (at the 64 value of the CC parameter), the cursor suddenly moves in the opposite way.
Thanks for looking at this, but I'm not so sure that, even with Reascript or a Midi2OSC kind of workaround, I'll be able to use my MPD32 with Reaper. Which means returning to Cubase 6.5 for any efficient remote control, using my gear...
Exactly ! And the problem here is that Reaper only detects the CC98 part of the NRPN messages sent by the MPD32 (these, again, being fully compliant to the official MIDI specifications and I can't change the MPD32 behavior ; I can only change on it the MIDI channel, CC99 and CC98 values of the bunch of NRPN messages sent). So, I guess that something has to be done to use this one combined with different MIDI channels.
There would be two solutions that don't seem to be doable with Reaper :
1) The ideal one (the one that would allow NRPN messages to be used at their full potential) : a detection of any CC99-CC98-CC96/CC97 combination to be able to set things like this, in example :
Not within Reaper, but doable with pre processing.
The idea I had in mind is using some pre processing (outside of Reaper) to convert CC96/CC97 to other CC message pairs depending on the NRPN messages that preceeded them.
EG assuming your knob 1 sends:
1_________CC_________Non-Reg Parm MSB (99)_________0
1_________CC_________Non-Reg Parm LSB (98)_________52
1_________CC_________Data Button Inc (96)___________1 (clockwise) / CC97,1 (counter clockwise)
1_________CC_________Non-Reg Parm MSB (99)_______127
1_________CC_________Non-Reg Parm LSB (98)_______127
your pre-processing needs to look at NRPN LSB (CC98) and decide what to convert the data inc/dec CC into.
Controlling different actions for left/right turn:
- If the last CC98 has been value 52, then convert CC96=>CC1 and CC 97=>CC2. Assign "scrub right" to CC1 and "scrub left" to CC2.
- If the last CC 98 has been value 53, then convert CC96=>CC3 and CC97=>CC4. Assign "nudge+1" to CC3 and "nudge-1" to CC4.
(CC1 trough CC4 are only examples. Of course you could use any CC pair or the same CC number on different channels if you prefer that)
The pre-processing would then strip all CC99/CC98 and only output the converted data inc/dec messages (CC1 through CC4 in the example) to Reaper.
Controlling actions designed for "CC relative/mousewheel) need a different conversion of CC 96/97:
They both need to be converted to the same CC number ( as above depending on the last received CC98), but different values, according to which relative mode (relative 1,2 or3) you decide to emulate.
EG if you use mode 3 then values 1 through 64 are counter clockwise and values 65 through 127 are clockwise. The bigger the value, the bigger the step size (if that is supported by the action you control).
you'd convert
for knob 1 (last cc98 was value 52)
CC96 => CC1 value 1 (clockwise)
CC97 => CC1, value 65 (counter clockwise)
and
for knob 2 (last cc98 was value 53)
CC96 => CC2, value 1 (clockwise)
CC97 => CC2, value 65 (counter clockwise)
and again strip all but the converted data inc/dec messages.
(like above, CC1 and CC2 are arbitrarily chosen, use any CC/channel you like)
That's finest step size. I often find myself using values 7 and 71 for my emulated relative control, but you'd need to experiment to find out which step size you like for the action or plugin parameter you control.
These methods would allow you to assign 64x16 pairs of actions or 128x16 relative control actions.
As of your 0 or 127 boundary problem and the value 64 problem in relative control, I believe there is some confusion between relative and absolute going on there. I do a similar method to the one I described above controlling action pairs and relative/mousewheel actions and it works. I use Logic's environment and MIDI Yoke cables, but it shouldn't matter at all which program does the processing.
Alas, I don't think ReaScript can help. There is no way I can see to grab MIDI data in realtime and no way to pump MIDI data into Reaper's inputs.
JS programming, could possibly be a ticket. I never tried, but maybe Jeffos' MIDI_to_ReaControlPath can direct messages to the action list's MIDI learn. If yes you could do all the processing inside a JS plugin followed by MIDI_to_ReaControlPath on a Reaper track. I never tested that, as I enjoy doing Logic environments too much and it works great for me .
Last edited by gofer; 03-27-2014 at 12:43 PM.
Reason: mixed up reft and light
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Yes, that's what I was thinking as well: this should be doable with some pre-processing of the MIDI data coming from the MPD32 device.
I was thinking of using OSCII-bot for this, starting with Jeffos' neat MIDI2OSC script (as that already covers the tricky part: parsing incoming NRPN messages). From there, we could have OSCII-bot send 'new and improved' MIDI messages to REAPER via a virtual MIDI port (e.g. MIDI Yoke). Or, have it send OSC messages via REAPER's OSC Control Surface function (eliminating the virtual MIDI port may slightly improve latency, I guess). Either way, this is more or less what Jeffos suggested above.
Of course, as 4x4uk noted, there are other ways of doing much the same, such as MidiOx. I can't help with setting up that, though, as it's a Windows-only app and I'm on OS X, but afaik it would indeed be another option. And indeed, I think MIDI_to_ReaControlPath does just what gofer suggests, so using JS could be yet another effective approach.
Don't lose hope yet, cubic13. Stick around and I'm sure we'll get your gear working, somehow.
Well, I'm not exactly prone to install again MidiOX : I already tried to use it, and it was exactly for the same purpose, but with Cubase, this time, before finding the workaround that uses different MIDI channels. I never got it to work on my system, despite the kind help of soul-burn, a Steinberg forumer who seems to really know what he is talking about, concerning MIDI pitfalls.
So, I guess that I'll have to look more in depth at a Midi2OSC/OSCII-bot kind of solution with its rather cryptic language (still don't get if it's pure eel, JS, a mix of both...). Indeed, gofer, the way you see this makes sense, using the CC98 value. But to set this as a script (JS ? eel ? I'm getting lost...) remains to be done. I admit that I'm a little discouraged, as writing this...
I'd like to see the OSCII-bot solution, although I am not sure the MPD benefits from parameter feedback. But it sounds interesting. I haven't done any OSC stuff at all so far.
I tested MIDI_to_ReaControlPath and yes, messages from that track are available in the action list learn dialog too (I only ever used it for plugin automation learn so far) . If we find someone to code a JS to do the MIDI processing this approach would certainly work.
Downside: The track with that plugin and MIDI_to_ReaControlPath would need to be record armed and monitor enabled constantly.
Definitely hang in there.
MIDI OX I always found complicated to use... and I am not sure it can pull off the conditional mapping we need. But the process as such is very easy. I could do it in a few minutes with three or four transformer objects in Logic. I am sure if we ask nicely in the JS forum we find a gentle person to write the JS plugin for you .
Btw, I noticed that I got left and right turn mixed up in my description of how to use Reapers relative 3 mode. I do that all the time . I'll edit the post...
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by gofer
I'd like to see the OSCII-bot solution, although I am not sure the MPD benefits from parameter feedback. But it sounds interesting.
No, I don't see the need for feedback (nor OSC) either. In this case, OSCII-bot would just sit there in the background and convert troublesome MIDI to more useable MIDI:
[MPD32]=(MIDI)=>[OSCII-bot]=(MIDI)=>(virtual MIDI cable, e.g. MidiYoke)=(MIDI)=>[REAPER]
So this would be much the same as MidiOx or something similar could do. The main downside here, I guess, is having to use a virtual MIDI cable. Perhaps using OSC would be marginally better in terms of overhead / latency, but I'm not sure at all. Either way, this would require only a very modest amount of system resources, but would result always in a slight increase in latency, when compared to directly sending MIDI from a device to REAPER. Still, the important part here is getting things to work in the first place. We can compare performance details of alternative solutions later, when we have them.
Quote:
Originally Posted by gofer
I tested MIDI_to_ReaControlPath and yes, messages from that track are available in the action list learn dialog too (I only ever used it for plugin automation learn so far) . If we find someone to code a JS to do the MIDI processing this approach would certainly work. [...]
See, that would work too.
Not having to (re)do all the heavy lifting involved with NRPN parsing is why Jeffos' script seems like a great start (do we already have something similar for JS? I forgot...). I'm currently hacking a little workaround to provide feedback using OSC<=>MIDI conversion for another REAPER user with hardware that also uses NRPNs, and the NRPN parsing works like a charm so far. (So, once again, many thanks to Jeffos for sharing this; it's really very useful as a generic framework to build more specific things on top of.)
Quote:
Originally Posted by cubic13
I'm getting lost...) remains to be done. I admit that I'm a little discouraged, as writing this...
Relax, go make a bit of music while I'll have a try at getting you started. I'm going to have another coffee, try to emulate the behavior of your device, and then see if I can do something along the lines of what's suggested above.
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Ok, I think I have the basics of a workaround in the form of a script for OSCII-bot: MPD32-NRPN2CC.txt.
For a test, it now converts these values:
Knob 1 (NRPN 52) turned clockwise =======> CC#1, value 1
Knob 1 (NRPN 52) turned counter-clockwise ==> CC#2, value 1
Knob 2 (NRPN 53) turned clockwise =======> CC#3, value 1
Knob 2 (NRPN 53) turned counter-clockwise ==> CC#4, value 1
I tested it by learning CC#1 to the 'Transport: Fast forward a little bit' action, and CC#2 to 'Transport: Rewind a little bit' action. This all seems to work as desired (although I'm finding the steps a bit large, but I guess that's simply how things are in any case...).
To test this script for yourself, unzip and put it in the folder for OSCII-bot scripts, then run OSCII-bot. It probably takes a bit of tweaking to configure your MIDI input/output properly. To do so, have a look at these lines:
Code:
@input in1 "MPD32"
and
Code:
@output out1 MIDI "Out To MIDI Yoke: 1"
Edit the name (i.e. the "MPD32" part) if this doesn't work. You can check the names of the MIDI ports in REAPER as well. I'm assuming you'll be using MIDIYoke for a virtual MIDI port on Windows, but anything similar should work, too.
If this works as desired, and you want to extend this script (to support more knobs), look at these lines in the code:
Code:
// NB: here, the "fmt2" variable holds the (N)RPN parameter number;
// the "msg2" variable holds the CC# number.
fmt2==52 && msg2==96 ? ( // Knob that sends NRPN 52 is turned clockwise
msg2 = 1; // Use CC#1 instead
midisend(midi_out_port); // Send value as CC#1 event
);
fmt2==52 && msg2==97 ? ( // Knob that sends NRPN 52 is turned counter-clockwise
msg2 = 2; // Use CC#2 instead
midisend(midi_out_port); // Send value as CC#2 event
);
fmt2==53 && msg2==96 ? ( // Knob that sends NRPN 53 is turned clockwise
msg2 = 3; // Use CC#3 instead
midisend(midi_out_port); // Send value as CC#3 event
);
fmt2==53 && msg2==97 ? ( // Knob that sends NRPN 53 is turned counter-clockwise
msg2 = 4; // Use CC#4 instead
midisend(midi_out_port); // Send value as CC#4 event
);
// Etc. ...
Just try to follow the pattern, it shouldn't be too hard (but of course feel free to ask for help if you would get stuck). You can also change the CC# numbers (1, 2, 3, 4 etc.) to something else.
Speechless to see how some here, especially you, are willing to help... I just compare to Steinberg forums where I wouldn't have even expect such implication (excepting from soul-burn and very few others, maybe ; if he reads me...).
Don't have the time to try all your suggestions and work this evening but will do so tomorrow and keep you informed here about how things are going.
First, few precisions that could help, concerning my setup. My MIDI/Audio device has two MIDI input ports and two output ones, listed as following in Reaper ('Preferences/Audio/MIDI device') :
Input :
E-DSP MIDI Port [EC00] ------> Mode : 'Enabled+Control'
E-DSP MIDI Port 2 [EC00] ------> Mode : 'Enabled+Control'
Output :
E-DSP MIDI Port [EC00] ------> Mode : 'Enabled'
E-DSP MIDI Port 2 [EC00] ------> Mode : <disabled>
The first MIDI input port receives the MIDI messages sent by my VMK-188+ keyboard controller. The second one receives the messages from the MPD32 (which is the device I want to control Reaper actions with). There is only one MIDI output port active, as I send all the MIDI messages involving my external instruments to, first, my ME-30P MIDI patch bay.
From which, here is what I did...
1) I first edited the MPD32-NRPN2CC.txt file by changing two lines, as following :
@input in1 MIDI "E-DSP MIDI Port 2 [EC00]"
// --> @input in1 "MPD32" // Edit the name (i.e. the part between the "quote marks") if this doesn't work
.
.
.
@output out1 MIDI "E-DSP MIDI Port 2 [EC00]"
// --> @output out1 MIDI "Out To MIDI Yoke: 1"
and saved it as MPD32_Test.txt then transferred it to a C:\Users\Lambda\AppData\Roaming\OSCII-bot folder. It's the only script in here.
2) I launched OSCII-bot and got the window viewable in the OSCII-bot_window.png attachment. Seems that OSCII-bot receives properly incoming messages from the MPD32, as the strings displayed on the bottom left, near the 'Quit' button change each time I use a different controller. As an example, I get :
Using my first knob : b0:62:7f b0:63:7f bo:60:01 b0:62:34
Using my first fader : b6:2c:68 b6:2c:69 b6:2c:6b b6:2c:6c
So, I guess that, at least, the @input statement of the script is right.
3) I launched Reaper and, just in case, as OSC is not involved, if I understood well, I set an OSCII-bot control surface as displayed in the ControlSurface.png attachment. Could you confirm that it's useless, when using OSCII-bot as a MIDI only transformer ?
The problem is that Reaper acts exactly as previously, as if OSCII-bot was simply not working : it continues to see CC98, each time I turn the MPD32 first knob in the 'Keyboard/MIDI/OSC input' window. Obviously, there is a problem with the @output statement of the script and I fear that it has something to do with the absence of any 'virtual' MIDI port.
So, I think that, sadly, it's the end of the road, as I never got MidiOX to behave as expected, here...
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by cubic13
Bad news...
So, first, few precisions that could help about my setup.
- My MIDI/Audio device has two MIDI input ports and two output ones, listed as following in Reaper ('Preferences/Audio/MIDI device') :
input :
E-DSP MIDI Port [EC00] ------> Mode : 'Enabled+Control'
E-DSP MIDI Port 2 [EC00] ------> Mode : 'Enabled+Control'
Output :
E-DSP MIDI Port [EC00] ------> Mode : 'Enabled'
E-DSP MIDI Port 2 [EC00] ------> Mode : <disabled>
The first MIDI input port receives the MIDI messages sent by my VMK-188+ keyboard controller. The second one receives the messages from the MPD32 (which is the device I want to control Reaper actions with). There is only one MIDI output port active, as I send all the MIDI messages involving my external instruments to, first, my ME-30P MIDI patch bay.
Don't despair. I think you just got confused with the routing there, while you already seem to understand what the problem is. It seems that you have set up OSCII-bot to send the converted MIDI data back to the device, like this:
[MPD32] <==> [OSCII-bot]
... instead of to REAPER, via a virtual MIDI cable, like this:
Do you have a virtual MIDI cable (such as MIDIYoke) installed already? This seems to be the missing part in your setup.
Also, you should *disable* the MIDI input from the MPD32 device to REAPER. Otherwise, of course you would still be receiving the problematic data we wanted to get rid of in the first place.
Quote:
Originally Posted by cubic13
From which, here is what I did...
1) I first edited the MPD32-NRPN2CC.txt by changing two lines, as following :
@input in1 MIDI "E-DSP MIDI Port 2 [EC00]"
// --> @input in1 "MPD32" // Edit the name (i.e. the part between the "quote marks") if this doesn't work
.
.
.
@output out1 MIDI "E-DSP MIDI Port 2 [EC00]"
// --> @output out1 MIDI "Out To MIDI Yoke: 1"
and renamed it MPD32_Test.txt then transferred it to C:\Users\Lambda\AppData\Roaming\OSCII-bot. It's the only script in here.
So, the @input line seems correct, but the @output line is wrong. That should be something like
Code:
@output out1 MIDI "Out To MIDI Yoke: 1"
(I.e., the line that was already there, but commented out.)
Quote:
Originally Posted by cubic13
2) I launched OSCII-bot and got the window viewable in the OSCII-bot_window.png attachment. Seems that OSCII-bot receives properly incoming messages from the MPD32, as the strings displayed on the bottom left, near the 'Quit' button change each time I use a different controller. As an example, I get :
Using my first knob : b0:62:7f b0:63:7f bo:60:01 b0:62:34
Using my first fader : b6:2c:68 b6:2c:69 b6:2c:6b b6:2c:6c
So, I guess that, at least, the @input statement of the script is right.
Correct. Those messages are the raw MIDI bytes coming in.
Quote:
Originally Posted by cubic13
3) I launched Reaper and, just in case, as OSC is not involved, if I understood well, I set an OSCII-bot control surface as displayed in the ControlSurface.png attachment. Could you confirm that it's useless, when using OSCII-bot as a MIDI only transformer ?
Yes, that would be completely useless. Indeed, we're only dealing with MIDI here.
Quote:
Originally Posted by cubic13
The problem is that Reaper acts exactly as previously, as OSCII-bot was simply not working : it continues to see CC98, each time I turn the MPD32 first knob in the 'Keyboard/MIDI/OSC input' window.
As noted, that is because you still have REAPER listening to the MIDI coming from the MPD32 device - which is why you should *disable* it in the MIDI inputs section in REAPER's Preferences.
You should have REAPER listen to the virtual MIDI cable that is configured as @output in the OSCII-bot script, so you should see something like "In From MIDI Yoke: 1", and it should be *enabled* for control messages.
Quote:
Originally Posted by cubic13
Obviously, there is a problem with the @output statement of the script and I fear that it has something to do with the absence of any 'virtual' MIDI port.
Exactly. So, install a virtual MIDI port and configure it!
Quote:
Originally Posted by cubic13
So, I think that, sadly, it's the end of the road, as I never got MidiOX to behave as expected, here...
I think you have missed the same crucial step in that case as well, then: installing a virtual MIDI port and configuring it. The road goes on, just take the next step!
OK... So, the absence of a 'virtual' MIDI port is the culprit : I was more or less, at the same time when doing this, fearing and expecting it. The problem is that MidiOX never worked on my system. So, under a Windows based system, how to set a virtual MIDI port without MidiOX ? Guess that I'll heve to make researches about this, but if you have any suggestion...
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by cubic13
Hi again, Banned
OK... So, the absence of a 'virtual' MIDI port is the culprit : I was more or less, at the same time when doing this, fearing and expecting it. The problem is that MidiOX never worked on my system. So, under a Windows based system, how to set a virtual MIDI port without MidiOX ? Guess that I'll heve to make researches about this, but if you have any suggestion...
Yes. Seems perfect for this job. MIDI Yoke is another popular one. Pick either one, shouldn't matter much for our purposes. Whatever works for you. Just forget about MidiOx for a moment, install it, and try to configure it with REAPER and OSCII-bot.
I installed LoopBe1 and, without any complicated added process, the port was immediatly detected in Reaper preferences (see reaper_LoopBe.png attachment).
From this, I edited again my MPD32_Test.txt script, changing this line :
@output out1 MIDI "E-DSP MIDI Port 2 [EC00]"
to this one :
@output out1 MIDI "LoopBe Internal MIDI"
Miracles happen, sometimes : the Banned script worked right away, as now, in the 'keyboard/MIDI/OSC' window :
- rotating my MPD32 first knob clockwise, 'MIDI Chan 1 CC 1' is detected,
- rotating my MPD32 first knob counter-clockwise, 'MIDI Chan 1 CC 2' is also detected.
Same thing for the second knob involved in Banned's script. So, there is a lot of work left : adjusting Reaper reaction to the incoming messages (think that the SWS extensions might be of great help, here...), setting all my knobs as wanted, etc. But the essential is here : it seems that, from now, I'll be able to control Reaper with NRPN messages, thanks to your work, Banned, and the LoopBe1 thingy.
Just a correction, though, Banned : I had to keep the 'native' second port (E-DSP MIDI Port 2 [EC00]) active, otherwise I would only receive the messages of the two knobs involved in the script. Not a big deal, as the whole thing seems to work.
Now, i'm for a big job of scripting everything as wanted...
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by cubic13
Well, things are getting much better, here...
Awesome.
Quote:
Originally Posted by cubic13
[...] Just a correction, though, Banned : I had to keep the 'native' second port (E-DSP MIDI Port 2 [EC00]) active, otherwise I would only receive the messages of the two knobs involved in the script. Not a big deal, as the whole thing seems to work.
Well, we can make the script pass through MIDI as well, for any controls that send MIDI data that is not problematic to use with REAPER. This was just a 'first things first' example to get you started.
Quote:
Originally Posted by cubic13
Now, i'm for a big job of scripting everything as wanted...
Thanks a lot again !
You're welcome, and success with finishing the script.
I really think Banned's advice should be in a sticky or something because it took me FOREVER to find this information and no one replied to my own thread about increment/decrement NRPNs and endless encoders.
Edit: Or more information about NRPN use could be in the manual.
Hiya,
at the risk of hijacking this thread, i've been trying to develop the nrpn script to work in another context - specifically converting nrpn data sent from the faders on a bcf2000 into OSC data.
I have found this thread, and the work of Banned and Jeffos invaluable in my quest for success!
If possible, before I lose my hair on silly errors, could anyone confirm that the areas i need to work on are in the images i have uploaded?
Image one is the nrpn data sent from the bcf - fader one hits nrpn 100 with max range ( 0 - 16383), fader 2 sends nrpn 200 etc etc
Image 2 is the area in Banned's wonderful OSCiibot script which I am expecting to edit.
I am very much looking forward to getting HiRes data from my trusty (and cheap!) bcf2000 :-)
Last edited by DanP2011; 08-12-2014 at 03:03 AM.
Reason: typo...
Late answer, DanP2011, as I just saw your post, but still...
What I'm wondering is what kind of parameter do you want to control with your BCF2000 ? I'm asking this, as NRPN mesages are supposed to have the following structure :
CC99 (NRPN MSB)
CC98 (NRPN LSB)
CC96/CC97 (increment/decrement value, always equal to 1)
CC98 equal to 127
CC99 equal to 127
The main purpose of NRPN messages is to allow the use of endless controllers and, obviously, faders are not designed for this. For true NRPN control of Reaper actions, I would rather try to use endless/infinite knobs (seems that there are eight of them on your device). What is displayed in your first screenshot seems more appropriate to control a high resolution synth parameter such as 'Pitch bend'.
Thanks for the reply, cubic123.
Maybe I'm on the wrong track here... I think I am misunderstanding NRPN. My understanding was that they used 4 cc's in order to transmit 14bit midi messages.
I simply want to get higher resolution control from faders - so i was hoping to send 14bit NRPN's from the bcf2000, and convert them into OSC to control the volume for tracks in reaper - or any other osc-capable software.
I absoutely understand that if NRPN messages are used to send +/- or incremental, then the format is not fit for my purpose :-(
So, without wanting to further compound my ignorance, I guess I need to find out if NRPN's can send non-increment/decrement data.
Ah no, you're right, DanP2011!
What cubic13 described is correct too, but it is a specific case. (N)RPN are indeed primality used for higher resolution, typically for faders!
Quote:
Originally Posted by cubic13
NRPN mesages are supposed to have the following structure :
CC99 (NRPN MSB)
CC98 (NRPN LSB)
CC96/CC97 (increment/decrement value, always equal to 1)
CC98 equal to 127
CC99 equal to 127
yes, (N)RPNs can have this structure, but the main use-case is rather:
CC99 (NRPN MSB)
CC98 (NRPN LSB)
CC6/CC38 (MSB/LSB of an absolute value, with 14 bit resolution -- CC38 is optional) no reset
Quote:
Originally Posted by cubic13
The main purpose of NRPN messages is to allow the use of endless controllers and, obviously, faders are not designed for this.
As I said above: no, on the contrary! This is mainly intended for absolute/bounded controllers, with 14-bit resolution.
What you describe is just how *AKAI* seem to implement relative modes for most of its controllers (which seems a bit strange since 3*8 knobs could fit in single CC events, using relative modes supported by most of DAWs... that being said, it is also OK to do whatever you want with NRPNs...)
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by DanP2011
[...]I simply want to get higher resolution control from faders - so i was hoping to send 14bit NRPN's from the bcf2000, and convert them into OSC to control the volume for tracks in reaper - or any other osc-capable software. [...]
If high resolution is your main goal, I would avoid NRPNs and use 14 bit CC# pairs (or maybe pitch bend), as it's less complicated (which is especially good for wrapping your head around scripting stuff) and more efficient with MIDI bandwidth. Afaik the BCF-2000 faders can easily be configured to use 14 bit (absolute) CC#s, although their actual resolution is lower, I believe it is 10 bits (1024 steps, much better than only 128 already).
Thanks for the reply, cubic123.
Maybe I'm on the wrong track here... I think I am misunderstanding NRPN. My understanding was that they used 4 cc's in order to transmit 14bit midi messages.
I simply want to get higher resolution control from faders - so i was hoping to send 14bit NRPN's from the bcf2000, and convert them into OSC to control the volume for tracks in reaper - or any other osc-capable software.
I absoutely understand that if NRPN messages are used to send +/- or incremental, then the format is not fit for my purpose :-(
So, without wanting to further compound my ignorance, I guess I need to find out if NRPN's can send non-increment/decrement data.
Thanks again for the input cubic123
I must apologize, here : Jeffos is indeed right. I've been too self centered on my own case, I guess.
Indeed, NRPN messages are also used with faders the way Jeffos described it. From which, I guess that adapting the scripts of Jeffos/Banned to your specific case should not be too complicated. I already did the adpatation for my case, without too much hassle. Could post it here, but it won't be of a lot of help, I guess, as it's only aimed at the use of 20 of the 24 knobs I have here as endless ones. After this, whether using faders as NRPN messages transmitters or as CC pairs ones, as Banned stated, is another debate : I never used NRPN messages with faders, so I can't help more, in this case.
Sorry, again...
@Jeffos
The way Akai implemented NRPN is corresponding to the use of the implemented knobs as endless ones and it's the only way such messages are used on my device, as there is no possible use of NRPN messages available for the faders. This is probably why I talked too soon... Beside this, the knobs available can be also be set as 'classic' CC messages transmitters, if needed.
This might be a little late but I had a similar problem and wrote a script.
I wanted my AKAI MPD26 endless knobs to work with REAPER and therefore had to deal with NRPN messages conversion to relative CCs.
I also tried with ReaLearn but did not succeed.
Instead I used this thread's way (thank you!): a virtual MIDI interface (loopMidi) and OSCII-bot v0.6.
The basic idea is:
Use loopMidi as MIDI-IN in REAPER.
Use OSCII-bot to read NRPMs from the AKAI controller and transform them to relative CC messages that are supported by REAPER. Let OSCII-bot send these events to loop-MIDI. In addition forward any other MIDI message to loop-MIDI (to be consumed by REAPER).
In the MPD26 MSB and LSB have to be defined for each knob's NRPMs. My idea was to use this information for parameterizing:
MSB defines the target CC (e.g. 012).
LSB defines the relative step size (0 smallest, 127 largest).
The attached OSCII-bot script expects assigned parameters using REAPER's relative mode 1.
Good LSB is 38 for me. As an alternative one could use one of the faders to change the step size globally (store it in a variable). But maybe I will just fallback to a constant values in the script.
In addition I used a second script (modified sample) to monitor transformation:
@input omni_midi_out OMNI-MIDI-OUTPUT
@input omni_midi OMNI-MIDI
@midimsg
printf("%s %s\n", msgdev==omni_midi ? "MIDI-IN" : "MIDI-OUT", sprintf(#,"%02x %02x %02x /// %03i %03i %03i",msg1,msg2,msg3, msg1, msg2, msg3));
NRPN messages to control Reaper actions...
. If we find someone to code a JS to do the MIDI processing this approach would certainly work.
Linear Mode
