V4.0 testing [was V3.7]

Amazing update. Unfortunately no time to test atm, engineering studies are eating up all my time and energy. But this is pretty much everything I could wish for in an update. Amazing with devs that listens and truly cares for their userbase. I’m so glad I invested in this product.

1 Like

I am able to reproduce the issue with your script. I am going to take a look at it.

2 Likes

Unfortunately, implementing v3.7 on mk1 is possible only at the expense of using more memory. Doing so would make it impossible to load existing larger preset that work ok on v3.6. I do not want to do that.

1 Like

That makes sense although would there be the option for mk1 users to install it at our discretion? Or is it not directly compatible?

firmware-v3.7.0e.srec.zip (1.6 MB)
fixes the issue (at least on my E1 :slight_smile: ) Please confirm that it works ok for you too. Thx!

2 Likes

@jhh, I am going to work on your list now.

1 Like

Hi @martin - I’ve tested both the dummy script and my full preset, and looks like the problem has indeed been resolved, thanks very much. :tada:

fyi - I am seeing these CRITICAL - level log messages each time E-1 receives a sysex Control update command:

17:59:36.092 udateControl: controlId: 2, name=Cutoff
17:59:36.100 udateControl: controlId: 3, name=Resonance
17:59:36.102 udateControl: controlId: 4, name=Drive

Are these debugging log statements in the new firmware? They make my lua script logging more difficult to read in amongst these repeated log lines.

Thanks for the new beta! Is anyone else getting a bug where after accessing the MIDI routing page on the device, most of the text on the page and all subsequent pages accessed disappears until power cycling? I just tried a wiping the drive and reloading everything and I’m still having this happen. I haven’t noticed any other side effects so far. Thanks!

1 Like

An updated version
firmware-v3.7.0f.srec.zip (1.6 MB)

Done. The default follows the config of v3.6 and older versions

the value labels overrides are now applied immediately.

for dial/knob controls, a whitespace splits the text into lines

I will adjust the docs. The first value id is 0 for envelopes too.

I need to think about it. There has been a separate thread openned for that discussion. Some ideas are already mentioned there.

At this moment it seems to be very hard to do. For now, I stay away from making a firm decision on that.

Important:

The v3.7.0f comes with several adjustments of the configuration JSON schema:

  1. The hardware buttons are now defined as object properties instead of array entries.
  2. The router supports routes to and from the API systems, such as external MIDI Control and the Remote.
  3. Remote and external MIDI Control do not have the MIDI interface/port/channel properties any more. They rely on the router configuration.

All the example config files have been updated. Plus some new added:

MIDI Control router rule
Inbound Remote router rule
Outbound Remote router rule

Using the router rules for managing inbound and outbound Remote and MIDI control messages provides more flexibility and multiple sources/destinations.

Outbound Remote messages - when enabled the Electra One knobs send extra CC message that can be used record parameter automations, etc. At this moment absolute 7-bit CCs are supported.

1 Like

I will try to replicate and review. Thanks for reporting!

This is awesome. Makes envelopes so much more useful within the Ableton live script!

2 Likes

I tend to make my life easier during the development. I get rid of these before the production release :slight_smile:

1 Like

Found a Bug/unexpected behaviour. Not directly 3.7 related as it is already present in the previous Versions as well. But maybe worth a look.

I have three Controls: 1 VT “MidiCC”, 2 VT “MidiCH”, 3 CC “Midi”. The idea is to select CC and CH from Control 3 during runtime and use Control 3 to control the Value of choosen CC/Channel.

CC Works without Problems. But if i Change the Channel, there are no Midi MEssages send out, even if i see that the Message of the Control gets changed. As soon as i place another “dummy” Control configured lets say on CH5, it works if i select CH5 with MidiCH, but not on all other channels.

Means i need 16 Controls, one for each Midi Channel, on a hidden page so that my MidiCH works for all Channels. So it looks as midi Channels are only opened for Channels having a active Object on Start of the Preset.

Ah and tested Remote functionality with Absolute and Relative: Works like a Charm. Thanks a lot!

1 Like

I think there’s a regression in 3.7.0f that breaks my preset made for my REAPER control surface plugin. On the E1, I’m doing this to ensure that knob movement is always applied to control set #3:

function events.onPotTouch(potId, controlId, touched)
    PotTouched[potId+1] = touched

    local controlSet = pages.getActiveControlSet ()
    if controlSet == 1 or controlSet == 2 then
        pages.setActiveControlSet (3)
    end
end

When updating to v3.7.0f, this just stopped working requiring me to manually click on the third control set to enable it. Any idea why this is happening?

Knobs provide smoother readings

Thanks for the improved pot readout, it is working much better than v3.6.1/2. The maximum acceleration is a bit slow with the current version. It used to be very easy to get from min to max with a very quick but short movement. With v3.7.0f, this is very hard. I mostly hit the neighboring knobs with my fingers before reaching the end of the value range. Is that slower acceleration part of the fix?

On-screen controls can be mapped and adjusted using MIDI CC (absolute and relative)

Can we also change a control’s value range, name, value text or control type (button, fader, envelope, list) using MIDI messages?

I had troubles to replicate the issue first. It seemed to worked just fine. I found it eventually, it is related to the migration from the original config format and the new one. It is fairly easy to fixed.

I will make the acceleration curve steeper to see how it works.

the 3.7 brings a bigger change in how the internal commands are processed (I think we talked about that at the Superbooth). There is now a central event processor and all the IO / API simply inserts a message to the event processor queue. This means that virtually anything that can be done with Lua or UI, can be also done using the MIDI messaging. That means, that adding new MIDI messages to manipulate controls is easy now. But, as v3.7 grew big, I want to make sure it gets out soon without adding more features. I am happy to add new sysex api calls in v3.8.

1 Like

Makes absolutely sense!

Currently, some things are tricky to implement with the lua API, mainly changing a control type (e.g. from fader to list) and defining the value texts of a list control. Do you think this is something that could also be added for v3.8, preferably via the new MIDI protocol?

Some of the existing lua calls can be demanding for the E1, causing quite a delay between setting the values and finally having them applied in the UI. This happens esp. when changing a lot of parameter names, ranges or groups. Is this an area with potential future performance optimizations?

1 Like

@martin Did something change in the code for receiving sysex commands? Specifically the one allowing me to execute a lua function. Short commands (~80 bytes or so) work, eg.


But longer commands fail, eg.

Returns this error:

I.e. it complains about '}' expected near <eof>÷
Any idea what could cause this?

1 Like

It may be something in the way you receive/store the incoming data.
I’m handling sysex buffers of 500+ bytes with the 3.7 beta just fine.

1 Like

There has been changes… I will take a look at that. It might be something specific to that particular call.

Are presets pinned by default? When switching to the master preset the code lua code appears not to be (re)initialised again. I.e. I do not see a line like this in the debugger:

--- START ----
loadLuaModule: Lua extension file initialized: file=ctrlv2/slots/p061.lua
----- END -----

This is problematic, because the subscription to POT events is lost. Or should all initialisation now be done through preset.onLoad()? (assuming this is called every time the preset is switched to and become active).