We are a music band, we have a MIDI light writing on Ableton Live for each track, and we want to chain them quickly on stage, we do not want to load each track one after the other (the loading time is too long). So we open two Live sessions via the computer’s Terminal. But we have a problem with Beam.
Here is the whole process:
I open my first track on Ableton Live, I open beam, the light writing is read correctly. Everything works.
In the Terminal, I open a second session of Ableton Live. I load my second track.
My first track is finished. I go to the second track in the second Ableton Live session. There, my generic plug-in displays “disconnected”. I quit Beam. I open it again. It still does not connect. I quit the first session of Ableton Live. Only the second session remains. I quit Beam and open it again. There, generic connects. But there are reading errors in my light writing. Color errors in particular in relation to written automations, inconsistencies.
I tell myself that it is the use of the Terminal that is causing the problem. So I try to open Ableton Live via two separate applications. But the problem remains exactly the same.
I even tried to use two different Beam patches for the two tracks, with different midi assignment notes, so that they do not conflict, but that does not change anything.
Can you help me?
Maybe it is possible to reset Beam or generic so that there are no more reading errors on the second Ableton session… I don’t know what else to try.
Because of the way Beam integrates with Live (as a separate application through the Control Surface) running two Ableton Live apps at the same time is expected to not work and is not supported. The behavior you’re describing where Generic doesn’t connect to the second Live session is what I would expect, so the only supported way to switch between multiple Live instances is by first quitting the running one before launching a new instance.
That said, I’m curious about the color errors - just to understand where the problem comes from and see if there’s a bug that could also arise in other scenarios.
Yes, that is correct. Is there any way to avoid these bugs ? Because the important thing for me is to load an instance while another one is running, but I don’t mind to close it afterwards. If only beam could « reset » and avoid bugs when there only remains the second instance, it would be enough for me…
Is there a way ?
Thanks a lot for your time and help
Noemie
Hi Noemie, thanks for reaching out and for the detailed explanation of the issue! This sounds like quite a complex setup!
Since this isn’t a supported feature, I wouldn’t categorize it as a bug, but more as a feature request. That being said, I don’t think that we will add support for this workflow in the future. Needing to use the Terminal to open a second instance of Live suggests that it’s not an intended use case, and I wouldn’t recommend it due to the potential risks like increased load times, crashes, high RAM consumption, and other issues like audible pops, clicks, or unexpected behavior with hardware or other software.
In an ideal scenario, the entire performance would take place within a single Live Set. While this can require significant optimization—especially when the original production Live Sets contain many virtual instruments and effects—converting as much as possible into audio clips can help reduce CPU load. By keeping only the instruments and effects needed for live play and manipulation, it becomes easier to manage multiple songs within one Live Set.
I am of course assuming the reason for splitting your performance across multiple Live Sets comes down to CPU usage, so I’m curious to know if there are any other factors that led you to this workflow.