Hello,
at the beginning I thought only lists parameters with packed bits were buggy. Actually, all types of parameters are. Lists, faders and envelopes at least. I have two presets were retrieving parameters with a value of 0 is not working.
@martin don’t you mind to check them to see if there is something I’m doing wrong? Here they are:
Many thanks
I’m going to be a bit more specific, because both presets do not behave exactly the same.
JUNO 106:
faders are well retrieved even with 0 value, both for fader only response and patch change response
only the switches which are “packed” parameters with list type are not with 0 value
NOVATION BASS STATION:
all parameters for all types are not well retieved with 0 value
My two cents: this has something to do with empty bits.
Hello,
just to be sure, @martin what happened on the E1 when receiving empty bits in a response?
For instance, here is a LUA log of what is received by the E1 when switching the Chorus switch on the Juno 106:
10:21:57.500 lua: ----------------------------------- sysex message received: interface=0
10:21:57.506 lua: byte[1]= f0 >> 0.0 0 0 0 1 1 1 1
10:21:57.509 lua: byte[2]= 41 >> 1.0 0 0 0 0 0 1
10:21:57.510 lua: byte[3]= 32 >> 0.0 1 0 0 1 1
10:21:57.512 lua: byte[4]= 01 >> 1.0
10:21:57.513 lua: byte[5]= 10 >> 0.0 0 0 0 1
10:21:57.515 lua: byte[6]= 19 >> 1.0 0 0 1 1
10:21:57.516 lua: byte[7]= f7 >> 1.0 1 1 0 1 1 1 1
10:21:57.517 lua: ---------------------------------------------------------------------
When filling the empty bits by 0 in my LUA code, it looks like that:
10:25:14.658 lua: ----------------------------------- sysex message received: interface=0
10:25:14.664 lua: byte[1]= f0 >> 0.0 0 0 0 1 1 1 1
10:25:14.667 lua: byte[2]= 41 >> 1.0 0 0 0 0 0 1
10:25:14.669 lua: byte[3]= 32 >> 0.0 1 0 0 1 1 0
10:25:14.671 lua: byte[4]= 01 >> 1.0 0 0 0 0 0 0
10:25:14.673 lua: byte[5]= 10 >> 0.0 0 0 0 1 0 0
10:25:14.675 lua: byte[6]= 19 >> 1.0 0 0 1 1 0 0
10:25:14.677 lua: byte[7]= f7 >> 1.0 1 1 0 1 1 1 1
10:25:14.680 lua: ---------------------------------------------------------------------
I guess empty bits are not converted to 0 when received as a response, right? Would it be safe to make the E1 behaves like that?
Because the Juno 106 do not send all the bits for some parameters (I don’t know why) I suppose it is why the response is not understood by the mapping response recipe… That’s it?
I manage to bypass my issues by script, but it make the preset heavier for no reason. Nonetheless, I’m really happy to have succeeded, it makes me learn a lot. I’ll integrate it to the public Juno 106 preset later, since I want to clean and optimize my code.
Here is my LUA code to test sysex message received for those interested:
-- HELPERS ---------------------
midiInput = {
interface = MIDI_IO,
port = PORT_1
}
-- convert decimal to binary
local function toBits(num, bits)
-- returns a table of bits, LSB first.
local t={} -- will contain the bits
bits = bits or 7
while num>0 do
rest=math.fmod(num,2)
t[#t+1]=rest
num=math.floor((num-rest)/2)
end
for i = #t+1, bits do -- fill empty bits with 0
t[i] = 0
end
return t
end
function midi.onSysex (midiInput, sysexBlock)
print ("----------------------------------- sysex message received: interface=" .. midiInput.interface)
for i = 1, sysexBlock:getLength () do
local stByte = (string.format ("byte[%d]= %x", i, sysexBlock:peek (i))) -- "%d" is for decimal / "%x" is for hexadecimal
local bits = toBits(sysexBlock:peek (i))
local stBits = (table.concat(toBits(sysexBlock:peek (i)), ' ')) --print (table.concat(bits, ' '))
print ((stByte) .. " >> " .. (stBits))
end
print ("---------------------------------------------------------------------")
end
Hi,
I am sorry. It took me a little longer to respond. I was away from the computer recently.
The sysex bytes are received as 8-bit numbers. E1 passes the bytes to the sysexBlock without making any modifications to them.
I am still not sure I do 100% understand. If the issue is that you do not get the leading zeros (empty bits), I think the while num>0 might be the culprit. I modified your code a little bit. This prints all the bits:
function toBits(num, bits)
local t = {}
bits = bits or 7
for i = 0, (bits - 1) do
table.insert(t, (num >> i) & 1)
end
return t
end
function midi.onSysex(midiInput, sysexBlock)
print("----------------------------------- sysex message received: interface=" .. midiInput.interface)
for i = 1, sysexBlock:getLength() do
local byte = sysexBlock:peek(i)
local stByte = string.format("byte[%d]= %02x", i, byte)
local stBits = table.concat(toBits(byte, 8), " ")
print(stByte .. " >> " .. stBits)
end
end
output:
13:28:41.872 lua: ----------------------------------- sysex message received: interface=1
13:28:41.880 lua: byte[1]= f0 >> 0 0 0 0 1 1 1 1
13:28:41.883 lua: byte[2]= 41 >> 1 0 0 0 0 0 1 0
13:28:41.888 lua: byte[3]= 32 >> 0 1 0 0 1 1 0 0
13:28:41.895 lua: byte[4]= 01 >> 1 0 0 0 0 0 0 0
13:28:41.898 lua: byte[5]= 10 >> 0 0 0 0 1 0 0 0
13:28:41.900 lua: byte[6]= 19 >> 1 0 0 1 1 0 0 0
13:28:41.902 lua: byte[7]= f7 >> 1 1 1 0 1 1 1 1
Hello @martin ,
thanks for the reply. I have no issue with the code I put here, it was a code I did to debug what’s going on. Let’s try to be more precise on my description of my problem:
Example: (See Juno’s sysex chart here)
On the Juno we have 3 buttons for the CHORUS, they represent 3 states:
When I push the OFF button on the Juno, the E1 understand it, and change state of its Chorus control accordingly. Same for the Chorus type I button. But when pushing the Chorus type II (midi value 0), the E1 does not change its Chorus control state. That’s why I suspect the apparent empty bits…
I actually find a solution, but it’s a quite heavy script, I see it as a temporary problem’s bypassing. You may have a look at it in the last preset’s revision I’ve just published: Juno 160 2.31
To resume:
Many thanks, have a nice week end.
ok, got it and I see it in the code (firmware). Just fixed it. The v3.6 goes out tomorrow morning. This fix will be included.
Wow,
that’s awesome!!
For my knowledge, was it coming from the empty bits as I was thinking? Is old gear may behave like that?
So many thanks @martin.
By the way, that’s a wonderful piece of gear you did. I’m in love with my E1. It’s opening a universe of possibilities to me.
fix released as part of v3.6.0 earlier today.
Great!!
I confirm it’s fixing the problem. 