Reason Remote MIDI Throughput

Want to talk about music hardware or software that doesn't include Reason?
Post Reply
djsmex
Posts: 248
Joined: 23 Aug 2016

28 Dec 2021

Hi,

Has anyone done any timed testing of the remote system? I know there is a 1mb size limit on the length of sysex messages but how many sysex messages can be sent per second from Reason, does the size of sysex message affect the speed? How many general midi messages like note/cc data can be sent and recieved per second?

Do midi messages get sent in batches from reason? If so is this based on sample rate or system time or midi clock? What is the max speed and volume of midi data reason can receive per second?

I didn't find any info for this in the sdk, is their any other documentation on the remote system anywhere else?

many thanks,
john

User avatar
mimidancer
Posts: 636
Joined: 30 Sep 2021

29 Dec 2021

djsmex wrote:
28 Dec 2021
Hi,

Has anyone done any timed testing of the remote system? I know there is a 1mb size limit on the length of sysex messages but how many sysex messages can be sent per second from Reason, does the size of sysex message affect the speed? How many general midi messages like note/cc data can be sent and recieved per second?

Do midi messages get sent in batches from reason? If so is this based on sample rate or system time or midi clock? What is the max speed and volume of midi data reason can receive per second?

I didn't find any info for this in the sdk, is their any other documentation on the remote system anywhere else?

many thanks,
john
I use and control hardware from reason without any issues. You can only send clock to one midi source from reason. I use a midi patchbay to distribute clock. As for 1mb limit. I did not know there was none, but 1 mb is huge in midi terms. I am sorry I do not know more techy stuff to tell you. But reason does play nice with hardware. Remember to set up a default template with your routings.

djsmex
Posts: 248
Joined: 23 Aug 2016

29 Dec 2021

Thanks for getting back to us, the reason I ask these questions is I am looking to write a virtual midi controller, that provides speech feedback of mapped parameters. This is a little like the native instruments NKS project but for Reason Remote and coded a little like the Novation Automap software as far as the codec/maps are concerned.
The automap software has a limit of 256 buttons and 256 pots but no delta encoders and some devices in the rack have over 700 remote items while the master mixer has over 5000 remote items.
If the remote system can send large blocks of data to cover for example every remotable item in the master mixer in say under a second, then the software can load an initial snapshot of all parameters on device focus and then the software manage the mappings. However, if it would take say several minutes to send large blocks of data, then the software would need a different design to get optimised performance.
There will be other things to consider like the throughput of the virtual midi cables, the process time of the software and any midi hardware also connected to the software.
I was hoping to build the software to be non midi hardware specific and allow multiple midi hardware devices be connected together to form large remote mappings and by managing the mapping in the software instead of the remotemap, allow for more customisable maps. However, if the throughput is too slow, then a different approtch is needed, perhaps a page based system a little like the Nektar codecs.

User avatar
mcatalao
Competition Winner
Posts: 1824
Joined: 17 Jan 2015

29 Dec 2021

Hi,

I think all reason SDK's are now open source? So you can easily check the specification for remote here:

https://developer.reasonstudios.com/dow ... r-products

As for your "1 mb" limit, I think what reason does is sending and receiving data through and trough as needed. It only sends a big chunk on device changing or block change (grouping), and I think it even doesn't do it as a batch. And as mimidancer said 1 mb is a lot of midi data, i only remember some odd situations where you'd like to send so much data, like a bulk load definition for a controller, or something like that.

Anyway on some older devices you can see it updating initial device status (i.e. BCF/BCR2000 have slower controllers as these are really old devices) but even for really big devices (i.e. the mixer, or a mamoth like Red Queen) it's not something that takes a minute, at most it takes seconds for a full refresh on a very slow device! And from that refresh, you move a fader on reason, reason updates your control fader, and same back so it won't send the whole lot of faders and knobs again. Also, remotemaps, work as filters for the devices, so if your controller has something like 100 controls and your reason device has 700 you can send only 100 controls defining them on the remote map.

About delta encoders (i assume you're talking about controlling the whole channels within the mixer with a smaller controler), this depends on the controlling strategy you want to use. At the remote level the mixer has 2 different scopes, the master mixer scope, where well, you can have an infinite amount of controls, but you also have the channel scope, where it only exposes the channel controls. From here, you get the control context of the sequencer->channel and control only that channel, vertically. So it depends on your controlling strategy and imho, something as a developer you should propose but leave to the users to decide, altering their own remotemaps. The other good thing, is that reason manages the deltas, with what is called the remote base channel, so you just have to select the previous and next 1 or 8 remote channel delta controls and reason does the rest. And again, this is not something you have to define on the lua codec, just on the remote map, or at the song project level. Still on delta encoders, and paging, reason has it's own page system, so if you don't have paging on your controller you can use the groups feature, where you can control that from reason. Paging/grouping allows for the example you gave of controlling more stuff with smaller phisical devices. You can work with these things together (use your controllers own paging system, with reason grouping, plus base channel). And you can cascade groups inside reason for REALLY BIG devices thought for the mixing i wouldn't recommend that as cascading groups gets a little fiddly!

Anyway, if you're entering this realm of controllers, you need coding knowledge (remotemaps are only one part of the equation). The other part wich interfaces reason with your device, has some parts, the most important are .lua codecs. It's a simple programming language, describing the device and behaviour establishing communication between reason and the device. At it's core, lua interprets CC info between reason and the device and back. Remote interprets at a higher level, per device.

I hope this brings you some insight on reason remote, but please follow that link and check the info! Again I know the architecture, been playing a bit with my RD88 to create a codec and remote for it, but haven't finished it yet and my hands on experience with it is limited.

Good Luck,

MC

djsmex
Posts: 248
Joined: 23 Aug 2016

29 Dec 2021

thanks for getting back to us mc, much appreciated
The aim of my project is to use virtual midi cables with a web app and midi hardware, so that the web app can speak out control parameters and their values. I have some initial prototypes working but what I am looking at, is would it be workable to use the style of codec used by the novation automap software, if the number of mapped controls were increased from 512 to say 4096 or even 8192? The only issue would be like you said when a reason device first gets midi focus and the changed_items would equal all mapped items. The novation automap software works by the lua codec and remotemap using generic 256 buttons and 256 pots and the automap software sits between the midi hardware and reason remote. The mapping of controls is done in the automap software and midi feedback from reason remote is shown on the automap software.
When I talked about delta controls I was refering to endless encoders that work by using +/- incrimented values instead of absolute values from a pot or fader. The novation automap software doesn't use delta values in its codec.
The thinking behind using the novation automap style of codec/map was to allow any midi hardware to work with the one codec/map via the web app and virtual midi cables. It would also allow for a web ui mapping solution instead of end users writing remotemap files.
The loopmidi software defaults to 5000 midi messages over 5 seconds, does this sound like what the remote system can output?
Another option may be to split reason's midi output across multiple virtual midi ports also something that seems quite common.
many thanks, john

djsmex
Posts: 248
Joined: 23 Aug 2016

30 Dec 2021

Just did a test with loopmidi, webmidi.js and custom lua codec/map sending 8194 short sysex messages. This took 34 seconds, around 241 sysex messages per second. I'll do some more tests to see if longer sysex messages take longer to send and may be test other midi messages like note/cc.

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 8 guests