Open Live Mixing System - Don't buy a mixer: do it instead

Community Ideas for Ardour
#12

This has been a passion of mine for many years.

I have never been able to solve this fundamental problem:

The user must purchase a computer I/O system with enough microphone preamps and enough monitor outputs to handle a reasonably sized band. And you have to spend a lot more if you want recall of the basic elements (mic gain, 48v) that you get with a live mixer.

What you often find is that a small digital mixer is the most practical way to get a lot of mic inputs and monitor outputs from your computer. So you’re now faced with carrying a perfectly serviceable live console around, just to support your virtualized one.

That said, there’s plenty of room to do something cool in the computer that complements the live mixer.

Harrison LiveTrax and Apple MainStage are 2 products that complement the digital mixer without trying to ‘be’ the mixer. And I see a lot of live rigs running Ableton Live for backing tracks and video playback.

-Ben

3 Likes
#13

nevermind me, I only just recalled that you want to run this headless.

(I thought due to the UI layout and dedicated direct i/o toggle mode)

1 Like
#14

You are absolutely right about budget mixers. OLMS is not a competitor for them; it’s an alternative to expensive, limited consoles.

Our focus is on three main advantages:

DSP Power: it uses standard x86-64 CPUs for unrestricted plugin scalability. This offers the best Performance-to-Cost.

Open Logic (GPL): The system’s Lua scripts are fully accessible, providing total customization and zero vendor lock-in for complex automations.

Stability: We use Linux PREEMPT_RT for hyper-optimized, low-latency performance essential for live use.

Let’s see if these will be enough…

#15

Using AI to vibe-spec and vibe-code is one thing, but copy-pasting AI in a conversation between humans is lame. Sorry if it’s not the case, but the AI smell is so strong in your last answer.

5 Likes
#16

Been trying to avoid being a naysayer, but I have to agree with Ben for the most part.

I am no stranger to both the budget end of mixers and the high end range of mixers in live sound, given my professional history and work. In general I love aspects of some things, and have no problem with using, say Mixbus, as a live mixer for myself, but I would eb hard pressed to say I can build a mixer of any size cheaper than the options already out there. Proprietary lockin isn’t so much an issue when dealing with any of these in my experience, it isn’t that it doesn’t exist, but rather that really you are buying the tool and use the tool, and when the tool dies you buy a new one. Yes it takes time to rebuild libraries of presets etc you may have used to move quickly, but that may bring me to my next point:

What has interested me more is controlling the mixers in a somewhat standard way. There are two aspects to this, one is using software similar to TheaterMix for instance, which can help manage aspects of live mixing consoles, including EQ, Dynamics, etc. that does an ‘ok’ job of allowing this to be transferred between consoles potentially (Haven’t tried the latter part of that, just the managing of it on a single console). The EQ etc. always sounds different between consoles, but like anything with presets these should be starting points only.

The second aspect is the reason some people decide to use things like Waves Soundgrid for processing, it allows you to use the same tools on any consoles. I don’t need or want a specific EQ for mixing live necessarily, but what DOES benefit me, is having presets I can pull up for any channel quickly and easily and know they will sound the same on any console. When you are running on shows quick this can save quite a lot of time, sadly I don’t think Soundgrid is there yet for this to truly apply, and while there are other options I haven’t spent a lot of time exploring this due to the requirement of dedicating a computer to it really.

Finally I just don’t know how you would make money in such a project to support yourself. There have been similar closed source projects along these lines before, Software Audio Mixer is one that for a while gained steam, but honestly it just never holds up.

Seablade

4 Likes
#17

@x42 do you think you should add this in the new coming release?

#18

This could also be achieved with a combination of PW, jackmix (or any other headless mixer) and carla. My idea was to get a pi, use the trio for the audio layer and control it from an open stage control interface via midi and OSC. Open stage control would also be able to implement the logic, like scene-safe, presets etc.

There are a lot of pitfalls in all this and I do not think it will be suitable for a big console replacement in professional venues, but as a creative mixer for dub mixing, electronic music livesets etc.

The software defined mixer kinda screams for an open source pendant. Something that allows the user to either make the best of their junk audio interface and singleboard computer collection or, thinking this further, a modular system, consisting of open source hardware and software. Open source interfaces for i/o, a software layer for routing and controls. Maybe even analogue insert effects system.
Open source hardware would also allow for a market of high end boutique producers to make money of this. Or just cheap mass market clones. They could coexist. Ok, getting of rails here a little. But I think @x-radios seems to be driven by a similar idea.

1 Like
#19

@GenGen I really appreciate the alternative suggestion using PipeWire, jackmix, and Carla! That is definitely a viable approach, especially for lighter setups like a Raspberry Pi.

For OLMS, I’m currently committing to Ardour Headless because:

Integrated Logic: Ardour provides native Lua scripting for complex session logic (like our proposed bank and scene management), which is safer and less complex than building custom logic with an external service.

OSC Protocol: Ardour offers robust, integrated OSC support right out of the box, reducing the need for middleware or translation layers.

Proving Ground: Ardour’s core engine is a proven, high-performance platform on Linux RT, giving us a stronger foundation for the professional-grade stability the project aims for.

I fully agree that this kind of software-defined mixer needs an open-source pendant! Thank you for the insightful feedback.

1 Like
#20

@baptiste ever use it for.language and technical barrier. Anyway it’s just an interpreter, I never copy and paste just because I have not time. I ever evaluate every single inbound and outbound sentences. My presence is 100% human and everything in this topic if ever double or triple filtered by my little human mind. Thank you for your open and sincere answer.

Francesco Nano

#21

Thank @seablade for your feedback. I appreciate

You are absolutely right about the cost-effectiveness and the challenges of sustaining a project like this.

At this point, OLMS is less of a serious business venture and more of a passion project and an open architecture experiment. The initial business idea largely dissolved when the extreme difficulty of achieving genuinely professional, ultra-low-latency / zero x-run performance was fully realized.

However, the architecture remains fascinating, and we can’t predict what new low-level APIs or hardware tools might emerge in the future that could pair perfectly with this software core.

So, why not keep building it? I’ll see where the journey takes me.

Cheers!
Francesco

#22

It is already possible in the current release.

It’s way to early too look into tech details; but if you want, there is…

Example Code

You can do this form the track’s point of view:

track = Session:route_by_name("Track 1") -- get Track 1
assert (track) -- ensure that the track exists
track:input():disconnect_all (nil) -- disconnect all its input ports 
track:input():audio(0):connect ("system:capture_10") -- connect first (here, 0 = left) input to the sound-card's 10th audio source.

or like JACK connect/disconnect, globally on engine level. e.g.

audioengine = Session:engine()
_, t = audioengine:get_ports (ARDOUR.DataType("AUDIO"), ARDOUR.PortList()) -- get a list of al Audio ports
for p in t[2]:iter() do  -- iterate over all  audio ports
  print (p:name())
  if p:name () == "Track 1/audio_in 1" then
     p:connect  ("system:capture_10")
  end
end

To test, you can urn both in Ardour Menu > Window > Scripting

–

PS. Loading partial state is somewhere on the ToDo list.
Ardour v9.0 includes a feature to set plugin/processor state, leaving everything else as-is.

2 Likes
#23

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

#24
#25

​Hi guys, I’m keep working hard on the audio engine startup process. It’s very difficult because I’m going di do it avoiding systemd and trying to do everything on a started and running machine.

The main challenge is we have 3 pieces which have to run together but with different privileges and starting users.

Asla, jack and ardour.

Very technical issues and solutions. In true I don’t know exactly everything. The main part is AI driven. I’m the ai chief. I’m like a music producer that feels music but isn’t able to explain musicians what to do because he’s not understanding music theory, chords, and so on…

I know what I want but I have no idea how to reach it. A lot of time is invested onto fails and bad ways… make, come back, try again.

Very bad developing practice, of course, but I had several refuse from professionals before trying by myself. Anyway, I’m playing and learning and I think I’m doing something good and valuable.

Some times things goes right, after 1 minute anything is working anymore.

Anyway… I’m at99% of a really important piece of this work: startup process running to start asla, jack and ardour all together in a very high performance high tuned machine.

This assure ardour will run in a real time kernel in the best way possibile to match live low latency mixing needs leveraging a standard PC that is my goal.

If anyone is interested enjoying my love developing olms chat you can find it here on telegram:

Here is the official website with got and every resource
(Do not look seriously at git for now… I’m going to reorganize file and fix translations and everything in a couple.of.days).
https://openlivemixingsystem.org

I’m going to keep working alone till the POC will be closed. Then for sure I’ll need some help from you guys.

All the best and thank you for support.

#26

ALSA is part of the kernel, you generally do not have to “start” ALSA in the traditional sense of starting an application.

Ardour and jackd should be started as the same user or Ardour will not be able to use the JACK server.

1 Like
#27

Thank you. I’m learning while running. Anyway… The problems were about to align asla, jack and ardour and of course it was a drama, especially because the RT privileges.:sweat_smile::index_pointing_at_the_viewer:

#28

Did following the instructions in the jackaudio FAQ not work right away?
I suspect you would be better served by asking specific questions on linux-audio-users mailing list than trying to determine which AI answers are correct and which are completely fabricated.

1 Like
#29

The truth is the best way to do what I’m trying to do is having a support from senior sysadmin. But I didn’t find it when I looked for and then a lot of dev told me they were not interested. So, this is my karma challenge: I’m going to achieve the Proof Of Concept by my blind trying. I’m sure I’ll achieve that. When I have that I’ll have something to let all you have a look working and maybe the project will be cooler and itself explaining. And at that time, I really hope to share developing with someone who really is a dev. I’m just a visionary and I like to try. But if I see right, the potential of this project is very very high, so I hope I’ll bring inspiration and find support and community to really build up powerful mixer. Thank you for your nice answering.

Ps: of course I’ll share with the world and LAU when my POC will be operative.

#30

Wow guys!! My startup script is working! My standard PC has been highly tuned by my script; IRQ assignment and CPU affinity, USB detection and maximum performance tested fo the connected device, with my old UM2 usb1 bheringer we have a stable 8ms roundtrip! My POC is quickly evolving and I’m going to clear garbage from my repo and wrong files and old test, then I’ll release my first POC startup script. Does anyone is interested in supporting me by testing the system?

#31

Hello everyone! I just released the POC1.0 version. Please have a look. In the next days i’ll send a couple of tutorial and screenshot. I would need help for testing on your devices to see if we get comparable results.

Thank you for being with me and helping and supporting!
Francesco Nano