Just to make sure I understand, as an example:
midi.sendSysex (devPort , { 0x3E, 0x13, 0x00, 0x00, 0x01, 0x00})
doesn’t return patch B001?
Another small bug. It seems that the LINK AMP EG control does not reset to its default state when a new patch is parsed - perhaps because it is not a blofeld parameter. I think it would make sense for it to reset, but defer to your judgment.
1 Like
Indeed, it’s like the Blofeld does not understand that command.
Just a guess, but could it be that
Note that the checksum is omitted here
refers to the table and not the actual sysex command? Notice that line 7 is omitted from the table. Like I said, just a guess. Good luck!
I tried, with ox00 and ox7F as checksum, but no luck. It’s difficult to decide on a checksum when there is no payload to calculate it on.
Found this info that might be useful - especially the python script for blofeld checksum
https://www.kvraudio.com/forum/viewtopic.php?t=616898&start=285
EDIT: On reflection its not so useful. We already know this info.
But I see what you mean. For an sound request message there is no data to checksum, which is probably why they exclude it.
It’s even more puzzling. There is a beta editor for the Blofeld (Bigglesworth it’s called) on Win. It does allow for dump requesting from the RAM of the Blofeld. And the Blofeld responds to it.
So I thought if I compare both requests (mine and theirs) I’ll know what is wrong…
Requesting C 007 for instance:
Here’s mine (Blofeld does not react):
F0 3E 13 7F 00 02 06 7F F7
And here is the one from Bigglesworth to which Blofeld does respond:
F0 3E 13 7F 00 02 06 7F F7
And below the (expected) answer, but only given to the second request.
F0 3E 13 00 10 02 06 01 34 40 3A 42 60 00 00 01 7F 00 40 00 00 00 00 00 40 40 49 42 60 00 00 04 00 00 40 00 00 00 00 00 34 4C 40 42 60 00 00 01 7F 00 40 00 00 00 00 00 00 00 77 00 01 02 01 00 1E 20 00 00 40 40 41 7F 42 7F 00 00 40 00 00 7F 00 00 00 00 01 31 40 00 5B 00 00 40 40 65 51 59 06 6A 00 00 40 00 4D 00 01 31 40 00 5B 00 40 40 40 65 51 59 06 6A 00 00 40 00 4D 00 00 03 00 00 10 6A 00 40 00 00 00 03 37 16 37 40 00 40 40 40 40 40 40 40 40 40 40 08 33 40 40 40 40 40 40 40 40 40 40 40 40 40 40 00 00 00 00 00 00 00 40 00 00 40 00 00 00 00 00 00 00 00 40 00 00 40 00 00 00 00 00 00 00 00 40 00 00 40 01 00 40 00 00 7F 3B 23 59 57 4F 00 00 00 40 00 18 00 00 7F 7F 40 17 00 00 00 40 00 00 40 00 7F 40 40 00 00 00 00 40 00 40 40 40 7F 40 40 40 00 00 01 00 00 00 40 00 00 00 40 00 00 00 40 00 00 00 40 05 14 65 00 14 67 00 00 40 00 05 41 00 00 40 00 00 40 00 00 40 00 00 40 00 19 08 00 14 08 00 03 5B 00 00 40 00 00 40 00 00 40 00 00 40 00 00 40 10 00 00 00 0F 07 07 00 02 02 01 00 00 01 0F 00 00 37 54 04 04 04 34 04 04 04 04 04 04 04 04 04 04 04 44 47 44 47 44 47 44 47 44 47 44 47 44 47 44 47 44 00 00 00 4A 75 6E 6F 20 53 6F 75 6C 20 20 20 20 20 44 4B 0B 00 00 00 5D F7
I can’t wrap my head around this one 
If you want to try this for yourself, then uncomment line 462 in lua. It contains the command described above on program change.
PS :
- the EG link is now discoupled when you change a preset on the Blofed (line 463 in lua)
- issue with ill represented EG should be solved as well. To make ‘reading’ the chosen env mode faster, I’m now showing the standard ADSR mode with a graph, while using the names (like ALDSDSR) for all other modes. My brain interpretes that faster.
1 Like
This is what I see in the lua output after uncommenting that line
08:01:09.648 lua: bankNum : 1.0
08:01:09.653 lua: progNum : 6.0
08:01:09.654 lua: selecting patch: Bank = 1, Prog = 6
08:01:13.331 lua: #
08:01:13.335 lua: sysex message received on interface= 0 with a length of 392.0
08:01:13.336 lua: peek = 1 value =240.0
08:01:13.338 lua: peek = 2 value =62.0
08:01:13.339 lua: peek = 3 value =19.0
08:01:13.340 lua: peek = 4 value =0.0
08:01:13.341 lua: peek = 5 value =16.0
08:01:13.342 lua: peek = 6 value =127.0
08:01:13.343 lua: init dump
08:01:13.344 lua: start dump
Is this expected? I’m guessing the fourth line is not.
Hi, thx for trying.
Peek = 6 equals 127 or 7F. That seems to suggest you uncommented the ‘buffer memory’ request line, not the line requesting a specific bankNum and ProgNum. If you miss that line (2 adjacent commented lines, very similar), then download the last version again
Yes, I was not using your latest version. Here is what I get now when selecting B007
09:20:40.944 lua: bankNum : 1.0
09:20:40.948 lua: progNum : 6.0
09:20:40.949 lua: selecting patch: Bank = 1, Prog = 6
B007 loads on Blofeld but is not parsed to E1 (there is no activity on MIDI 1 IN)
Well, mystery not yet resolved then…
@Newlgnis I should have added that even though the patch didn’t parse via the Patch Select control, it did via the top right button on the E1. A second best outcome, but still better than none.
Yes , that is as designed: the upper rigfht button should always allow to retrieve what is in buffer memory. So in case you change the patch on the Blofeld without saving, those changes will not reflect on the E1, until you press that upper right button…
I used the preset for testing today. It really looks good.
There’s one thing I would like to mention and I could not get my head around. When I request the current patch. It does it but there is also an error showing up in the logger:
16:36:44.666 lua: bankNum : 2.0
16:36:44.675 lua: progNum : 19.0
16:36:44.677 lua: selecting patch: Bank = 2, Prog = 19
16:36:45.765 lua: #
16:36:45.773 lua: sysex message received on interface= 2 with a length of 392.0
16:36:45.775 lua: peek = 1 value =240.0
16:36:45.777 lua: peek = 2 value =62.0
16:36:45.778 lua: peek = 3 value =19.0
16:36:45.780 lua: peek = 4 value =0.0
16:36:45.781 lua: peek = 5 value =16.0
16:36:45.782 lua: peek = 6 value =127.0
16:36:45.784 lua: peek = 7 value =0.0
16:36:45.785 lua: init dump
16:36:45.786 lua: start dump
16:36:45.788 error running function 'onSysex': ctrlv2/slots/b00/p00/main.lua:341: attempt to index a nil value (local 'valueObject')
which is a result of of the showEnv call in the sysex callback:
function midi.onSysex(midiInput, sysexBlock)
print("","sysex message received on interface= " .. midiInput.interface.." with a length of "..sysexBlock:getLength())
for i = 1,7 do
print ("peek = "..i.." value ="..sysexBlock:peek(i) )
end
if sysexBlock:peek(1) == 0xF0 and sysexBlock:peek(2) == 0x3E and sysexBlock:peek(3) == 0x13 and sysexBlock:getLength() == 392
and sysexBlock:peek(4) == 0x00 and sysexBlock:peek(5) == 0x10
then -- current patch dump - - -
print("init dump")
--for i=1,900000 do end
print("start dump")
showEnv(ValueObject,parameterMap.get (deviceId, PT_SYSEX, 4027),0)
showEnv(ValueObject,parameterMap.get (deviceId, PT_SYSEX, 4033),1)
showEnv(ValueObject,parameterMap.get (deviceId, PT_SYSEX, 4039),2)
showEnv(ValueObject,parameterMap.get (deviceId, PT_SYSEX, 4045),3)
for i = 0,11 do
hideMod(ValueObject,parameterMap.get (deviceId, PT_SYSEX, 7001+i*3),7001+i*3)
end
for i = 0,3 do
hideMod(ValueObject,parameterMap.get (deviceId, PT_SYSEX, 8001+i*3),8001+i*3)
end
setFx(ValueObject,parameterMap.get (deviceId, PT_SYSEX, 6001),1)
setFx(ValueObject,parameterMap.get (deviceId, PT_SYSEX, 6013),2)
end
end
the ValueObject is neither a global or local variable, and thus it results in the error. Message is parsed and all but part of the functionality (showEnv and others) is not executed.
Thanks, I’ll check it
Thanks for looking into it, Martin: that all superfluous code from old times. I’ve disabled it, and will remove it after some thorough testing.