V9.7.51 : the preferences > control surfaces is now looking good,
but although my shuttle pro2 is functioning inside Ardour, the checkbox is not checked.
If I click on the shuttle pro checkbox trying to enable the settings, the sound stops and ardour crashes.
It’s not possible to adjust the shuttle pro2’s settings inside ardours active surfaces.
I did have a similar random crash while I was trying to get this working on my system, but just tested the Shuttle pro 2 and it came right up.
There are no “settings” for things supported by a MIDI binding map (as is the case with the Shuttlepro). The settings buttons are only for things supported by a surface module that has distinct parameters for the user to adjust.
Hello Paul,
Yes I do understand that.
Maybe it’s a misunderstanding, but on Ardour versions until 9.5, for the shuttle pro2 it’s possible to assign an action of choice for each button, by first activating in the prefs > control surfaces > click the ContourDesign checkbox, and then after clicking the ‘Show Protocol Settings’ a Control Protocol Settings Window opens.
This window was superhandy but is missing in the recent Ardour version 9.7.51.
See this screenshot from Debian 13 X11 KDE Ardour 8.12 version.
I’m not complaining but this would be nice to see again in the recent Ardour version.
Grrr, is it again some spooky things going on with my system… ??
Probably ??
Maybe someone with a shuttle pro reading this can also check this out.
Is this because as soon as I click Shuttle Pro2 checkbox Ardour crashes, so Ardour even can’t open this Control Protocol Settings Window on my system ?
Did you build from scratch or using their pre-built executable? I also see the Shuttle Pro window when looking at the settings for it. Does it crash on other controllers or just the Shuttle Pro 2?
Hello Mark,
I did self build from scratch yes, to profit / check from the latest bugfixes.
I have 2 other controllers which are midi controllers, sending out midi data to Ardours midi control in ( for dedicated midi input use from midicontrollers ).
These midi controllers work perfect in Ardour.
The ShuttlePro2, isn’t a midi controller ( I think you know this ) but is sending out key commands I think.
In a previous linux Debian12 setup, I did install the Lander software ( Robotista / Shuttle Lander · GitLab ), but in Debian 13 I didn’t install anything for the shuttlepro2 because it is recognized instantly ( konsole command : lsusb ),
Good to hear you have the shuttle pro window in working condition, to access the individual shutlle pro buttons !
Hoping to experience the same behaviour in near future 
Kind Regards, Luc.
Hey Lauren,
No, I didn’t know anything about the ShuttlePro2 but trying to do a crash course in it. I’ll try to help as best I can since I started this thread and have learned a little bit about this area of Ardour.
I’m kind of thinking that something is different between our systems, and that difference is that you actually have a ShuttlePro 2. That would indicate to me that there is something wrong in the communication with the device, though there is probably a strong argument that if it was working in 9.5, it should be working in 9.7 as there probably weren’t any changes in this part of the code (my guess at least).
Can you try unplugging the Shuttlepro and then opening the window? That will verify if it’s something in the communication with the Shuttlepro and not just a configuration issue.
I’m also kind of curious if there is a difference in the device name since you said you used to have to load a driver and now you don’t. Did the name of the device change? Did you ever try loading that driver anyway?
There are also debug messages throughout this area of the code, but I haven’t been able to get a debug version of Ardour yet that will show those messages, which may be because I don’t have a shuttle pro. Run it from the command line and check the output to see if there are any debug messages that might say why it’s crashing.
EDIT: You would have to create a debug version of Ardour to see debug messages, and I’m not exactly sure how to do that. I used --debug-symbols on the waf build and configure options but didn’t really have any change, so not sure I’m doing that right.
Nothing is needed to get a debug build - it is the default.
If you want a non-debug build, then --optimize is added at the waf configure step
Where would the DEBUG_TRACE outputs show up? I haven’t seen them in the output and I’m not aware of a debug file… is there one?
You start ardour in a terminal window and they show up there.
Well, I’ve certainly done that many times, but even before when I started this I never saw any debug statements in the output stream. I usually had to double them up with cout to get something. I see in the Shuttlepro code a lot of DEBUG_TRACE statements, like when it searches for a Shuttlepro device, but nothing shows up in my console that the window was even selected to start the search. Not sure why I don’t see them then.
But may Lauren will, which is what counts now.
I would lean towards a bug in the communication somewhere, like maybe since debian is now handling this device there is another condition to consider, though it looked like there was enough error handling in the code to cover that and not crash, but never know.
You need to use -D XXXX (replacing XXXX with something appropriate)
-D list will show all the possible “something appropriates”.
Ah-ha… you mentioned that once before and it may have been perfectly clear to you what you meant but it was still greek to me at the time. Now I see…
Lauren,
Start ardour from the command line with the ShuttlePro connected with this command:
ardour9 -D contourdesigncontrol
And that should let us know about where you’re crashing. Please post the last few messages with a DEBUG tag on it.
Hi Mark,
Thank you so much for your posts and willing to help find a solution !
Since english isn’t my native language maybe there is some confusion, sorry for that.
Debian 13 Trixie supports the ShuttlePro2 out of the box, no special extra drivers needed.
On my system, konsole command “lsusb” lists → Bus 003 Device 005: ID 0b33:0030 Contour Design, Inc. ShuttlePro v2.
The ShuttlePro2 is also working in BOTH versions 9.5 and 9.7, all keys, jog and scroll are working here inside Ardour.
BUT with the Shuttle connected to my pc, in the version 9.7 have 2 issues :
The debug window, with ‘ardour9 -D contourdesigncontrol’ in the konsole gives this information, when I click the shuttlepro2 checkbox ( prefs > control surfaces ) and Ardour crashes :
(ardour-9.7.51:3617): GLib-CRITICAL **: 21:50:20.658: g_main_loop_unref: assertion ‘loop != NULL’ failed
ardour-9.7.51: …/…/libusb/os/threads_posix.h:46: usbi_mutex_lock: Assertion `pthread_mutex_lock(mutex) == 0’ failed.
Aborted (core dumped)
Strangely :
When I unplug the ShuttlePro2 device from my computer, I can click the ShuttlePro2 checkbox in the prefs > control surfaces, and see the shuttlepro2 under active surfaces, and by clicking there on the settings button the Control Protocol Settings window opens !
There’s also another notification, dont know if it’s relevant but when Ardour finished starting up, I see this in the konsole :
(ardour-9.7.51:3617): GLib-CRITICAL **: 21:49:24.715: g_main_loop_get_context: assertion ‘loop != NULL’ failed
(ardour-9.7.51:3617): GLib-CRITICAL **: 21:49:24.715: g_main_loop_unref: assertion ‘loop != NULL’ failed
To me it seems as something has changed in the code of the 9.7 version, compared to 9.5.
The Improved list of control surfaces looks nice but isn’t working for me because I just don’t have access to configure the shuttlepro2 buttons like it used to do until the 9.5 version.
I’m not a gifted programmer, I don’t know whats causing this behaviour and how to solve it.
Hey Lauren,
Glad to help, both you and the Ardour team. They have certainly spent their time creating this great tool, and unfortunately, I guess, I’m a better coder than musician, so if I can help in this way, glad to. I’ll just be a little slower than they might be. And your English is just fine. Think I’ve understood everything, I’ll just have to be a little clearer.
Yeah, understood. At least it is working, you just want to be able to change the key functions.
This is what I expected. There’s nothing wrong with the device code itself, just the interface. They just redesigned the interface and somewhere there’s a null pointer being referenced that’s causing the crash. Now to track that down.
Did you see any messages that started with a [DEBUG] before the Glib-CRITICAL message showed up? I’m most interested in any message in the window that starts with that [DEBUG] statement. If there weren’t any, that tells me something, but I need to be sure.
For example, this is what I see when I run ardour with that command and open the ShuttlePro2 configuration window:
… LOT OF OTHER MESSAGES…
Frame::on_size_allocate 1x94 < 442x94
Frame::on_size_allocate 1x94 < 442x94
Frame::on_size_allocate 1x94 < 442x94
Frame::on_size_allocate 1x94 < 442x94
using block size: 1024
mlock 1157524 bytes
DEBUG::ContourDesignControl: thread_init()
DEBUG::ContourDesignControl: set_active() init with yn: ‘1’
DEBUG::ContourDesignControl: start()
DEBUG::ContourDesignControl: acquire_device()
DEBUG::ContourDesignControl: set_active() init with yn: ‘1’
… LOT MORE MESSAGES…
Please run that command again and let me know what you see. Post everything that has that DEBUG::ContourDesignControl: tag on it in the order it came out. Thanks.
Hello Mark, it’s me again :
This is what I see in the konsole with gdb :
[New Thread 0x7fffaeffd6c0 (LWP 5959)]
[Thread 0x7fffaeffd6c0 (LWP 5959) exited]
[New Thread 0x7fffae7fc6c0 (LWP 5960)]
Set cursor set to default
[Detaching after vfork from child process 5961]
[New Thread 0x7fffaeffd6c0 (LWP 5962)]
[Thread 0x7fffaeffd6c0 (LWP 5962) exited]
[Detaching after vfork from child process 5963]
[New Thread 0x7fffaeffd6c0 (LWP 5964)]
[Thread 0x7fffaeffd6c0 (LWP 5964) exited]
[New Thread 0x7fffaeffd6c0 (LWP 5965)]
[New Thread 0x7fffadffb6c0 (LWP 5966)]
[Thread 0x7fffaeffd6c0 (LWP 5965) exited]
[New Thread 0x7fffaeffd6c0 (LWP 5967)]
[New Thread 0x7fffad7fa6c0 (LWP 5968)]
[New Thread 0x7fffacff96c0 (LWP 5969)]
[New Thread 0x7fff93fff6c0 (LWP 5970)]
[New Thread 0x7fff8bfff6c0 (LWP 5971)]
[New Thread 0x7fff937fe6c0 (LWP 5972)]
[New Thread 0x7fff92ffd6c0 (LWP 5973)]
[New Thread 0x7fff927fc6c0 (LWP 5974)]
[New Thread 0x7fff91ffb6c0 (LWP 5975)]
[New Thread 0x7fff917fa6c0 (LWP 5976)]
[New Thread 0x7fff90ff96c0 (LWP 5977)]
[New Thread 0x7fff8b7fe6c0 (LWP 5978)]
[New Thread 0x7fff8affd6c0 (LWP 5979)]
[New Thread 0x7fff8a7fc6c0 (LWP 5980)]
[New Thread 0x7fff89ffb6c0 (LWP 5981)]
[New Thread 0x7fff897fa6c0 (LWP 5982)]
[New Thread 0x7fff88ff96c0 (LWP 5983)]
[New Thread 0x7fff53fff6c0 (LWP 5984)]
[New Thread 0x7fff537fe6c0 (LWP 5985)]
[New Thread 0x7fff52ffd6c0 (LWP 5986)]
[New Thread 0x7fff527fc6c0 (LWP 5987)]
[New Thread 0x7fff51ffb6c0 (LWP 5988)]
[New Thread 0x7fff517fa6c0 (LWP 5989)]
[New Thread 0x7fff50ff96c0 (LWP 5990)]
[New Thread 0x7fff3bfff6c0 (LWP 5991)]
[New Thread 0x7fff39ffb6c0 (LWP 5992)]
[New Thread 0x7fff2f7fe6c0 (LWP 5993)]
[New Thread 0x7fff2d7fa6c0 (LWP 5994)]
[New Thread 0x7fff2cff96c0 (LWP 5995)]
[New Thread 0x7fff1a7fc6c0 (LWP 5996)]
[New Thread 0x7fff12ffd6c0 (LWP 5997)]
[New Thread 0x7fff0bfff6c0 (LWP 5998)]
[New Thread 0x7fff09ffb6c0 (LWP 5999)]
[New Thread 0x7fff037fe6c0 (LWP 6000)]
[New Thread 0x7fff017fa6c0 (LWP 6001)]
[New Thread 0x7ffef6ffd6c0 (LWP 6002)]
[New Thread 0x7ffef4ff96c0 (LWP 6003)]
[New Thread 0x7ffeea7fc6c0 (LWP 6004)]
[New Thread 0x7ffedffff6c0 (LWP 6005)]
[New Thread 0x7ffeddffb6c0 (LWP 6006)]
[New Thread 0x7ffed77fe6c0 (LWP 6007)]
[New Thread 0x7ffed57fa6c0 (LWP 6008)]
[New Thread 0x7ffecaffd6c0 (LWP 6009)]
[New Thread 0x7ffec8ff96c0 (LWP 6010)]
[New Thread 0x7ffebe7fc6c0 (LWP 6011)]
[New Thread 0x7fffb40f6cc0 (LWP 6012)]
[New Thread 0x7ffe977fe6c0 (LWP 6013)]
[New Thread 0x7ffe96ffd6c0 (LWP 6014)]
(ardour-9.7.56:5918): GLib-CRITICAL **: 17:12:00.738: g_main_loop_get_context: assertion ‘loop != NULL’ failed
(ardour-9.7.56:5918): GLib-CRITICAL **: 17:12:00.738: g_main_loop_unref: assertion ‘loop != NULL’ failed
[New Thread 0x7ffe967fc6c0 (LWP 6015)]
[New Thread 0x7ffe95ffb6c0 (LWP 6016)]
[New Thread 0x7ffe957fa6c0 (LWP 6017)]
[New Thread 0x7ffe94ff96c0 (LWP 6018)]
[New Thread 0x7ffe7ffff6c0 (LWP 6019)]
[New Thread 0x7ffe775ff6c0 (LWP 6020)]
[New Thread 0x7ffe7f7fe6c0 (LWP 6021)]
[Thread 0x7fffcc88d6c0 (LWP 5951) exited]
[Thread 0x7fffb77fe6c0 (LWP 5953) exited]
[Thread 0x7fffb7fff6c0 (LWP 5952) exited]
ardour-9.7.56: …/…/libusb/os/threads_posix.h:46: usbi_mutex_lock: Assertion `pthread_mutex_lock(mutex) == 0’ failed.
Thread 1 “ArdourGUI” received signal SIGABRT, Aborted.
0x00007ffff4db095c in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)
Interesting. Nothing from the module, so it crashed before it could load it. That gives me something to look for. I’ll let you all know if I find something. Thanks.
