I’ve now had this experience already 3 times and it’s truely exhausting: a perfectly working preset with parsing implemented which is being improved visually (other graphics, colours, hiding ,renaming, formatting because of new possiblities in the new firmware, or because of the new memory headroom in Mk2) suddenly stops parsing, while no changes were done to the parsing itself, nor to the parameter map.
Right now I for instance have 3 versions of the same Blofeld:
V3 still parses but is four years old and outdated
V4 parsed when I made it public a coulple of week ago. But it doesn’t parse with me anymore
V5 parsed when I clone it . I continued improving it , and it also stopped parsing now.
So far , all I could do was go back revision by revision until I meet a version that still worked, and then figure out what changes were applied since and redo them.
So I’ll probably drown in versions and clones of versions with as a result no longer knowing where exactly I ended up on a moment. It brings a tedious and necessary bookkeeping with it. And this while all the while the risk of the parsing quitting on me, remains real.
I don’t need to mention this is really hampering progress.
I am finishing my work on the 4.1.3. It brings with numerous improvements specifically for Mini and a few fixes of the firmware in general.
What you describe seems to be identical with what @Grappa reported (PCM80, TX7). The initial review points to the patch request/dump system being affected by the saved changes to the Device settings (changing channel/ports on the mk2 hardware). The settings is correctly applied when the preset is transferred to the device but not picked up correctly (most likely Lua involved) after the device restart.
I cannot say now that your issue is 100% the same. It looks like that. I have the presets and the dump data from your earlier post. I will use these when working on it.
LAST UPDATE: since the V5 was working I just added a function “sourceARP” to control #181"
and added 2 new functions in lua:
function colorBlue(valueObject,value) ---- Set color according to value
local r = 82 local g = 157 local b = 236 local divide = 5 -- light blue color
if value == 0 then r = math.floor(r/divide) g = math.floor(g/divide) b = math.floor(b/divide) end
valueObject:getControl():setColor (r*65536+g*256+b)
end
function sourceARP(valueObject,value) ---- Darken controls according to value
local r = 82 local g = 157 local b = 236 local divide = 5 -- light blue color
if value == 0 then r = math.floor(r/divide) g = math.floor(g/divide) b = math.floor(b/divide) end
controls.get(147): setColor (r*65536+g*256+b) -- ARP overlap
for i = 182, 192 do
controls.get(i ): setColor (r*65536+g*256+b)
end
end
I’ve been changing the blofeld V5 preset without being able to test the parsing myself , knowing even that some controls were transmitting gibberish. However @kiwigrass tested it and it was okay !
This sheds a different light. The cause might thus be elsewhere, perhaps even electrical.
The issue may not lie in the preset itself or in the editor per se, but perhaps in the transport from the editor to the E1.
In my case, recently a lot of flickering is ongoing on my Mk2, like it suffers from some lack of current. It was still reactive so I didn’t think a lot of it. But perhaps it is causing issues during ta preset load. Curious though, the power adapter hasn’t changed in the last years. I get the flickering regardless when I connect the Mk2 via a power USB Hub (Elektron Overhub) or when it’s directly connected via USB B in the PC (he same one htat’s been there for 3 years).
Other observation which I have a long time already and may be related: every 1 in 10 approx transmissions to the E1 fail (the dots remain running), after whioch I need to restart the E1 and the Chrome browser.
How can I avoid the flickering and perhaps improve preset transmission?
I have had the transmission issue you describe in the past where the dots don’t go away and the only solution is to reboot browser and E1. But have not experienced that problem recently. For me, it was because I was running into memory constraints. My preset was too large because I had a lot of long option lists. If I recall correctly, lists use significantly more lines of JSON than an equivalent fader. Converting those lists to fader controls resolved that problem. FWIW.