Midi Controllers - ReaScript or Plugin? Where to Get Started?

[Kyran]

Hello, I'm looking to have a very deeply integrated midi controller scheme. I've been toying with implementing this in Ableton or Bitwig, but Bitwig isn't mature yet and I find Ableton abrasive to work with and also lacking in API functions. The obvious choice is Reaper given that it's probably the most customizable DAW in existence.

What I want is to capture all midi input from several different controllers and act on them depending on the program context and what mode the controller is in. For instance in midi mode, a knob might change the velocity of selected notes, whereas in performance mode, it would pass that data through to the program for midi mapping. I'd need a main class which would handle input from the controllers and use it to switch contexts, pass data to the context classes to perform actions, or pass the data on to Reaper. It would also need to handle LED and LCD output, and register listeners for various state changes in Reaper.

What would be the best way to implement this? Could it be done all in scripts or would it be better to code a plugin and then possibly call some custom scripts from there? Is there any documentation or examples relating to midi control scripting?

[Xenakios]

For something this complicated, you will need to do a C++ extension plugin. You could yourself then embed Eel or Lua or similar scripting language to be used from the plugin. (The Reaper API wouldn't really help you with this.)

Reaper's scripting currently doesn't actually support even simple MIDI controller scenarios. (Beyond writing scripts that can be triggered with a MIDI message but you can't get any information about the messages, it's strictly triggering like you would do with a keyboard shortcut.) This seems to me a glaring omission in the Reaper scripting capabilities. A half-effective solution called Osciibot exists, which is a separate application from Cockos, but I guess it won't be enough for your needs. But it does allow writing Eel scripts to manipulate MIDI and OSC messages. http://www.cockos.com/oscii-bot/

Even with a C++ plugin you may encounter some limitations on what is possible (easily and cleanly).

[Geoff Waddington]

I agree with Xenakios, C++ is the ticket on this one.

As far as Reaper function coverage / limitations, etc. the best source I have found ships with each version, reaper_plugin_functions.h.

Just in case you don't know this one, go Actions Menu, then at the very bottom of the list, Write C++ API functions header.

And don't forget to use this cool method of importing Reaper API functions, courtesy of our good friend, Xenakios : http://forum.cockos.com/showthread.php?t=151862

[Banned]

While I'd agree that C++ is probably the best choice, I would also point out that CPU performance is often not a very important issue in this context, given the relatively slow speed of MIDI controller data. I have also built this sort of stuff in platforms like Pure data / Max/MSP where you only design stuff at the top-level, and most 'boilerplate' stuff is already implemented in various modules (while you can also create/modify such 'externals') using C++. The upside of such an approach is that it allows you to focus on interaction design rather than implementation, which I also found useful for prototyping stuff before deciding whether to implement something in C++ for better performance, portability, etc. Another benefit is that is much easier to modify on the fly for non-coders, which may be useful if you build stuff for others rather than yourself only.

[Xenakios]

Originally Posted by Banned

While I'd agree that C++ is probably the best choice, I would also point out that CPU performance is often not a very important issue in this context, given the relatively slow speed of MIDI controller data.

The problem is that he is asking about Reaper integration. C++ would not be needed for the speed but for the integration into Reaper. ReaScript/Jesusonic just don't offer the needed functionality to achieve that. IMHO they should, but at the moment they don't. C++ certainly should not be needed to implement MIDI control surface functionality into Reaper.

[Kyran]

I'm more familiar with C++ than python anyway so that's not the end of the world. That hinders my ability to reuse code for Ableton scripting if I end up doing that as well, but again, not a big issue.

Will I be able to register listeners in Reaper? For instance tracks being muted, added, volume changes, plugin windows being opened, etc?

Good tip on the API export, I'll give that a try when I get home.

[Xenakios]

Originally Posted by Kyran

Will I be able to register listeners in Reaper? For instance tracks being muted, added, volume changes, plugin windows being opened, etc?

For some things you can get callbacks (via the virtual functions you need to implement for the control surface class) from Reaper, for other things you won't. So for the latter you will be spending some quality time implementing polling solutions, which is nasty.

The officially available Reaper plugin header is a bit out of date. You can see what is currently possible with the IReaperControlSurface class from these :

http://ge.tt/2ERBxz52/v/0?c

[Banned]

Originally Posted by Xenakios

The problem is that he is asking about Reaper integration. C++ would not be needed for the speed but for the integration into Reaper. ReaScript/Jesusonic just don't offer the needed functionality to achieve that. IMHO they should, but at the moment they don't. C++ certainly should not be needed to implement MIDI control surface functionality into Reaper.

Well, afaik you can get pretty much the same information via OSC as you can (easily) get via callbacks, without writing a single line of code, as arguably, REAPER's OSC control surface already features a working implementation of the entire IReaperControlSurface class (I haven't checked this out in detail, but suspect it matches almost 1:1). Using this as a basis for integration certainly has its limitations, but it comes for free, out of the box, and it's good enough for a whole bunch of 'deep integration' stuff for many things the OP mentions (e.g. handle tracks being muted, added, volume changes, plugin windows being opened).

Again, I'm not arguing against using C++ at all, only mentioning an alternative approach.

[Geoff Waddington]

Originally Posted by Xenakios

For some things you can get callbacks (via the virtual functions you need to implement for the control surface class) from Reaper, for other things you won't. So for the latter you will be spending some quality time implementing polling solutions, which is nasty.

Right on, as usual man.

However I wouldn't quite call polling nasty.

There is a function (Run I think) that gives you a hook for polling (runs about every 30 msec if memory serves).

From there it is easy (but a bit tedious) to implement collections (arrays, dictionaries, whatever you like) to hold current value for each watched param. Then you just do a simple compare to new value (by calling the appropriate Reaper API) in the Run method and only update as needed, this is helpful for a slow protocol like MIDI, no redundant updates please

@Banned = I'm not sure that you can't use OSC, but last time I checked the plugin API set still had the most extensive coverage, and seems to fit better with the OP's fairly intricate intentions, not sayin' you can't do it with OSC though, just not sure

[Kyran]

Thanks a lot gents, this gives me something to go on. I've downloaded the plugin headers. I'll be sure to have a look at the OSC implementation, at least as an example for my own code. I'd probably rather write everything in C++ than have to do OSC scripting in an external app before it gets to Reaper.

I guess with Midi being relatively imprecise in the time domain anyway, polling isn't tooooo nasty. Not quite as clean as being event driven for sure, but it shouldn't be too bad. I guess that depends on what I can and can't register listeners for. It's still a better option than no option at all.