Hi Paul. How’s the wife and iguana?
Wife good, iguana long dead.
Roli’s financial troubles, continued:
Hmmm. Roli meant Juce got more open to MPE stuff. Made sense, was great. With PACE our dreams regarding dongle integration into Open Source software will finally become… I don’t know. But good to hear JUCE will be further financed and the JUCE devs will still have a job in the long term.
Hope Role makes it! All in all they make cool stuff!
I’ve been thinking for a month or two that the current round of Lumi delays were just Roli stalling until another round of funding comes through. They just announced ship dates for the rest of us. (Strong correlation on that timing…)
Roli seems to be all-in on the Lumi app, and its premium subscription. If they can get through this launch, that’s their path to financial solvency. So, most of their eggs are in that basket for a while.
I’m fairly confident that they’ll make it, but how much their continued existence affects us here, is hard to predict.
sad day 
JUCE is really important, and so always a bit scary when it changes hands - though I could possibly see PACE being an improvement… as long as it doesn’t tinker too much with the GPL and licensing model.
its really sad, that it looks like Jules is staying with Roli (and doing SOUL there), Juce without Jules at the helm is a concern. (even if he is going to have some kind of ‘advisory role’)
also, it does point to Roli have financial issues… and really sad to hear that they have not shipped all the Lumi to kickstarters (Id not followed after I dropped out).
I really hope Roli can pull thru this.
1 Like
Just got my tracking number. (UPS thinks this Friday)
(They’re down to their last 700 shipments, but it sounds like quality control has been out the window under quarantine. Which is unfortunate, since “they’ve had time to correct a lot of issues” was our only consolation for some time now.)
Also worth noting, they’re still selling off assets.
…but they should be able to do their public launch when things go back to normal, and if the world economy hasn’t collapsed, maybe they can get paying subscribers onto the premium service.
Pulling through this is largely a race against time, but they’re all in with this strategy to widen the customer base.
thats great news - very pleased for you!
odd… Id have thought they would sell of FXpansion as one thing.
I feel for Roli, they obviously were going thru a difficult time anyway, and the current situation makes it even harder
and best wishes for Roli, and their employees.
BFD has a more general market than Strobe and Cypher. It was probably easier to find a buyer for just that.
Side note:
They gave Strobe and Cypher licenses to the multi-unit folks who were still waiting, more than a few months ago. I already owned those, so I asked for BFD instead. They said they couldn’t offer that. Now we know why.
(and also, that these negotiations take FOREVER to go through)
2 Likes
Two units have arrived. (they shipped in pairs)
I plugged one in, to start with, and am noting first impressions.
-
It’s very pretty to look at. No scratches on this unit.
-
DNA connector layout: There’s a pair on either side, as you’d expect. On the back, there’s one and two half pairs. No connectors on the front. (so, you can snap another block on either side, at rear center, or spanning two units in the back.)
-
If you’re using the USB port (for charging and/or MIDI transmission), that’s in the back, next to one of the DNA connectors.
-
Key size is more compact than a piano, but less cramped than a typical mini keyboard. Feels pretty natural to me.
-
Velocity: You do have to press deeper into the key than I’d prefer before your touch registers. Let’s call it “spongy”, for lack of better terminology.
-
Release Velocity: I’ll probably never use that, but I’m able to see it.
-
Pressure: It feels very well suited for “aftertouch as an effect” applications, where a more deliberate press is required. Does not seem remotely usable as a continuous volume or filter control.
I need better vocabulary for that last bit, but it’s become clear in recent years that there’s a difference between “pressure” and “aftertouch”, and that MPE probably backed the wrong horse in using aftertouch data to represent pressure.
“Pressure” is light and continuous, tracking across the duration of your note. Parameters responding to expression (CC#11), breath control (CC#2) or filter (CC#74) will map well to this.
“Aftertouch” is a secondary effect. After playing your notes and hearing them out for a moment, you can press harder to make things more intense somehow. This could mean making things louder, or harsher, or adding vibrato, etc. The intended gesture is “cranking it to 11.”
Of course, that’s implementation. “It’s just numbers”, after all. And indeed, I think the industry has always regarded polyphonic aftertouch as more of that first category. But they just won’t budge on channel aftertouch.
(Synths typically respond to channel aftertouch with a more dramatic effect than us MPE folk are looking for out of pressure data, and it’s sort of our fault for sending the wrong signal.)
Anyway. This requires a concerted effort to trigger aftertouch. Once you’ve pressed into that range, it’s very sensitive. But the threshold is higher than what’s needed to trigger a note.
This is exactly what you’d expect from a keyboardcentric midi controller outputting channel aftertouch. It’s a good “aftertouch” implementation. But it’s not what you’d want from a midi controller outputting “pressure” on each key.
You can adjust the sensitivity curve, but at this time, the threshold itself is off limits.
There’s not much reason to use poly aftertouch, as provided. I think it makes more sense to reconfigure that as channel aftertouch.
(If I had to guess, I’d say there’s a single row of Roli’s typical sensor material inside of the Lumi, and that the keys are pressing into that.)
Hacking / LED Feedback
This part’s weird.
Send it a note, that key lights up as though pressed.
It’s not looking for “velocity 0” to turn off that light. You actually have to send an actual “note off” message. Or what they call “lift”. Like, the Note On identifier byte (in channel 1) is 0x90, or 144 in decimal. A message using that will turn on an LED. To turn it off, you need the equivalent Note Off message (which starts with 0x80, or 128 in decimal).
I’m not sure what the ramifications of that are. Your DAW probably converts those proper note offs to “note on with velocity zero”, so replaying your performance like a player piano might not work out well.
Note: there’s no obvious way to turn off local feedback, so physically pressing and releasing a key will turn off that LED.
Also, there’s no obvious way to change the active/highlight/note on LED color. That’s just going to be white.
I’m able to clone the sysex messages that Roli is sending to set scale modes, background colors, etc. I can’t arbitrarily set the colors of individual keys, but this is a lot of what I was after on that front, anyway.
Also, I haven’t been able to generate my own RGB tones programmatically, because there’s a checksum involved that I haven’t worked out yet. But I can just grab the messages for a handful of colors, and call it a day.
I don’t know. I do like this controller, but I have to rethink my use cases for it.
Current Progress
I have a full set of triggerable messages to set to root note of the scale. And a menu of selectable scale/mode types (blues, pentatonic, whole tone, etc).
I have yet to analyze and compare those scale/mode messages. I’m hopeful that we can format messages to create our own scales, in addition to what’s provided. But this does have the same challenges as providing full RGB support – the second to last byte is some kind of validation checksum, and I can’t test any theories without first learning how that’s constructed.
But mimicking the existing signals works flawlessly.
Other observations…
-
these messages work across multiple units
-
the root tone messages work across any scale. (meaning, the LED transposition happens in hardware)
-
Any other behavior (mostlu involving LEDs dimming and brightening) also appears to be stored in the firmware. Which is a shame, as I hate most of them. (especially annoying: those don’t span across multiple units.)
3 Likes
The default script is still crazy limiting, but it looks like we have littlefoot example code to change that now.
2 Likes