How to 'rate throttle' your device?

General discussion
1

I see the device section supports ‘rate’.

but i cannot find documentation.

what value do i have to put in? is it in percentage or max updates per second?

2

There is an optional rate attribute of the device object in the JSON. You can use it to specify the time lag between individual messages. The lag is specified in milliseconds. A snippet from the docs:

rate

A minimum wait time between sending MIDI messages to a device, specified in milliseconds.

  • optional
  • numeric
  • min = 10
  • max = 1000
"devices": [
   {
      "id": 1,
      "name": "My MKS-50",
      "instrumentId": "roland-mks50",
      "port": 1,
      "channel": 1,
      "rate": 20
   }
]

… sends messages in 20ms intervals.

2 Likes
3

Ah thanks, I guess I need glasses was really looking in the docs.
This will be great for the DX11 template. No more midi buffer overflows I hope.

Cheers

TIm

4

Hej @martin,

I’m trying to get the snapshots working with my Ambika, but it seems, that the MIDI messages are sent to fast from the Electra to the Ambika. I tried to set another Rate [ms] in the editor, but the timestaps between MIDI commands (NRPN) seem not to change in my MIDI monitor when sending a snapshot besides different rates.

Does the option affect the snapshots?

5

I will review that one. I am pretty sure that individual CCs of the NRPNs are not rate limited. Only the NRPNs as wholes. That is one thing to improve from the very beginning. I will get back to you on that.

1 Like
6

I think the issue is (also?) that when a snapshot is loaded, all the parameters are sent immediately?

I guess my question is - what happens when a snapshot is loaded?
Do you just run through the parameterMap and send the saved values?
That flood of MIDI may overrun some devices.

7

yes, snapshot is just a saved dump of the parameterMap. When you load a snapshot, you just populate all parameterMap entries and the messages are triggered. These messages go to the device outgoing queue which has the rate limiter. The problem is that eg. NRPN is considered to be one message. The individual ccs will go out without any limit. But as mentioned, I will review it. There were quite intense changes made between 2.n and 3.n firmware.

1 Like
8

ok, that’s good to know that the messages all go through the standard queue and send process.

So a snapshot that sent a bunch of sysex messages should be fine, as well as the ‘normal’ note and CC stuff.

9

Does that mean, @martin , that as a workaround, one could set the throttle at a higher rate than needed for CC’s, just to get the NRPN pass thorugh well when changing snapshots?

10

@martin A killer feature for the snapshots would be morphing between two for a performance!

I also tried giving names to snapshots via the console mac app, but they are not shown with firmware 3 anymore.

Looking forward for some updates :slight_smile:

11

Just saw the snapshots part of the browser editor… so I can name them there.

12

Would the “rate” property affect messages sent from Lua as well?

13

Hi yes it does.
At least from my experience writing the LUA code for the Ensoniq Mirage Masos template.

2 Likes