Headless/Remote Control

[Rippert]

I have an interest in using R+ headless and remotely controlling it from a different computer or tablet or phone, etc. The idea being to not open the GUI on the host machine at all to make more CPU time available for the audio.

There was a rakarrack-headless project on GitHub, but it only went so far. There were several issues with being able to use Rak headless. Would you be interested in work in that area?

In terms of remote control, R+ has, I assume, the same default MIDI implementation as the old version. While extensive, it is not complete without functions such as editing every parameter in every FX unit, being able to edit presets and save new ones, changing preferences, etc. I thought I saw that you had added somethings like bank change to the default MIDI. Would you be interested in a more complete remote control system like OSC? I see you have liblo already for NSM support.

[Stazed]

Original rakarrack and r-plus can both be run headless. From command line -n parameter. R-plus can be run gui optional in an NSM session.

For MIDI control, the default MIDI implementation table is the same for original and r-plus. Only the addition of CC 0 bank select, and CC 32 bank select fine for custom MIDI program change table were added to r-plus.

MIDI learn was extensively expanded in r-plus to include the vast majority of effect parameters, all sliders, value input, choice menus. If there is some specific parameters that you really want added that are missing, give me a list.

Not sure what you mean by not being able to edit presets... Saving presets currently requires the gui to be shown, but with NSM support, the gui can now be shown or hidden without restart.

I really do not understand why you would want to change preferences in headless mode. Which preferences do you need to change remotely, without the gui, and why?

As far as OSC, it is not something that I would want to pursue. It would not provide any additional control by itself, and any additional control features could probably be added more easily to MIDI learn.

[Rippert]

Really I'm talking about a full remote control. So that R+ could be running on a true headless system with no monitor, but could be fully controlled from another computer. Right now that would have to be over VNC or the like. That works, but my goal is to control everything with a smartphone via a webpage. I've got the basics of this working for guitarix using Open-Stage-Control via a JSON-RPC to osc translator. Guitarix already has the ability to run the gui on a separate machine from the audio engine, but that requires a linux OS to run the GUI.

Open-Stage-Control can control both osc and MIDI messages and makes a GUI control surface webpage available on the network.

I can work with the expanded MIDI-learn, but it would be very useful to have some ability to save a preset if it has been changed in the headless setup. Seems like that would need a SYSEX command over MIDI since you need to be able to set the name of the preset. Changing preferences remotely is really just a low priority, nice if it worked, kind of thing.

Don't worry about this if it's not of interest to you. I'll deal with what is there, and if I can come up with some new features in my cloned repository I'll send you a pull request.

[Rippert]

Hey, thanks for mentioning NSM. Looks like it can be controlled by osc, and that can save presets. I'll try that approach.

[Stazed]

I suspect that NSM is not going to work for your approach. The issue is that original rakarrack and r-plus are basically designed for live performance when headless. All the editing is supposed to be done with the gui shown. Even MIDI control changes would not have been saved during live performance, just adjustments to existing presets for the performance.

The way r-plus works under NSM does not allow saving of presets headless. You can save user preferences for each individual instance, and which preset from a bank to start a session, but saving must be done with the gui, manually. In addition, presets must be saved to a selected user bank, and the name must be set.

[Rippert]

OK, I see what you're saying. That does limit things.

[Stazed]

Can you create and send SYSEX with your setup? If so, then that could be added...

[Rippert]

Yes, It can do sysex.

[Stazed]

O.K. I will look into what needs to be done. Might take a little while as other things are consuming my time right now.

[Rippert]

Thank You. No problem if it takes some time. If you point me at the right pieces of code, I'll see what I can do to get things started.

[Stazed]

In the sysex branch there is now an alsa sysex save routine that may actually work.. For the sysex format, check out the parse_sysex() routine comments in rkrMIDI.C. There is also a SYSEX.pd patch for "Purr-Data", the fork of Pure-Data that I used for sending and testing.

Alsa only for now... Would appreciate any feedback.

[Rippert]

Thanks. I looked at the code, and it seems straightforward. I won't be able to get to testing until Monday, but will do it then and report back what I find.

[Stazed]

Jack should be working now as well...

[Rippert]

Hey, I'm hung up on some other things. I'll get to testing this in the next few days. Thanks for working on it.

[Rippert]

Just tested a sysex preset save. It worked well on both ALSA and JACK midi ports. Thanks.

Seems like, the way you have it setup, it would be straightforward to add a second "sysex type" at byte 6 and address any one of the several hundred parameters already mapped out at the top of rkrMIDI.C. say 0x02 at byte 6 followed by a single byte value (everything is already worked out to scale to 0-127), followed by the name of the FX parameter to address written in hex code. That would avoid the 128 controller limit and allow every FX parameter to be addressed.

Just a thought.

[Stazed]

A caution about using the sysex save. The code written was quick and dirty and will probably not work in all cases, certainly not for jack. The issue is that sysex messages can sometimes be split into separate packages if there is a large enough volume of other MIDI messages sent concurrently. The Alsa code might work and piece things together, but Jack will not. I need to do additional research and some stress testing should be done. Also, sometimes a checksum is used to confirm the whole message is received.

When using the sysex save, if you do not send with other MIDI messages, it should work though. At least temporarily, the sysex usage will be an experimental build option, disabled by default. Will put that in the cmake options at some point before the next release.

[Rippert]

OK, I wasn't aware of that aspect of sysex. I assume it's some kind of Jack thing, as I don't remember seeing that in the MIDI specification when I read it long ago. I prefer using ALSA MIDI due to JACK MIDI sometimes leading to xruns, so that helps at least my case.

I'll try to set up some automated CC's that can run while repeatedly saving a preset as a stress test. What should I be looking for, other than some kind of obvious crash, that might show that there is a problem? Preferably something I can automate.

[Stazed]

To test, un-comment the printf in parse_sysex() (rkrMIDI.C) and run in terminal. Watch for errors when running. You may get crash also. The ALSA code was rough cut and paste from another project which indicated split sysex packages. Did not have any JACK sysex example, and was not aware of it otherwise. Will need research...