Lua Scripting GUI Library

Does anyone know if you can create a GUI with Lua scripting or is there any GUI libraries that work with it ?

In short: You cannot create custom UIs from scripts.

Currently Lua scripts only support Dialogs, but no custom GUIs.

As opposed most proprietary DAWs, Lua scripting in Ardour serves a different purpose.
Since Ardour is free/libre software, the source-code is available and can be modified. 3rd party contributions can be directly integrated without resorting to scripts.

Lua scripts have direct access to large parts libardour as-is. It is not a stable script API. Lua is mainly useful for interactive introspection, one-off features, batch processing tasks, random glue and prototypes.

Currently Ardour GUI libraries (Ardour’s libcanvas, libwidgets, libgdk, etc) are not directly available to Lua scripts.

1 Like

I was just looking at porting ReaTrak over, but I just do Lua and I’m not on Linux.

I’m planning to implement Chordimist (a Max4Live component) as an LV2 plugin. It won’t do quite what ReaTrak does, but is somewhat related.

Ardour already comes with VAMP plugins to detect pitch and chords (those are also already available as Lua bindings), but no custom GUI.

Maybe Lokasenna could help implement something

And, are you guys the equivalent to Justin Frankel & John Schwartz :slight_smile:

Well, Justin came to talk to me before he started Reaper, so make your own judgement on that.

I’m not sure you totally got the point of Robin’s original answer.

Because we’re an open source project, we don’t need a scripting language to do arbitrary extensions to the software - you can just extend the software without the scripting language.

Now, yes, that does mean you have to (1) be able to build it and (2) have to be able to deal with C++. It seems that for the current generation of largely web-development experience-based programmers, these two are often stumbling blocks.

But it is important to underline Robin’s point again. With Ardour, you don’t need a scripting language with GUI capabilities in order to make extensive changes to the program: you can make any changes to the program you want.

This is in contrast to Reaper, where there is an extensive and very powerful scripting language for extensions, but you can only do what Justin et. al. decide to make possible. In Ardour, we just give you the entire source code, no need to screw around with a subset of the capabilities being exposed by Lua or whatever else.


(2) have to be able to deal with C++

I understand what Robin explained, if I knew C++ and come from a Linux background sure I would be right into it no problem at all.
I’m just thinking for end users as most would be from a Windows background if Ardour is used by mostly Windows users.

There’s almost nothing in our codebase that is platform-specific. We use Glib as a portability library, which provides something reasonably POSIX-like no matter whether the platform is Windows, macOS or Linux (or Solaris, or FreeBSD or some other operating systems to which Ardour has been ported). People who are intimidated by the POSIX API (as represented by Glib) probably shouldn’t be working on a cross-platform application (since it’s really the only API that you can viably use in such a context, or something very closely modelled on it).

Most end users do not code :slight_smile:

It’s all a bit too deep for me :frowning: , all I mean is end users can use the Lua script without having to know C++ and compile to add a feature or function. Is that why you have scripting in Ardour to make things easier for the end user.
I could probably get the basic functions of ReaTrak working without having any GUIs.
Basically it would read the chord track (regions/markers) and import the chords from the source wav by reading the text file for the wav that has the region list with the name of the chord and the time/bar it occurs in the wav, then import to that chord on your track and adjust the media start pos and length. The drum track will just fit to the verse chorus of the regions/markers (that’s where color select would be good for regions/markers).

Ardour does already offer a similar Widgets (checkboxes, text-entry, sliders, dropdown menu, file-select, etc), but only for Dialogs:


It is still somewhat limited, the layout is automatic(a key/value pair table), yet it is already sufficient to setup custom extensions, or configure batch processing operations (grep for LuaDialog.Dialog in the scripts folder).

At some point it would be great to use Lua more centrally as glue in Ardour’s GUI (not editable by users) because it is very convenient. By then it may also be possible to for 3rd party scripts to create Windows with custom layout and process events.
Realistically, however, it may be years until we get there. There is also no immediate benefit of allowing to script the GUI. Yet other areas of Ardour are in dire need of improvement.

Integrating a script-interpreter with Ardour’s main GUI event-loop needs very careful planning. It’s, alas, not something to hack on a long week-end. Still, If someone wants to step up and contribute that will be very welcome.


That looks good ! I got that to run and added a few things.
I thought of using AutoHotKey GUI though it’s only Windows but as you say most of the users are Windows, it has an Always On Top option and tabs.
I can use “WinMenuSelectItem” to access the scripts

WinMenuSelectItem, ahk_class gdkWindowToplevel , , Edit, Lua Scripts, “script name”

You can then also add macros. It can also use SendMIDI to send the chord tone to the system gm synth when entering chords.
Thanks for that info it’s all looking good !

Getting somewhat off-topic, but for Ardour, that is not true.

There are some statistics from “new version checks” from official versions from and Linux users have a slight edge. That does not include all the versions from linux-distros (who disable version check calls to

Ubuntu alone has 74481 installs and that’s only from users who agreed to submit stats.

As of today, official stats say 43% Linux, 42% Window, 15% Mac. Yet by factoring in Ubuntu alone it’s more like 75%, 18%, 5%. and that doesn’t include Debian, KXStudio, AVlinux, Arch, etc

That being said. If making it windows-only but it solves a problem for you, that’s all fine. It is not uncommon to have some things work on a given platform only. AudioUnit plugins are the prime example.

I think I read something Paul typed, maybe it was a while ago.
So I’ll have to use autokey or IronAHK for Linux I don’t know if they have got GUI’s like AHK ?
I was looking for a Mac equivalent, thought of applescript but with Mac every time there’s a new cat, mountain range or island something don’t work anymore. And now they have banned you from using 32 bit apps.

Who is next? Vocalists? Songwritters?

Just add a button and x,y options to those and you’re there (color option also would help).
This is a modified Scripting window (below), you can add whatever scripts you like to it, it has a scrollbar, might add some tabs to it for different categories. It’s set to Always On Top “set_keep_above”.
Being able to run a script from within a script or be able to run a sequence of actions as a new action. ReaTrak runs a lot of script actions within one script.
These will take things from the impossible to a walk in the park.
You have so many Lua Bindings but you need to be able to make use of them.

You have so many Lua Bindings but you need to be able to make use of them.

I hit this problem a lot. I usually just end up running scripts from the script editing window, which is not ideal.

The script editing window has all you need, so it could be modified also as a separate Scripts Action window that you can select what scripts you need to show (as pic below) from the scripts folders and in what Tab.
Reaper uses the Command ID’s that can be run in a script

commandID101= reaper.NamedCommandLookup("_RSce47da3c9b1238de71cc94a1cb99732b9abd5e41") -- User Script ID
reaper.Main_OnCommand(commandID101, 0) -- Script: ReaTrak Go to start of next region.lua

or the native actions

reaper.Main_OnCommand(40012, 0) -- Item: Split items at edit or play cursor

instead of having to run one action script at a time.