[ardour-dev] Insight on a few Ardour bugs?

Brian Ahr brianahr at gmail.com
Wed Nov 8 20:11:12 PST 2006

Hi all.
Ive gone through mantis, and picked out a few bugs I'd like to fix (or 
see fixed, whichever comes first). So far, I've had a few patches 
accepted into the source tree, and would like to continue to contribute 
to the project. However, I'd like to ask for some input/suggestions/etc 
on what the best way to go about some of these would be. I'm sure the 
senior developers can provide some good insight. If nothing else, 
perhaps I can generate some interest in getting these specific issues 
resolved. Thanks in advance for any comments on these.

Also, one more quick question. If a bug is marked for the 0.9x series, 
but is still present in the 2.0 series (and I fix the 2.0 series bug), 
should I post the patch to that bug, or file a new one for the 2.0 
series, and post it there? Or just email out patches?



1. Bug #211, Most buttons do not show their status (colour) when the 
mouse is hovering over them

Seems like #94 and #211 might be related?

I'm curious if the gtkrc file can be modified to fix this. That 
certainly seems like the cleanest solution, if such would be possible. I 
haven't played with gtkrcs too much, so I'm not sure if gtkrc is 
powerful enough to do that. If not, another solution might be to 
implement mouse-over handlers for all the affected widgets - but thats a 
lot of work, touches a lot of code, and probably isn't the best possible 
solution. It might also be possible to subclass the button widget, with 
one that preserves its color on mouse over, but that still touches quite 
a bit of code.


2. Bug #1194, If plugin connection impossible, Add dialog closes


Seems that the connection dialog closes by default, and the 
weird_plugin_dialog is called from deeper in the code. Here's whats 
going on:

Connect Button Clicked -->
    PluginSelector::run [plugin_selector.cc:482] -->
        PluginSelector::use_plugin [plugin_selector.cc:380] -->
            <signal> PluginCreated() -->
                RedirectBox::insert_plugin_chosen [redirect_box.cc:359] -->
                    RedirectBox::wierd_plugin_dialog [redirect_box.cc:377]

Obviously, if the connection is impossible, which seems to be determined 
in RedirectBox::insert_plugin_chosen, something needs to happen to tell 
the top level method (PluginSelector::run) not to close the dialog - any 
ideas on what would be a clean way to do this?


3. Bug #1210, Would be nice if there was a way to globally change the 
height of all tracks in the editor.


I've gone around on this one for a while. I have a patch for it, but I'm 
sure theres a better way. According to the report in mantis, when the 
'Display height' button is Ctrl+Shift clicked on a track, and then the 
user selects a height from the pop-up menu, the height of all tracks 
should change to that height. Seems reasonable enough.

The click handler for the button has a GdkEventButton *ev, passed to it, 
from which it's possible to figure out if Ctrl+Shift was clicked. Is 
there any way to figure out instead if the menu item was Ctrl+Shift 
clicked? That would simplify the solution a bit. If not, I've come up 
with two possible solutions, neither of which I'm perfectly happy with. 
Let me explain:

a) use the existing pop-up menu, and just change the callback, so it 
checks if Ctrl+Shift was clicked on the button. This works, but requires 
some way to pass that information (ie, if Ctrl+Shift was pressed) to the 
callback that handles the menu click. Using a flag somewhere in the 
class isn't a good idea, since that introduces a bug that if you 
Ctrl+shift click the button, then cancel the menu, then change the 
height of a track, the height of all tracks still change... and since 
Gtkmm doesn't wrap the menu_canceled signal, I haven't found a way 
around that.

b) alternatively, define another pop-up menu, which only handles the 
case of Ctrl+Shift click, and have the button callback select which menu 
to display based on if Ctrl+Shift was clicked. Works great, but adds 
another menu to the code...

My patch uses (b). If anyone is interested in seeing that, Ill email it 
out, and/or post it to mantis.


4. Bug #1293, Punch markers can be hidden but the edit area remains colored


Is this really a bug? Seems that if you hide the punch range, the 
colored area is still there, however, deactivating the 'Punch In' and 
'Punch Out' Buttons makes the colored area go away. Can someone clarify 
the desired action?

Also, is this related to bug #1294 ?



5. Bug #1292, "Original Position" function does not work


Can someone explain to me what this function is supposed to do?


6. Bug #1041, If track name has ":" in it, outputs are not saved


This seems like a good thing to have fixed. Jack gets seriously confused 
if there is a colon in the name of a track. What would be the desired 
action? Just prevent ":" in track names?


7. Seems like there might be a few memory leaks?

There's no bug filed for this as of yet. But I ran Ardour through 
valgrind, (ie, open ardour, play 2-3 seconds of audio, and close it). 
The output from valgrind is nearly 10,000 lines long (ie, about 250 
pages) Granted, a lot of that is bugs in GTK, Gtkmm, glib, etc... I 
should set up valgrind to suppress the bugs in the libraries. Does 
anyone have an existing ardour-specific suppression file that they use 
for this kind of stuff?

More information about the Ardour-Dev mailing list