Ableton Live MIDI Remote Script / Control Surface

Is there a way to wipe the whole device and do a clean re-install? Maybe I should try with a clean build

Yeah, but that ACK you see getting received is the response to the select slot (5,1) sent just before.

Just to be sure, the name you set for E1_PORT_NAME is an exact match of the name of the port 1 as returned by executing the command sendmidi list?

I have 3 options when executing the command:

Screenshot 2024-06-19 at 14.13.16

I currently set it to: E1_PORT_NAME = 'Electra Controller Electra Port 1'

Can you run the command in the attached file? (It runs sendmidi, assuming you have it installed in /usr/local/bin) to send the Echo preset to the current slot on the E1.
sm.zip (3.7 KB)
Does that work and show the Echo preset on your device?

yes, it does show Echo on my display.

Iā€™ve just reinstalled all the files in the SD drive using this sd.zip:

Iā€™ve also reinstalled the Remote Script related files in the ctrlv2 folder.

Now the remote script works a bit better. M4L and plugins can be shown on the display. But it still sporadically hangs. Here are two examples:
crystaline.txt (607.1 KB)
granulator.txt (302.6 KB)

Do you happen to have a spare test device? I wonder if it would be helpful for you to encounter the same issue if you have a fresh install.

Not sure if itā€™s related, but after my re-install, now when I restart Ableton Live, and then press the top right button to show the device view, itā€™ll also show a black screen. In the log it shows:

2024-06-19T14:55:56.809678: info: RemoteScriptMessage: E1 (debug): === MixCont mixer MIDI map built.
2024-06-19T14:55:56.809707: info: RemoteScriptMessage: E1 (debug): == Main refresh state called.
2024-06-19T14:55:56.809734: info: RemoteScriptMessage: E1 (debug): === EffCont not refreshing state (no effect selected or visible).
2024-06-19T14:55:56.809777: info: RemoteScriptMessage: E1 (debug): === MixCont not refreshing state (mixer not visible).

Selecting another track will refresh the device view and the E1 display is then in sync with the appointed device.

Iā€™ll have a proper look this weekend. Regarding your last point, I already noticed in an earlier log you sent that apparently when you open Ableton or load the song there is no device initially selected (or at least, thatā€™s what the remote script thinks). Which means the screen will be black. Selecting a device (or a different track) brings the E1 in sync.

1 Like

Just had quick look at the crystalline log. It seems you have logging on the E1 on; this is really not necessary unless you want to debug - and may impact performance. Does it still sporadically hang if you set E1_LOGGING = -1 (and E1_LOGGING_PORT = 1)

@jhh thanks for taking a quick look! I changed the setting and the sporadic hang still happens. Have you tried to add a Granulator inside an instrument rack? This causes hangs when selecting the device or the rack at least 9 out of 10 times.

By the way, should I leave E1_LOGGING_PORT = 1? The default value seems to be 2. (Probably doesnā€™t matter if logging is disabled)

The log is attached:

excerpt.txt (35.1 KB)

I have no problems with a Granulator III inside an Instrument Rack (on E1 mkII, using sendmidi). Can you increase DEBUG to 5 and send the log again?

Here is the log starting briefly before selecting the rack containing granulator:

excerpt.txt (132.6 KB)

Thanks. I had a look and it seems to be the same problem as before: the remote script is waiting (until the timeout of 3 seconds) for an ACK after the upload. You are using sendmidi, and the preset for an instrument rack is short, so uploading this should be fast and never anything close to 3 seconds.

Is there anything else connected to your MIDI setup? Both externally (other devices) and in software running on your laptop (eg Chrome with the preset editor, or anything else)? If so, what happens if you disconnect everything else?

If that doesnā€™t make a difference, there are two options to proceed:

  1. send me the full Ableton Live set that triggers this bug, so I can see what happens on my setup. This is not likely to help to be honest, but worth a try.
  2. install Midi Monitor (snoize: MIDI Monitor) tell it to capture all MIDI (i.e. in ā€œSourcesā€ select ā€œMIDI sourcesā€ and ā€œSpy on output to destinationsā€, tell it to remember up to 10000 events and then try to trigger the bug. Save the captured events and send them to me, together with the remote script log file.

I removed all MIDI devices and the issue still there. E1 connects to the laptop through a hub (in order to convert to USB3 for my Mac M1 laptop)
select Granulator.zip (34.4 KB)

This is what I did:

  1. Select the Granulator track (which contains an Instrument Rack, with Granulator III inside)
  2. The instrument rack is automatically appointed and reflected on E1
  3. Select Granulator III inside the rack ->the device hangs

The device hangs when I select Granulator like in the screenshot.

In the Log.txt file, I can see that when I select Granulator III, the script actually consider the device an ā€œInstrument Rackā€, like this:

When I select the instrument rack, it shows

ā€œDevice InstrumentRack# selectedā€

There is a # sign appended to the name

You can see that itā€™s dumping different parameters from the previous screenshot for ā€œInstrumentRackā€, which is actually a Granulator:

In summary: When selecting Granulator device inside the instrument rack, the script considers it as an InstrumentRack.

Could it be possible that the hanging comes from mistaking Granulator III as InstrumentRack?

Here is the Log file:

excerpt.txt (253.3 KB)

Here is the ableton project:
test2-e1 Project.zip (64.8 KB)

Thanks for the detailed additional information.

Regarding your question about using the name InstrumentRack for the Granulator III: this is intended behaviour, see ElectraOne/README-ADDING-PRESETS.md at main Ā· xot/ElectraOne Ā· GitHub

In the log that you sent this time I see that when selecting the InstrumentRack itself, the preset is correctly and quickly uploaded to the E1 (in 0.1 second). (This is different from the previous log you sent where even uploading the InstrumentRack# preset took way to long.) But now uploading the Granulator III preset (with name InstrumentRack) takes to long (more than 3 seconds, the timeout). Iā€™ve tested your Live Set in my setup and at my side it consistently uploads between 0.4 and 0.8 seconds.

So there appears something is causing your E1 to quite randomly take a long time to upload presets. And I am really really sorry but I have no idea why. The only way to reliably test this if you could somehow swap your E1 with another and see if the issue persists. When resetting your E1 recently, did you also refresh/reflash the firmware? Maybe that could help?

I have installed/re-installed so many things Iā€™ve lost count what I did, but I just reinstalled the latest firmware and it seems to be much better now.

It hangs less than 10% of the time and I can fix it by selecting another device and then re-select the problematic device to get E1 show the parameters. I can live with this for now. Thanks for helping with the troubleshooting!

Glad to hear that it has improved, but still, it should not hang 10% of the time: using sendmidi, performance should be snappy.

Hi,

So strange happened here. Last week the script was working fine. This week I can see it maps the parameters but when I move the knobs they donā€™t move in the Ableton nor when I move then in Ableton they donā€™t move in the controller. That is pretty weird as I have not changed any configuration.

Hereā€™s the config:
config 2.py.zip (3.3 KB)

Here are the logs:
Log.txt.zip (1.1 MB)

And hereā€™s daw config:

Appreciate any help or tips on how to tackle this one.

**PS. Iā€™ve also noticed that the manual states to provide this variable (E1_PORT_NAME) in the config.py but there is also another one down below in config.py:

# Remote script input/output port number (0: Port 1, 1: Port 2, 2: CTRL)
E1_PORT = 1
# Name of this port as used by SENDMIDI_CMD
E1_PORT_NAME = 'Electra Controller Electra Port 2'

The MIDI settings in Ableton are wrong: you should connect the remote script to Port 1 for both input and output (this is the port over which values for parameters are sent and received).

The config file you sent also looks suspicious: it starts defining SENDMIDI_CMD which is further on redefined as SENDMIDI_CMD=None so sendmidi will not be used in your setup. Then it defines E1_CTRL_PORT which is deprecated.

Running the command sendmidi list returns the list of ports SendMidi knows about.

E1_PORT should be set to 0 (and Iā€™ve now removed that setting from config.py because it really should not be changed.)

P.S.: This should be set to
E1_PORT_NAME = 'Electra Controller Electra Port 1'

The idea was to use port 2 since I have midi template synths on port 1 and I did not want any midi data sent there when using Ableton script. I assume thatā€™s still possible? I checked the send midi list and provided the correct port name for port 2. Whatā€™s wrong with using that one? Or the script does work only on port 1?

Iā€™ve made the changes you suggested but the behavior is still the same.

Hereā€™s the config and logs:
config.py.zip (3.3 KB)

sendmidi:
image

logs:
Log 2.txt.zip (225.9 KB)

Edit: Nevermind. I got it working by deleting the dir and creating recreating it from scratch and resetting electra. Thanks fo the help.

@jhh if you donā€™t mind I have two more questions:

  1. If I have the script running on port 1 and I have a template to control the synth on port 1 if I switch from script to control the synth would the script still be sending some midi/control data? I just would like to avoid anything being sent towards the synth and rewriting the whole template for port is something Iā€™d like to avoid.

  2. Is there a way to have Ableton open to pin other templates and force Electra to not switch to control devices? For the context letā€™s have a soft synth that responds to midi cc etc. I would like to go to the channel and switch to the template on Electra to control it but with every movement inside the DAW that will force Electra to switch to the appointed device on the channel.