Firmware / Web editor beta testing

[jhh]

@martin

Yup, I know. I am about to add it but I have need to understand it a little bit more. It is quite easy to overwrite the visible display value (ie. what you see on the screen). But how about the underlying midi value? I assume you will still use it for the communication with the Ableton, right? And will the, eg. fader value bar, be set correctly? Or do you need a relative control where the fader does not maintain its internal value and just sends increments/decrements to the Ableton?

The following ONLY applies to faders. (For other controls there is no need to change the value displayed)

What I need is essentially two things

1. The same behaviour of faders as they behave now, except for only one thing: not showing the actual value string. Apart from that they should behave as before.The MIDI min - max values define the range of values sent out when turning the knob. The VALUE min - max range on the other hand influence the way the coloured bar is displayed (e.g. going left or right from center in case if a PAN control that ranges from -50 to 50, or going from left to right if the range is 0 to 10). Incoming MIDI CC values set the current value of the MIDI CC AND adjust the displayed bar. Perhaps no underlying change is even necessary, because it essentially is equivalent to setting the LUA formatter for the control to a function that always returns the empty string

function formatEmpty (valueObject, value)
  return ("")
end

and making sure the E1 just ignores the output of the LUA formatter if it returns an empty string (to prevent any timing issues where the LUA formatter would execute after the value string is received and displayed).

2. A SysEx function that sends the value of a control as a string, to be written at the exact location where otherwise the LUA formatter would output its string. Now there are two choices in terms of addressing the control: either using the control “id”, but for me it would be easiest if the control could be addressed using the MIDI channel and CC. The SysEx could look like

0xF0 0x00 0x21 0x45 channel cc valuestring 0xF7

with

• channel: the MIDI channel the control is assigned to
• cc: the CC parameter the control is assigned to
• valuestring: the ASCII value string to display (zero terminated?)

Using MIDI channel and CC to address the control to send the value string to makes mapping consistent by default, but even better: it makes it easier to deal with ADSR style controls (where the value should only be shown when the ADSR details page is shown, and anyway the controls within an ADSR do not have their own id but do have a specific CC assigned)

[NewIgnis]

Testing the latest version.

• After the firmware update, the web app keeps saying there is a new firmware availabe. And indeed the E1 sticks to the 3.0-a.13 version. So the update fails without telling so.

• I used to make characteristics like the name, color and the overlay list being inherited between NRPN and SysEx controls by copying and pasting the one control on top of the other, but in FW3 this doesn’t work yet.

[NewIgnis]

Further testing

• I’m still stuck on beta a.13. The E1 won’t upgrade to a.14. Reason unknown

• In preset Electra One App I have implemented my simplified NRPN transmission (no RPN messages). This works, except when double clicking to go to the default value. The display goes to the configured default value, but the value transmitted is a different, more random one, and seems to correspond sometimes (not always) to the location on the display where I double clicked. Try out the pan controllers on page 1 for replication.

• Quite often, the preset freezes when changing pages via the lower right button. Can’t reproduce. (in the log viewer: after the “Pmap”, the “Page switched” message does not appear)
  

• As for esthetics I like this possibility to set wide or small faders as in the example below. Unfortunately they both appear as small faders on the E1 itself.
  

• During the progamming of the preset, at a certain point both the 1 and Google Chrome became unresponsive, and had to restart everything.

• During the programming a synth, the preenFM2, is begin connected via USB to the PC. When I start the E1 web site first, the PreenfM2’s USB port gets taken by the E1 website, although it doesn’t do anything with it. As a consequence I can’t access the PreenFM2 anymore via MIDI-Ox, because it’s already claimed by the E1. This forces me to then stop the E1 webstie, stop and restart MIDI-Ox, establish the necessary connections with the PreenFM2 via MIDI-Ox, and only then start the E1 website again. Needless to say a lot of time gets lost when eventually the E1 freezes, and you need to respect the correct order of restarting everything.

[martin]

@NewIgnis

I’m still stuck on beta a.13. The E1 won’t upgrade to a.14. Reason unknown

That was my mistake. a.14 got available before it was actually finished. It is fixed now. You should be able to update to the proper a.14 now. The web updater has been improved too. I tested that throughfully on both Mac and Windows. I am getting pretty stable updates.

@NewIgnis

Quite often, the preset freezes when changing pages via the lower right button. Can’t reproduce. (in the log viewer: after the “Pmap”, the “Page switched” message does not appear)

I cannot reproduce that yet. I made a few adjustments, please retest it in your environment. I tested that on both Mac and Windows too, with constant traffic at 500bpm from the Ableton.

@NewIgnis

As for esthetics I like this possibility to set wide or small faders as in the example below. Unfortunately they both appear as small faders on the E1 itself.

The general idea is that 3.0 brings possibility to have control type “variants”. The variants will provide more visual representations of the same type of control, eg. it will be possible to display fader as narrow fader, wide fader, but also a round knob, etc.

@NewIgnis

During the progamming of the preset, at a certain point both the 1 and Google Chrome became unresponsive, and had to restart everything.

To replicate that I have built a preset for Twisted Electrons MegaFM, using Chrome on Windows 10. Unfortunately I did not have any problems. I really do think there must be something special in your setup.

@NewIgnis

During the programming a synth, the preenFM2, is begin connected via USB to the PC. When I start the E1 web site first, the PreenfM2’s USB port gets taken by the E1 website, although it doesn’t do anything with it. As a consequence I can’t access the PreenFM2 anymore via MIDI-Ox, because it’s already claimed by the E1. This forces me to then stop the E1 webstie, stop and restart MIDI-Ox, establish the necessary connections with the PreenFM2 via MIDI-Ox, and only then start the E1 website again. Needless to say a lot of time gets lost when eventually the E1 freezes, and you need to respect the correct order of restarting everything.

hmm, the only explanation is that PreenFM2 uses the same MIDI port names as Electra One. Have you tried to change the ports in the Controller::Update firmware?

[martin]

anyways v3.0-a.14 is on beta.

It is basically another round of fixes and improvements:

1. memory requirements of presets lowered.
2. Preset name / Page are displayed using the white font
3. reset to the default value with the double click improved.
4. Add an option to format the internal SD card
5. Do not send duplicate MIDI values. Send MIDI only when there is a change.
6. Tweak the visuals

[oldgearguy]

I can never seem to easily find something via search or looking through the documentation …

Is the sysex message size limit still 256 bytes (receive and send) as of the latest beta?

thanks

[oldgearguy]

I found in the docs where it says the receive buffer is currently set to 256 although the underlying system calls have no real limitation.

So I guess the expectation is that eventually we’ll either get access to the lower-level calls and manage the buffers ourselves or will there be an added parameter to the send/receive sysex calls to specify a max buffer size, or will it all “just work” transparently behind the scenes for us?

[NewIgnis]

I’m of the same opinion, that would solve a lot of challenges I’m currently having, especially with the more complex synths.

[oldgearguy]

Yes - there’s a few templates that are great in that they let you edit a device, but they cannot currently pull back the current configuration, so in some ways, you’re editing blind when you make a change.

The evolution of the Electra One has made supporting a lot of different music devices worlds easier than any other controller platform I’ve worked with so far. Larger I/O system exclusive buffers would be the last* piece of the puzzle.

* I reserve the right to ask for more stuff after that. lol

[martin]

it goes like this:

when sysex message is handled with Request / Response parser, it will just work transparently. That part is completed in beta version already. The missing bit is the exchange of long messages with the MIDI learn.

I just tested it with:

[
  {
    "request": [],
    "responses": [
      {
        "header": [
          "43",
          "00",
          "09"
        ],
        "rules": [
          {
            "parameterNumber": 1,
            "type": "cc7",
            "byte": 4093,
            "bitWidth": 7,
            "byteBitPosition": 0,
            "parameterBitPosition": 0
          }
        ]
      }
    ]
  }
]

resulting in

8068708 processGeneralSysex: manufacturer 43
8068710 Midi::processSysex: matched response: responseId=0
8068710 ParameterMap::setValue: deviceId=1, type=1, parameterNumber=1, midiValue=0, origin=1
8068730 Midi::applyRulesValues: applying extraction rule: byte=4093, byteValue=86, extractedValue=86 to parameterNumber=1, type=cc7 resulting in parameterValue=86

So it parsed the 4093th byte just fine.

In Lua script the peak() function should reach any byte within the sysEx message too. I am considering adding buffered reads. That would speed processing.

I am partly back to working on the firmware again, for about a week now. I will make the latest version available soon.

[oldgearguy]

Ever see this before?
This E1 has been acting weird ever since the a.14 update

[NewIgnis]

I seem to recognize this from other projects. The Electra is probably fully functional, isn’t it? So it’s like the addressing of the memory where the fonts are to be found that is empty or contains invalid data. Or are other phenomena present as well? Are the colors correct?

Is reloading the firmware any help?

[martin]

Hi @oldgearguy,

do the following. Pls note, it works on beta firmware only:

1. Make sure you have the latest beta firmware (at least v3.0.-a.14)
2. disconnect electra
3. connect electra to the USB port
4. press and hold the left-middle button when the boot up animation is active (this will format the internal SD card). The button must be pressed when the animation is in progress and it needs to be held down until the animation is completed.
5. disconnect and connect electra again
6. send enclosed sysex file to Electra Controller CTRL port (
   uitoolkit-1.0.0.syx.zip (206.7 KB))
7. disconnect and connect electra again

if you have done everything correctly, Electra should start up with all graphics assets recovered,

[oldgearguy]

Thank you. Yes, now the graphics/text are restored and it properly goes through the boot sequence.

The remaining problem is actually the first problem I had – the E1 knobs do not change the values. I can press/hold on a screen control, the large slider appears and I can adjust the value that way, but the knobs do nothing.

[martin]

please downgrade to 2.2 (the firmware is available on the website). Let me know if the knobs work with the stable version of the firmware. Thanks!

[oldgearguy]

yes - 2.2 behaves as normal.

Please note - the other Electra One here has also been running the latest 3 beta and has been perfectly stable while I have been editing and using various templates.

[martin]

ok, I will review this on beta.

There is another user who is experiencing similar issue. We have a conf call later today. I hope it will help me to understands what is happening there. I will share info on that / fix as soon as I know more. Thanks for reporting!

[oldgearguy]

Attached is the Console app info for this controller. I tried reloading 3.0 a14 and same issue - knobs not working. I have/had the Alesis Micron Beta template and the Oberheim Cyclone (edited) templates as presets 1 and 6

[oldgearguy]

Here is the working hw unit info. Same 2 presets loaded in slots 1 and 8, although in the “right middle button” preset list, neither are showing up there (I do see them in the web beta controller management page)

[oldgearguy]

So is the web beta editor really broken or is it just my configuration?
I tried using an Electra One on 3.0 a14 and connected to beta.electra.one and the entire left panel is all messed up.

This was from Chrome on a Windows 10 box. All previous edits have been done from Chrome on a Mac Mini.