When I move the pots and faders very slowly they send an event for every MIDI value from 0-127, but if I move them faster they skip values. If I set the bit depth higher, they send events more frequently but still skip values.
Is this expected? I want to always receive an event for each value reached by a potmeter.
I’m using Grid editor 1.6.2 with a PBF4 E-32 v1.5.0, and I’m inspecting the MIDI events in the Grid editor MIDI Monitor.
Yes, that’s possible.
There is an internal limit for how fast the LUA engine can process inputs. This limit is about 100Hz, which means if you send more than 100 input values to Grid, only 100 of those will be processed and the others will be skipped.
Yes, I noticed that and reported it on Discord long time ago, and that’s a big limitation for my use case.
Is the limit 100 input values per second? Does this apply equally to all resolution settings (MIDI 7bits / 10 bits / 14 bits)?
I would be interested to know.
The limit is that maximum 100 inputs per second will be passed to the LUA engine to be processed. This is an inherent limitation of the engine.
May I ask, what is your use case? Why is this a big limitation for you? Maybe we can do something about it if we know more.
Thanks for the quick replies! Just wanna add that I’m LOVING the controllers and the grid editor. I just bought a PO16 and BU16 to add to the rig. But I’m about to issue some criticism on this 100hz limit.
Here is the use case I’m working on right now, following this pure data tutorial video; I’ve linked to the time where it explains the implementation: https://youtu.be/J-p9UmjUN0Q?t=476
I’m looking for MIDI control change events and triggering notes when certain values are sent, imitating a harp or guitar strum. But if I sweep the full range of a potmeter in less than 1.27 seconds, or at imperfect speed, it will skip values and inevitably miss triggers.
I can imagine how to work around this with code, whether in PD or maybe in the grid lua editor itself, but it’s complicated. I have to store the last transmitted value, compare with the current one, if it skipped one or more(!) trigger values along the way… and I need to do that extra handling every time I want to trigger something based on a specific value or value range from a potmeter.
Maybe this is an inherent issue with all MIDI controllers? The Korg Nanokontrol2 used in the video seems to handle it well.
My expectation is that as I sweep a potmeter, I get every value along the way, one time, as the potmeter sweeps past that point in its range.
Going into this I was thinking I’d just give up on this project but the more I think about it the cooler it sounds to strum on a fader while changing cords with buttons, LOL! So I’m hoping there’s some good native workaround or solution that I’m unaware of.
Hi @narayb, thanks for the reply.
Similarly to @user254, I’m using the controller with SuperCollider, an audio-synthesis language, in 14-bit MIDI mode with an effective resolution of 10 bits.
In 14-bit MIDI mode, fast movements of potentiometers or faders can easily generate well over 100 MIDI messages per second. When this limit is hit, MIDI data appears to be dropped or throttled, which results in missing control updates on the SuperCollider side.
In an audio context, especially for high-frequency parameter modulation (e.g. pitch controls), this manifests as clearly audible stepping and zipper noise, rather than smooth, continuous modulation. The issue is therefore not just about control responsiveness, but directly impacts audio quality and signal continuity.
Supporting a higher sustained MIDI message rate would make a substantial difference for synthesis and modulation-heavy use cases. I would genuinely love to see the engine handle more than 100 messages per second, as it would unlock much smoother and more expressive control in near-audio-rate scenarios.
Thank you!
Hi @ayalavalva !
So it seems that both of you use completely scriptable, custom audio evironments which allow you to customize the data flow from a Pitch Bend message (or the note inputs) to the oscillator itself.
This is something that commercial Audio Workstations and synths already do natively, for example they use smoothing algorithms for Pitch Bend inputs to generate a smooth audio output.
In cases like yours, where you work with raw code and data from a controller, you’ll probably have to implement these algorithms yourself if you want a completely smooth audio output.
This is not a feature controllers do natively, at least I never tested one that does this. For example I just tested an M-Audio Keystation61 and that has a dedicated Pitch Wheel. At the slowest speed inspecting the input with MIDI Monitor I could see that it’s actual resolution was just 7bits, as you could see no smaller step than 128 values.
And yet, when used for Pitch Bend in Ableton, it produces a beautiful, non-stepped pitch modulation.
So in conclusion, no controllers do this smoothed out of the box, most of them skip values sometimes. Some do bigger steps, some do smaller. Therefore most software use some kind of smoothing algorithm for sensitive inputs. In environments like PureData and Supercollider this would require building a simple smoothing device/algorithm or a filter before sending the controller input to the oscillator.
As a sidenote, you could do the smoothing Grid-side as well. We have an example of it on the cloud, called PID smoothing or something similar.
Hey @narayb , thanks for the reply. I already implemented an interpolation algorithm in SuperCollider to smooth incoming MIDI data, but it’s obviously preferable if the controller itself can transmit a higher message rate.
Is increasing the maximum number of MIDI messages per second the LUA engine is able to handle something that could be considered? When turning a potentiometer through its full 300° range very quickly, I sometimes observe as few as 7–10 MIDI messages arriving on the SuperCollider side.
Thanks for the info @narayb! I will try out the smoothing algo in grid and let you know how it goes.
Would be cool for sure, but it depends on your application, doesn’t it?
We had to set some baseline speeds for the whole system, and because all Grid modules communicate everything with each other this 100 Hz restriction does fit into the whole system nicely.
If we reduced the delay further to 2ms let’s say, we would run into a processing issue somewhere else in the pipeline: maybe the baud rate of the inter-module communication would be too slow that many messages? I can’t really tell.
Because Grid is a very complex system, that allows you to bend the rules and create workarounds in most places, there have to be some hard limits based on the hardware we chose. This feels like one of them.
So, as in with most cases with audio: your choice will be between fidelity of the signal and latency of the signal. The difference is that we can give you the option to increase latency on the device to increase the fidelity of the output. But in your case, the best bet is still just using a filter on the software-side of things probably.
But let me know if I’m wrong in some aspects, as I’m tiptoeing the line of my expertise here.
No worries, I understand the ecosystem has constraints. There may have been a slight misunderstanding on my part. When you said in your original reply, “Maybe we can do something about it if we know more,” I assumed this referred to increasing the number of inputs per second at the hardware level.
Regarding your previous message, is there currently a way to increase the devices’ latency programmatically?