Patch Parsing suddenly stops after editing a preset in other area's

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.

What is causing this and how to prevent it?

EDIT :
to make matters even more complicated: I just reinstalled V5 on the Mk2 , and it parses again.

Then I reinstalled V4 , and that one in turn now parses !!!

Could there be another element causing this? Can it be a preset is being loaded correctly into the Mk2 for all its functionality, except for parsing?

In any case, I can go one wiht the perset tweaking.

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.

thanks @martin

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

And now V5 stopped parsing again…

@Martin,

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.

1 Like