LUA frustration

[oldgearguy]

I’m clearly missing some fundamental aspects here.

What I’m trying to do is to get any LUA script that interacts with the E1 controller to work.
I can use the sandbox to upload a “Hello world” single line script that prints that message to the log file.

However, when I paste the Pot Touch script into the sandbox and upload it, I never see anything in the log file. I don’t see any messages indicating that the script is being fired. I do see in the log this information:

603891 setup: preset loaded: name=Alesis Micron
603895 loadLua debug output:
603895 ---- START ----
603895 loadLuaModule: Lua extension file initialized: file=ctrlv2/p006.lua
603895 ----- END -----

So what am I doing wrong/not doing? I could not find a basic “Step 1, Step 2, … Step n” tutorial that shows how to incorporate a LUA script into an existing preset. There’s the ‘edit LUA script’ button in the preset definition page, but it has the same effect - I can see “Hello” printed, but I never see any interaction w. the hardware.

Also - it appears I cannot run the Preset Editor App and the console app to see the debug output at the same time. One or the other will not see the connection to the hardware (since the port is already assigned I think).

[martin]

Hi Tom,

there are two ways to use Lua script on Electra:

1. The Lua extension
2. Standalone Lua

The Lua extension extends functionality of the JSON preset and allows you to manipulate controls, process midi, etc. The Lua extension is part of all firmware releases, eg. the latest v2.1.2. The documentation is available at: Preset Lua extension | Electra One Documentation. The examples are at https://github.com/martinpavlas/electra.one/tree/master/lua.

The Standalone Lua goes goes deeper. It provides API for low-level functionality such as interacting with the hardware. For the time being it is supposed to be very alpha. I am actually working on that part at present time. In order to run Standalone Lua, you need to run a special firmware.

I am pretty sure that for your work on the Micron preset you want to use the Lua Extension.

I checked the docs and I get your point, the difference between the two is not really pointed out there. I will fix it.

@oldgearguy

Also - it appears I cannot run the Preset Editor App and the console app to see the debug output at the same time. One or the other will not see the connection to the hardware (since the port is already assigned I think).

This is the Windows driver hassle. As a quick fix I will try add an option to edit / upload the Lua script to the Electra One console. That should make the work on Windows more convenient / possible.

[oldgearguy]

OK, I was reading the right pages. Here’s where I have a disconnect –
I can start a new preset, copy the Value-formatting LUA and EPR files into the sandbox and upload them to the E1.

This all works properly. I can see inside the EPR file where the calls are made to ‘Add %’, display Note values, etc.

I guess there is no way for now to attach LUA calls to a control inside the preset editor? I have to save my preset, un-minify it, then add calls as needed? If I’m just using stuff like ParameterMap.OnChange(), I can use the LUA script editor directly since it’s not tied to a particular control, correct?

[markus.schloesser]

If you have an iconnectivity midi interface (or an rme Audio interface), connect Electra to those. As both iconnectivity and rme (and probably others, but not that many) offer multi client midi drivers you circumvent that highlander problem.

[oldgearguy]

Thanks for the tips. I’ve been taking it slower trying to work smaller examples in a minimal preset so I can see the effect of the changes I am making more easily.

My other option was to code everything perfectly the first time so I wouldn’t need to look at the logs.

I’m getting a better flow for doing development and test, so hopefully in the next week or so, I should have what I need implemented.

[oldgearguy]

Using this topic to capture some lessons learned as I find them …

If you have the parameterMap.onChange() method defined in your LUA script, it “eats” all changes and even if you have a specific function defined for a particular control, that specific function will not get properly invoked.

I started with the onChange() method to implement some things, then decided it would be more efficient/cleaner if things were defined for a specific control.

So I commented out the parts in onChange() and created a new function to be invoked on a Pad press, but the log file never showed it being called. I saw some logging about sending a sysex message, but I wasn’t doing any sysex transmission.

What is the comment syntax for the LUA scripts? I thought it was --[[ commented out stuff --]]

It was only after deleting the entire onChange() code that the specific methods per control worked properly.

So you cannot have onChange() and specific functions in the same preset?

[martin]

I tried to replicate what you described.

I made a simple preset with one control that has a Lua function controlCallback() assigned:

The Lua extension script is like this:

function parameterMap.onChange(valueObjects, origin, midiValue)
    print (string.format ("a new midiValue %d from origin %d",
        midiValue, origin))

        for i, valueObject in ipairs (valueObjects) do
            local control = valueObject:getControl ()
            print (string.format ("affects control value %s.%s",
                control:getName (), valueObject:getId ()))
        end
end

function controlCallback(valueObject, value)
    local control = valueObject:getControl ()
            print (string.format ("callback called control value %s.%s",
                control:getName (), valueObject:getId ()))
end

When I twist the knob I get following output in the console:

39980875 lua: callback called control value CUTOFF.value
39980876 lua: a new midiValue 32 from origin 0
39980876 lua: affects control value CUTOFF.value
39980888 sendMessage: port=0, channel=1, type=cc7, parameterNumber=1, midiValue=32
39980955 lua: callback called control value CUTOFF.value
39980957 lua: a new midiValue 31 from origin 0
39980957 lua: affects control value CUTOFF.value
39980966 sendMessage: port=0, channel=1, type=cc7, parameterNumber=1, midiValue=31

ie. both functions (The control’s function controlCallback() and the parameterMap.onChange() called and the MIDI message sent out (verified in the MidiMonitor application).

if I comment out the parameterMap.onChange() like this:

--[[
function parameterMap.onChange(valueObjects, origin, midiValue)
    print (string.format ("a new midiValue %d from origin %d",
        midiValue, origin))

        for i, valueObject in ipairs (valueObjects) do
            local control = valueObject:getControl ()
            print (string.format ("affects control value %s.%s",
                control:getName (), valueObject:getId ()))
        end
end
--]]

function controlCallback(valueObject, value)
    local control = valueObject:getControl ()
            print (string.format ("callback called control value %s.%s",
                control:getName (), valueObject:getId ()))
end

Then the callbackFunction() is called and the MIDI message sent out:

40157752 lua: callback called control value CUTOFF.value
40157752 sendMessage: port=0, channel=1, type=cc7, parameterNumber=1, midiValue=12
40157781 lua: callback called control value CUTOFF.value
40157781 sendMessage: port=0, channel=1, type=cc7, parameterNumber=1, midiValue=13
40157820 lua: callback called control value CUTOFF.value
40157821 sendMessage: port=0, channel=1, type=cc7, parameterNumber=1, midiValue=14

I feel I am doing probably something different than you do. Pls let me know where the difference is. Thanks!

[oldgearguy]

Martin - I tried to pull up an old version that had the issues and so far I cannot recreate the original problem I was having. It easily could have been a simple typo/incorrect syntax that caused the script to not run.

So at this point I think the real answer is - yes, both can exist and work properly if you code it correctly.

lol

[studiobischof]

Hi @Martin,

maybe you can help: I also cannot get live print messages from the electra console by the examples provided…

My Electra has HW 2.0, FW 2.1.3

First I tried your github lua examples… I pasted some into the sandbox (epr and lua) and uploaded them.

After restarting the electra the example “Hello world” prints something on the console, so lua works but should I get the “hello world” message without restarting on the hardware?

Then I tried the 01_simple_callback_function.epr with 01_simple_callback_function.lua and got nothing on the console.

I then tried your example from above in this chat… pasted the lua code into the “edit lua script”, added one fader control with ID 1 and function (LUA): controlCallback.

I get no prints either on the console:

I don’t know where to look at. Could it be that my other loaded presets and scripts on my electra can crush the lua function of the electra?

I also closed the editor and sandbox page in chrome, shut down Ableton and restarted macOS. Didn’t help.

Thanks for any hints.

[Flyweight]

I tried the example as well without getting anything printed.
Also I created a preset with 1 knop with writeToLog assigned to it:

function writeToLog (valueObject, value)
print ("writeToLog function called so printing something")
end

Twisting the knop and nothing is printed in the console app.
The control itself spits out midi data.

[martin]

possibly the logger disabled? Just thinking out loud. I will try to test it tonight.

Sysex calls for Logger control

martinpavlas/electra.one/blob/master/sysex/system-logger-on.syx

[Flyweight]

I send

.\sendmidi.exe dev "Electra Controller" syx hex 00 21 45 7F 7D 01 00

Also send it to Port 3, and tried to fetch the current preset but no response from the Electra One.
It was working somehow but I am still learning Lua and got sometimes the line appearing from Lua that a particular function was called.

while listening on all 3 ports from the Electra One and I get no response and neither does the function work.

Nothing gets printed inside a function.

The sysex log messages when booting do appear on MIDIIN3 or in the console app.

[martin]

Would you run .\sendmidi.exe dev and post the output? Thx

[Flyweight]

> .\sendmidi.exe dev list
Electra Controller
MIDIOUT2 (Electra Controller)
MIDIOUT3 (Electra Controller)

> .\receivemidi.exe dev list
Electra Controller
MIDIIN2 (Electra Controller)
MIDIIN3 (Electra Controller)

Hi Martin sure here is the output.

[martin]

try following:

.\sendmidi.exe dev "(MIDIOUT3) Electra Controller" syx hex 00 21 45 7F 7D 01 01

the sysex command must be send to the CTRL port. Observe the Console app output when sending the message.

[Flyweight]

@martin

.\sendmidi.exe dev “(MIDIOUT3) Electra Controller” syx hex 00 21 45 7F 7D 01 01

Because I run Microbastard WinDos I am not able to use Sendmidi and the console app due to the midi driver being locked

I used:

.\sendmidi.exe dev "MIDIOUT3 (Electra Controller)" syx hex 00 21 45 7F 7D 01 01

And it did work. Simple function is printing again. Thanks a lot!I

[martin]

Just to have the story complete. The sysex call can be used to turn the logger on and off. The change is persistent - the last status of the logger is recalled on the startup.

The Electra’s startup messages are, however, always written to the log. That is to be able to see what is happening in case of problems with booting.

Having the logger off, saves a bit of CPU time and reduces unneeded traffic on the CTRL port. Which could possibly confuse midi learns in DAWs, etc.

[Flyweight]

Ah ok, I do wonder how it got turned of.
I never send the sysex messages before.
But good to know. Thanks for your help

[studiobischof]

Thanks for the clarification Martin! Messaging on the log works now