Blocks and MIDI

General JUCE discussion
1

This question is not about Juce actually, please do let me know if I should post it somewhere else.

So I connected the Lightpad Block via USB to my Linux machine, great it shows up as a Midi device and I can access it through ALSA.
I have the following questions:

  • Right now it is generating channel messages, (those described here ), but previously I have seen it generating sysex ( I believe it was while it was connected over bluetooth to noise). Is it possible to force MPE mode or API mode manually?

  • Can I assume this page contains the full specification for the sysex?

  • How much can we rely on the MPE ad API mode being supported in the future?

  • I find that I have to hit the pad quite hard in order to trigger a note at all (or to get the desired velocity). Is there a way to adjust the sensitivity to the touch?

  • Even when connected over USB, I find the response of the device is pretty slow (i.e.: a noticeable latency between hitting the pad and receiving the MIDI message on the computer). What is the declared action-to-MIDI latency? Is there a way to improve it? Is this somehow related to the 25Hz refresh rate of the LEDs?

Thanks,
Giulio

2

Great that you’re trying it on linux - we haven’t really tried that yet ourselves!

It goes into API mode when it receives some kind of API message, and stays there until the API messages stop and it times-out.

Yes, that file contains the current sysex format, but it may change! (There’s at least one part of the sysex layout that will definitely change in a future version). My recommendation is do not bother trying to generate these sysexes yourself!
It’s not a simple protocol, it will change over time, and since we’re giving away our implementation as a completely 100% permissively-licensed SDK, there’s no reason not to use it. If anyone posts moaning messages on the forum in the future that we’ve changed the protocol and broken their implementation, I will have very little sympathy!

No, please don’t assume that MPE mode will continue being supported - it’s under discussion right now. We think it’s not a long-term solution because for the pad to be versatile as a standalone device, there are just too many parameters you might want to change - e.g. the octave, scale, various modes, drumpad mappings. And unlike something like the RISE, the device has no physical interface for controlling all these things.

Actually, my favourite recent idea is for us to remove the built-in MPE mode but extend littlefoot to be able to send MIDI messages, so that an app can send it a program that does exactly the same job as MPE mode, but being a modifiable program, would allow the to tweak its behaviour in any way we want, and people could run custom-hacked MPE mode implementations.

The sensitivity has been fine-tuned to be the best possible match for the silicone and pressure sensor behaviour. Maybe in future we’ll find a way to get a greater range of sensitivities, but it’d need a different physical design, it’s not just a software parameter.

Nope, latency has nothing to do with the 25Hz display rate. The sensors are scanned every millisecond, and converted to MIDI messages immediately. Any latency comes from the USB/Bluetooth protocol, and your computer’s MIDI driver (and of course whatever synth/audio output you’re using). I’m told that the touch-to-host latency over USB is about 12ms, so anything above that is beyond our control.

1 Like
3

Interesting stuff! I havent got my hands on the lightpad block yet (ordered from roli.com for uk delivery so have to wait a little while) but I bought it to use for my own app development but also as an MPE controller (I got a seaboard rise 25 recently, love it and want more :smiley: )

I understand what you are saying about MPE configurability, but all the same I am slightly alarmed at the prospect of losing built-in MPE output. There is something desirable about getting appropriate midi messages out of the device without having to run a particular app. I would not mind having to run a particular app to change MPE settings, but would want the device to remember these and work standalone, similar to how the Rise Dashboard works. Longer term I would be quite happy if a new block hardware module was released that allowed for MPE configuration if there are reasons why the lightpad cant carry the full weight of this on its own.

4

Not sure why my reply would alarm you… Obviously we want this to be a ‘pro’ level controller and to have it controlling 3rd party midi software and hardware. Exactly how best to implement that in a powerful, flexible way is what we’re currently figuring out. But there’d be no need for new hardware, the current device is more than powerful enough to send out plain old midi in whatever form we need.

5

Thanks for the reply!

Perhaps alarmed was the wrong word, and I am at the disadvantage of not having yet had the opportunity to try the current MPE mode. As long as I can get midi out of the device without having to run a particular app, there will be no complaints from me!

Anyway exciting times eh, I’m so pleased Roli made the device open, after all these years I finally have a reason to use C++ rather than avoid it :smiley:

2 Likes
6

Please don’t remove the MPE mode, that is one of the main reasons I’m interested in it! As an app developer who has long supported multi-channel midi input in my apps (ThumbJam, DrumJam) it would be a shame to see plug-and-play hardware support for it to disappear by default. MPE is a spec in which Roli is trying to promote, after all!
(Jules, we met at NAMM this year, incidentally). Being able to use any app (or hardware synth via USB-MIDI!), even one that doesn’t use the SDK/API mode is vital, I think. It seems that the control block provides opportunity to change some built-in parameters in MPE mode (octave, at least)… so don’t give up on the concept yet! Your custom littleFoot idea is intriguing, but requiring it for MIDI output means almost no one will get the benefit! Don’t underestimate your probable user-base’s capabilities when it comes to MIDI.

I just picked one up today, and I too am a bit disappointed in the pressure sensitivity curve. I understand the minimum recognition threshold is dependent on the sensor, but looking at the channel-pressure output, i feel that the most musically useful amounts of finger pressure occur when it is sending out from 1-15, and I feel uncomfortable pushing any harder than when it outputs 64 in actual playing. Does that curve represent the raw resolution and response of the sensor? Even if it did, I would recommend being able to set the scale/curve of the MPE channel pressure output to better match real-life playability (without having to make the user use custom pressure curves in every app or synth to deal with it). And Roli’s apps should have a pressure scale/curve adjustment settings too :slight_smile:

I haven’t tried the SDK yet, perhaps the data from touch events there yields more resolution?

7

If you think that, then you completely misunderstood the idea! Don’t panic, we have a great plan for this that will support everyone’s needs, and is much better than just having a boring old built-in MPE mode.

8

Maybe… the API provides 8 bits of pressure rather than 7. And we don’t attempt to provide a pressure curve in the hardware, it’s up to software to do that as appropriate, since usually you’ll want it to be user-configurable. Do we not already support that in NOISE? If not then I’m sure we’ll add it soon.

9

Last time I posted I hadn’t got my hands on any lightpad blocks but now I have 2 and have spent a while playing around with them and reading SDK/JUCE documentation and example code whenever I have spare time. I’m really enjoying them and will be going ahead with developing my own things for them using JUCE although it might take me a while to get into the flow.

I think the concerns/fears about potential future loss of the current MPE mode is because you mentioned custom apps and lightfoot. And people probably associate lightfoot with code that is sent to the block every time via an app that uses the API. You keep indicating that there is a misunderstanding somewhere but with the present info available I’m not sure where it is exactly. Perhaps a logical guess would be if you are hinting that lightfoot code could instead be sent to the block and remembered by the device, without an app on another device needing to run every time. And this mode becomes the default when no API messages are received, replacing the current MPE mode. Is that the sort of thing you were getting at?

In the meantime, I dont suppose there are any undocumented commands/midi messages or whatever of any sort that can offer any configuration of the current MPE mode? Because I sure do like to hook a pair of lightpads up to other ipad and desktop apps - I was pleased that hooking up a second block when in MPE mode gave me more notes that continue where the highest note on the first block left off. But it would be nice to play with the scale and initial note. I wouldnt even mind having to buy a Live Block if it offered some config of MPE mode but I’m guessing it doesnt at the moment and only works with the noise app or our own apps?

I have no latency complaints using either usb or bluetooth with iOS and OS X, and am really quite impressed in general with these lightpads.

10

Steve, can you check the update rate you are getting from your lightpad using a tool like MidiMonitor on the mac connected via USB? I am seeing fairly low rates for both MPE mode and SDK events, roughly one event every 31ms, or in the case of MPE mode, each dimension is only updating every 50ms (a pitchbend, CC74 and channel pressure, alternating one event every 17ms). I want to see if others are seeing the same thing, or if there is an issue with my hardware. This low of an update rate leads to stepping pretty quickly with fast motion/pressure changes…

For comparison, the Seaboard Rise over USB updates all dimensions roughly every 7ms.

I’ve talked to the Roli folks and I know they are working on firmware updates, but I’m not sure if they are seeing the issue themselves, and I’d like to eliminate variables here.

Thanks!

11

Sure, I’ve now monitored MPE mode and can confirm your numbers. Per note/touch/channel that is, since overall message rate for multiple notes/channels/touches is better than you indicate, though this does nothing to help the stepping issue per note/dimension that you describe. In practice so far I hadnt noticed stepping but thats probably a question of playing style, what parameters I was controlling and my attention focussing elsewhere - will be interesting to see how much it gets on my nerves now you’ve pointed it out.

12

That’s true, my numbers were per touch/channel, a good distinction to make since the data rate is indeed higher overall with multiple touches happening. But the per-dimension data per touch rates are what I’m mainly concerned about for playing.

13

I’m rather tired but I think I just read on some music site that the stuff strongly hinted at earlier in this thread has been properly announced at NAMM. Blocks Dashboard and uploadable scripts. Available February 16th I think it said, though I dont know if the dashboard and the script uploading arrive at the same time? Not got a link handy at this moment due to tiredness - I just wanted to comment here and say cool, I’m very happy this is happening. And thanks for sharing some hints about this stuff way before this announcement, it saved me from wasting my time hacking together my own crude solutions. And is there any way to apply to beta test this stuff before it gets fully released? I presently have a pair of lightpad blocks but none of the button-based blocks.

14

Yep, we’re showing BLOCKS Dashboard at NAMM right now!
Anyone who’s at the show, please pop over to the (very impressive) ROLI room and say hello!

1 Like
15

Sorry to resurrect an old thread, I just found this and interested if there are any updates on the custom hackable MPE ideas mentioned here?