Can someone please show me how to use ‘virtual’ as a message type? What I want it to do is send B0 24 00, B0 24 01, and so on, up to B0 24 7F when I turn a pot. If I’ve understood the ‘virtual’ message type correctly, does it connect to LUA code that does the job of sending the MIDI message?
In other words. Message type virtual does not send MIDI on its own without LUA code?
correct ; you typically use a Virtual if you want to do it something out of the ordinary. You then make a function in LUA with what it is supposed to do, and assign that function to the virtual control.
I need help from the forum to do this. I’ve tried a few different things but haven’t succeeded.
I need a control (virtual) that sends out MIDI (from the list at the bottom of this message) when I turn the control (pot) clockwise.
When I turn it anti-clockwise, it should send out MIDI in reverse order, so start with the last MIDI message in the list. The list is 257 MIDI messages long. So when I turn the pot clockwize it should send out 257 MIDI messages. And 257 MIDI messages when you turn it back anti-clockwize.
I don’t follow. Are you now saying that the same position of a control is always transmitting a different value, depending whether you are turning clockwise or counterclockwise?
Because to me it looks like the left value is always B0 24 7F , the middle value is always B0 24 40 and the right value is B0 24 00. For some reason Modal also uses B0 34 00 as an alternative for B0 24 00.
Providing a list of only results, doesn’t allow me to understand what the problem is. It’s just a list.
Try making a formula where you start from a E1 fader control value and convert it into the result you want to send to Modal.
Yes, the same MIDI message behaves differently depending on whether I turn the knob clockwise or counterclockwise. I’m not sure what the team at Modal was thinking when they designed it that way. It seems that the message B0 34 00 changes its effect—from decreasing to non-decreasing—depending on the direction you approached it from.
i don’t see the difficulty, sorry. From what I understand:
If you turn clockwise, thus from left to right, it starts at B0 24 7F and ends on B0 24 00.
Thus left = B0 24 7F and right is B0 24 00.
If you turn counterclockwise, thus from right to left, it starts at B0 24 00 and ends on B0 24 7F.
Thus again left = B0 24 7F and right is B0 24 00.
Seems pretty straight forward: you have a control that goes from left to right : x = 0..255
All you need to send out is “B0 24 (255-x)” as a sysEx string.
Hard to explain. I’ve been sitting all day testing different things. This is what I came up with. LFO Rate has two different modes. You can switch between modes with B0 34 00 and a special value. But there are two LFOs and Modal has been so stupid that B0 34 00 is the same for both LFOs and the value is also the same so my conclusion is that you can’t make a preset for it. Or at least very difficult.
Yes it starts with B0 24 00 but when you have turned the pot so you have B0 24 7F it sends out B0 34 00 but if you continue to turn in the same direction (clockwize) you have 128 more values from B0 24 7F to B0 24 00. Same the other way around so you have 257 MIDI messages when you turn the pot clockwize. And 257 messages of you turn it counterclockwise.
If that is indeed the case, I don’t see a viable solution. You could figure out a temporary solution within one patch, but since you get a B0 34 00 to switch between 2 modes, regardless of direction, there is no way to tell in what mode a newly selected patch would be. What you should try out is one control of 128 values B0 24 00- 7F and one temporary toggle just sending B0 34 00.
Here is the logic to control lfo 1 rate/clock-div and lfo 2 rate/clock-div on Cobalt5S with virtual controls. I hope someone finds some benefit from my reverse engineering. The two parameters share the same CC 52 but with different values. I’m sure this would never have been possible with any other MIDI controller. Thank you Martin for building the best. The code could probably be written smarter but I’m glad it works at all
function lfo1_Sync(valueObject, value)
value2 = controls.get(11):getValue():getValue()
if value == 0 and value2 == 0 then -- lfo 1 rate, lfo 2 rate
midi.sendControlChange(PORT_1, 1, 52, 0)
-- 0
end
if value == 1 and value2 == 0 then -- lfo 1 clock-div, lfo 2 rate
midi.sendControlChange(PORT_1, 1, 52, 1)
-- 1
end
if value == 0 and value2 == 1 then -- lfo 1 rate, lfo 2 clock-div
midi.sendControlChange(PORT_1, 1, 52, 2)
-- 2
end
if value == 1 and value2 == 1 then -- lfo 1 clock-div, lfo 2 clock-div
midi.sendControlChange(PORT_1, 1, 52, 3)
-- 3
end
end
function lfo2_Sync(valueObject, value)
value1 = controls.get(3):getValue():getValue()
if value == 0 and value1 == 0 then -- lfo 2 rate, lfo 1 rate
midi.sendControlChange(PORT_1, 1, 52, 0)
-- 0
end
if value == 1 and value1 == 0 then -- lfo 2 clock-div, lfo 1 rate
midi.sendControlChange(PORT_1, 1, 52, 2)
-- 2
end
if value == 0 and value1 == 1 then -- lfo 2 rate, lfo 1 clock-div
midi.sendControlChange(PORT_1, 1, 52, 1)
-- 1
end
if value == 1 and value1 == 1 then -- lfo 2 clock-div, lfo 1 clock-div
midi.sendControlChange(PORT_1, 1, 52, 3)
-- 3
end
So actually the control is to be split in two ?
Changing from sync to non-sync uses the last significant bit of the CC, and the values themselves use all other bits of the same CC? That’s indeed a first!
Glad you found it.
And I agee with you: the E1 is the only controller so far that can deal with all these creative quirks instrument makers seem to enjoy.