Custom MIDI Controller Not Showing Up on Controller List

Installation & Configuration Linux
#61

Ah, thanks, Paul, but it’s been decades since I last used gdb. Would love to relearn that again and I will definitely look through that info, but I don’t think it will help me since I don’t have a shuttlepro 2 and I can’t make it crash like Lauren is having. I was hoping the debug messages would give me a clue but I may be at a brick wall. Trying to look through the code to see what might be going on. Stepping through would help a lot to at least understand the flow quicker… used to love MS Studio and it’s integrated debugger.

But I’m also seeing a lot of weird behavior in this dialog box, which is making me think this dialog needs a lot more attention than just this crash. It seems to replace items I’ve selected rather than add to the list, and then it will randomly add an item for some reason. Example:

I select and make my Kurzweil controller active. It shows up on the list in the active box. Fine so far.

I select another device at random, say a Korg nanoKONTROLER, and it will replace my controller with this one. Then I’ll select another one, and it will replace the Korg, still only one device in the active list. I’ll do that several times, each time replacing the one active controller with the new one, and then all of a sudden it will add the new controller to the list. No idea why or what was different on that selection.

So I select another one and it replaces one of the two in the list. Usually the last one added, and then I can repeat this pattern over and over till eventually I have more controllers, but it’s just randomly replacing them and adding them at will.

Not sure what to think about that, but this could be part of the issue with pointers to the control surface selection list being confused and if you actually have an active one with a device on it, it may be trying to access some other device it thinks was there but is actually null now. My guess at Lauren’s crash would be that the list isn’t being managed as expected and it’s referencing a null pointer, possibly because it’s the third one in the list.

And just for awareness and before you ask, after messing with it before, I rebuilt Ardour from the tarball so it was clean and the only change is that one line scale factor. I haven’t updated the source from git ardour is fine with one controller. I should be in line with your code unless you submitted more changes into git related to this dialog.

Lauren,

If you get a chance, can you disconnect the other two controllers you have and run a test with only the ShuttlePRO 2 connected? I’m curious if it will work by itself as the only controller in the list.

#62

At present, Ardour can only support one Generic MIDI (binding map) device at a time. Hence the replacement. This was more obvious in the old listing arrangement. I intend to fix this, perhaps in the next few months.

#63

Ok, well, Lauren says she has three controllers, which I assume are two keyboards and the ShuttlePRO… so that configuration won’t work?

#64

Wait, you said generic midi device, but I’m seeing the replacement on any device.

#65

Anything with its own dedicated support can be run alongside a generic MIDI device. So the Shuttlepro + generic MIDI is fine, but not N * generic MIDI devices.

“Generic MIDI” in Ardour covers most of the devices we support. That’s one downside (for now) in the by-manufacturer ordering - it doesn’t make this clear.

#66

Yeah, Ok. I can see there are differences, but not too clear which is which. I’d still be interested to see if this is related to the crash Lauren’s experiencing…

So Lauren,

Would still be interested in testing if loading with just the ShuttlePro connected will crash. Don’t have to worry about the debug messages.

#67

Dear Mark, Paul,

In addition to a midi keyboard, I have 3 ‘control devices’ connected to Ardour.
1 device is the shuttlepro2 which isn’t a midi device.
The 2 other midi devices, a faderfox-ec4 and a fadermaster, sending simultaneously out midi are both connected to Ardours Midi Control in.

For connecting I’m using these applications :

This setup has always been succesfull for my workflow with Ardour.

Now :
I did switch off all midi devices with only the shuttlepro2 connected to the computer.
That doesn’t make any difference, still the crash over here when trying to click the shuttlepro checkbox in Ardour.

Thanks to your helpfull explanation and Paul’s tip I did run Ardour inside GDB this time with thread apply all bt.
This is the output :

Ardour9.751-ShuttlePro2-crash
Ardour9.751-ShuttlePro2-crash578×994 271 KB

#68

Please paste text rather than an image.

#69

I’m sorry :

[New Thread 0x7fffbffff6c0 (LWP 4639)]
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) thread apply all bt
Thread 94 (Thread 0x7fffbffff6c0 (LWP 4639) “pool-5”):
#0 0x00007ffff4e2a7b9 in syscall () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff5d36670 in g_cond_wait_until () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff5ccc753 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff5cccd85 in g_async_queue_timeout_pop () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff5d36f0d in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff5d368c3 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007ffff4daeb7b in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#7 0x00007ffff4e2c7f8 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
Thread 93 (Thread 0x7fffd49046c0 (LWP 4638) “pool-4”):
#0 0x00007ffff4e2a7b9 in syscall () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff5d36670 in g_cond_wait_until () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff5ccc753 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff5cccd85 in g_async_queue_timeout_pop () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff5d36f0d in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff5d368c3 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007ffff4daeb7b in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#7 0x00007ffff4e2c7f8 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
Thread 92 (Thread 0x7ffe827fc6c0 (LWP 4576) “AutomationWatch”):
#0 0x00007ffff4db69ee in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff4dab668 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff4df7fba in clock_nanosleep () at /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff4e033d3 in nanosleep () at /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ffff5d37f97 in g_usleep () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007ffff71d7dc5 in ARDOUR::AutomationWatch::thread() () at /home/username/workspace/ardour
build/libs/ardour/libardour.so.3
#6 0x00007ffff6933b6f in PBD::thread::_run(void*) () at /home/username/workspace/ardour/build/libs/pbd
libpbd.so.4
#7 0x00007ffff4daeb7b in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#8 0x00007ffff4e2c7f8 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
Thread 91 (Thread 0x7ffe82ffd6c0 (LWP 4575) “AutoConnect”):
#0 0x00007ffff4db69ee in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff4dab668 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff4dabc8c in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff4dae158 in pthread_cond_wait () at /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ffff7633a90 in ARDOUR::Session::auto_connect_thread_run() () at /home/username/workspace
ardour/build/libs/ardour/libardour.so.3
#5 0x00007ffff7633af9 in ARDOUR::Session::auto_connect_thread(void*) () at /home/username/workspace
ardour/build/libs/ardour/libardour.so.3#6 0x00007ffff6933ad0 in fake_thread_start(void*) () at /home/username/workspace/ardour/build/libs/pbd
libpbd.so.4
#7 0x00007ffff4daeb7b in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#8 0x00007ffff4e2c7f8 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
Thread 90 (Thread 0x7ffe837fe6c0 (LWP 4574) “SessionSignals”):
#0 0x00007ffff4db69ee in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff4dab668 in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff4dabc8c in ??? () at /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff4dae158 in pthread_cond_wait () at /lib/x86_64-linux-gnu/libc.so.6
–Type for more, q to quit, c to continue without paging–

#70

There’s many more pages than that … might be wise to use a paste site such as pastebin.com

#71

Hopefully this time better ( sorry Paul, but this debugging report is something I have to learn ).
I’m probably looking ‘not that smart’ over here :slight_smile:

#72

I think you’re going to need to run with -D controlproto,contourdesign from the command line.

The crash is inside libusb as Ardour tries to release it’s “handle” on the shuttlepro.

NOTE: this requires a debug build.

#73

Thanks, Lauren. Paul looks like he’s on it and I don’t think I can add any more value. Good luck! Hope a solution comes soon.

#74

The Ardour adventure is keeping me up late at night over here, still learning a lot… :slight_smile:
I just want to say : thank you for fast reply’ing and all the effort from both of you ( and probably other people involved ).
Would be so nice to see this one solved, I have no doubt that this will happen in the future.
Again : thank you !

#75

Hello Paul,

Here the GDB crash debug report with : run -D controlproto,contourdesign

https://pastebin.com/Lb6NSAbB

Hoping this is usefull for solving the shuttlepro2 crash.

#76

Alas, this has none of the output from the -D XXXX flags …

#77

Yeah, unfortunately that leaves us where we were several posts back. Feels like there’s something in the redesign that is referencing the controller before it’s ready. Any multi-threading going on here that one thread may try to reference the controller before the other thread has finished initializing it?

#78

Sorry but all this debugging is new territory for me.
It seems that I failed in giving to nessesairy information, isn’t it ?

If there’s someone who could explain me how to generate this -D XXXX flags output, Paul is asking for,
I would be more then happy to do that.

#79

No, it’s not you, Lauren. The output doesn’t have what we were expecting, or hoping for. This is probably getting into some serious debugging to figure out exactly why it’s crashing, and without a ShuttlePro, neither of us can run it in a debugger to see exactly what’s going on. The lack of the debug messages we were looking for leaves things a bit unclear.

I’ve seen instances where debug messages sent from a constructor don’t show up because the object hasn’t established a connection with stdout yet, so they get popped on the program’s internal queue, but the program crashes before the system can pop them off and that’s why we’re not seeing them. That usually implies that another thread is trying to access the object before it’s ready for use, but debugging multi-threaded apps is pretty tricky.

My thought is that the crash is occurring somewhere in the transferring of the object from the device list to the active list. I’ve looked through the code but I don’t understand the run-time design enough. I believe device discovery is happening when you click the ‘check’ box, but the active list is trying to display it before the constructor finished and is ready, but it still seems that the pointer to the device should be assigned by then and should be safe to at least display it in the list. A sequence diagram would be nice.

Or it could be something completely different. :confused:

#80

@MarkR1 not quite. The output from the -D flags is completely missed in Lauren’s pastebin.