Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

V0.3.x Firmware Workout: Better late than never



Re. Quick saves. What @NeilParfitt said is exactly my workflow.


+1 here!


Ah! I did it again, but I now I know why: It’s an aligninment of the planets moment, and the conditions and speed have to be just right:

So, lets say I have this massive thing (or anything sitting in the copy/paste clipboard), If then add any unit in a chain and for whatever reason change my mind and press S2 to delete, then S1 for ‘yes’… If I slightly fumble the press, it’s triggering paste which populates that same S1 after the delete process is complete.


Having the ER 301 as a core of my system, both in the studio and live i also would love a mutch bigger amount of quicksave slots!


Re. slots, I totally agree, why not an open file system like everything else :slight_smile:


perhaps mentioned already _ naming a quick save “harmonic_distortion” it saves ok, but fails to reload. Editing the name back to “harmonic” means it’ll load.


is it the underscore?


Or just the length of the word (with the underscore turning two words into one)…


Something tells me that you are talking about renaming files and not renaming quicksave slots…is that true?


nope talking about quicksaves

    1. design a a new chain
    1. quicksave to a new slot, name it “harmonic_distortion” & save
    1. clear chain
    1. try to restore quicksave, fails
    1. bring up quicksaves and delete “_distortion” then save
    1. reload quick - and it works


This is exactly what I did when I attempted to reproduce your issue. It worked however. When you say it “fails”, what exactly is the mode of failure? Error message? Nothing happens?

BTW, doesn’t such a long name spill over into neighboring slots making it hard to read? The reason why I bring this is up is that with a name that spills over like this it might be easy to be confused about what slot is highlighted when you press load…


Instead of an underscore, a space would look like this:


Just trying to wrap my head around what is going on over on your end. :sweat_smile:


It says it loaded, and then I see “/Out” in the little screen. The chain is empty still though. Renaming the Quicksave results in a proper load.

These names are silly of mine anyway and I’m resorting to abbreviations, easy work around but I wanted to report it anyway. Space is definitely the way. Underscore is old OS naming days/muscle memory.


maybe non-alphanumeric characters (other than space) should be illegal in the naming entry?


I didn’t bring this up for that reason, more to confirm that you have the correct slot selected when you press load. Can you confirm that for me? The selected slot has the darker border and the bouncing arrow is pointing at it. The shaded slot is the last slot loaded or saved.


The names of the slots are not used for filenames. These are just metadata kept in a separate file entirely. In fact the names are used for graphical purposes only and not anywhere else. Slots are referred to by their numbers…very confused over here! :thinking:


Yes, correct slot selected when pressing load. I gotta rest now but will dig a little further tomorrow. And try to get a video capture of the behavior.


what if the roles of screens were reversed for quick saves?

-vertically skimming through names on the small screen (each patch name listed could populate a row with I’m guessing up to 20 characters)
-large screen could update with all relevant quicksave info such as buffers, inputs used etc.

Definitely more real-estate to display all that patch data…


i like this one

  • m buttons for different pages of info?
  • on one of those pages: even rudimentary representation of patches?
  • navigating a patch map and then selecting a particular unit
    and a ‘jump to’ function could load the corresponding quicksave and directly navigate
    to that selected unit…

.this might not be the right thread for these ideas. but since Neils idea won’t endanger patching
consistencies this might be some kind of “adjacent possible”.

@odevices: great firmware! “Better, late, than never!”


I think there might be a bug with the Offset function.

I had a sample in the sample player but when I sampled it wasn’t tuned properly, so I adjusted the tuning within the sample player, so that it was tuned correctly. I added a copy of the sample player to the patch to get a richer phasing/detuned sound and then added another to tune a fifth up. Then I thought that adding an offset to my incoming 1v Oct signal would be a better way of getting in the sample playback in to the correct tuning than just adjusting it within the sample player. That way semitone, cent, octave offsets would all be easier to read and set. So within the sample players 1v/oct input, I added an offset after the input (with an offset of +0.323). However it seemed to add noise to the DC 1/v signal and caused the tuning to wildly fluctuate and misbehave, particularly as I played up the keyboard.


Hello and thank you for the report. Before replying, I started up a Sample Player with a recording of a reference 440Hz sine tone and played around with adding an Offset unit inside the V/oct control. It all worked as expected. On the other hand, there are a couple of possible misconceptions in your bug report that I would like to address now:

  • For the ABCD inputs, the input voltage of -10.24V to 10.24V is mapped to the internal range of -1 to 1. So, an offset of 0.323 is like adding 3969 cents (10.24V * 0.323 * 1200 cents/V). So you tuned up almost 4 octaves (*). :scream:
  • Setting the V/oct parameter in the Sample Player is doing exactly what you want already. It offsets the incoming V/oct signal by the amount shown in cents. I’m guessing that you were trying to offset by a perfect fifth, so just set the V/oct parameter to +700 cents.
  • If you still want to do the tuning with an Offset unit then the correct offset for a perfect fifth would be +0.057 ( = 700/1200/10.24).

(*) Edit: Oops. Made an error: 3969 cents is not almost 4 octaves, it is more like 3.3 octaves. Sorry!