I have all the same dependencies I had before. Everything is available. I did a waf install with sudo and the only midi_maps directory I see is from an earlier build this morning. That directory is under “/usr/local/share/ardour9/midi_maps”. That’s the only midi_maps directory that shows up in a search under /usr. Same with mcp. Looks it’s from my 9.5 build earlier, but maybe waf won’t overwrite a file that is already present and the same?
Well, at least I know what it’s supposed to look like. I may need to uninstall and reinstall. Seems to be something in the configuration on my end. I’ll keep working on it and hopefully figure it out. Thanks.
It is possible that there’s an error in “waf install” that doesn’t install the surfaces files, but it seems unlikely because our windows builds rely on waf install …
I just dumped the install output to a file so I could see the whole output. It is definitely copying the midi maps and surface libraries over under /usr/local/share/ardour9… I think the date/time is just misleading me as I’ve seen Konsole do sometimes, so I’m still unsure why they’re not showing up in the control surfaces window. It’s just blank, but if those are the correct directories… doesn’t make sense. They should be showing up.
I added some debug statements to the file “generic_midi_control_protocol.cc” in libs/surfaces/generic_midi. This is where I could see that the midi maps were being loaded earlier in the 9.5 build. Best I can tell now, though, the routine “reload_maps()” is never being called. I’m not getting any of my debug statements from it, even the first immediate one in the routine, and it is definitely compiling it in and moving it over. This file looks very similar to what I saw before in 9.5, but I would expect the display of the data is somewhere else and that’s where the changes were, but it seems like this is not being called anymore. If it’s supposed to be, there may be a bug in the Linux build. If this file is no longer needed and something else is being used, then I’ll have to track that down, but thought I’d post this before I chase this too far.
I tested our 9.7 binary build and it works entirely as expected. Not sure what is happening on your side. I wasn’t involved in writing the code that changed things up since 9.5 (that was contributor Franke Burgarino. It also works when using ./ardev to run from inside the build tree. Does that work for you?
I don’t really know how to do that. I’m just doing some ol’fashioned command line debugging with grep and vi. Can you verify that the routine “reload_maps” is still part of the solution? It may have changed, though the generic midi controller window you show above looks pretty much the same as before. Seems it’s just in the presentation layer where all the changes took place. Definitely looks like different behavior than 9.5 though.
Then I’m out of suggestions, bceause that bypasses anything to do with installation. Are the files there in share/midi_maps and share/mcp (within your source tree) ?
I’ve been putting debug statements in to try to trace what’s happening. I have been concentrating on the file “generic_midi_control_protocol.cc” as this seems to be at the lowest level of this function. I have debug statements throughout it. None of them are showing up in the output and looks like the GenericMidiControlProtocol object is never being created, though I assume that’s a base class for something more specific ones. In 9.5, I was able to see debugging data from this object, but so far, nothing in 9.7.
There is a function inside this file called “midi_map_filter” that I can see being called several times in the output, maybe 30 or 40 calls, which is close to the number of controllers I see in the midi_maps folder, but nothing for the class object itself.
I’m trying to trace where the class objects themselves are being created, but that’s a deeper dive and will take me a while longer, but hoping this might trigger something in the dev team. I think there is a bug here as I’m seeing definite differences in behavior between 9.5 and 9.7, and I don’t think there should be a difference at this level, but perhaps it was intended and something else replaced this.
EDIT: Ok, the “midi_map_filter” static function is being called from within the GenericMidiControlProtocol class, so that is evidence that the object is being created and now I can see the midi maps being created for each of the files, including my own. I don’t think the class has visibility to stdout though, so that’s why my debug messages are not displaying. That seems to be what has changed from 9.5 to 9.7. Everything seems to be loading correctly, but I’ve no idea why it’s not displaying. I can even see the compiled surfaces being loaded, but they don’t display either.
Yeah, that’s the output I was just seeing with the cout’s I put in. I can try the -D controlproto and see if that enables more of it.
Definitely some misconceptions on my part as I figure out your code. Hard to get in other people’s mind to figure out how they designed something. I have a decent background in c/c++ but every solution is different, so just takes some time to decode it.
Everything seems to be working as you intended it, but it just doesn’t show up in the window. I thought it was a data problem, but that seems to be working just fine. Not much left other than the display window. Doesn’t make sense why they’re not displaying.
Found it. In the ControlSurfacesOptions constructor, there is a scale check for the size of the font or table. On my system that evaluated to zero. I added in a check for zero and set it to 1 and it started working. Here is the short code segment:
class ControlSurfacesOptions : public OptionEditorMiniPage
{
public:
ControlSurfacesOptions ()
: active_heading (_("Active Surfaces Mod"))
, devices_heading (_("Control Surfaces"))
, _ignore_view_change (0)
, _protocol_change (0)
{
int scale = UIConfiguration::instance ().get_font_scale() / 102400;
cout << "DEBUG:COntrolSurfaceOptions:UIConfig Scale is " << UIConfiguration::instance().get_font_scale() << "and Scale is " << scale << endl;
if (scale < 1) scale = 1;
But onto the next problem…
When I activated a generic midi interface and went to select the MIDI bindings, there aren’t any controllers on it. There are just three options; Generic MIDI, Drop Map & Learned, and Drop Map Bindings. Do I select one of those and then that enables something? Or should I be seeing the whole list of controllers there? I know they’re loaded, but they aren’t on this list.
I was running this with ardev so should have been the default build config.
EDIT: Never mind. I had done a clean and lost my custom file. When I added it back to the directory with Manufacturer “Any”, it showed up on the list and should be bound. Much nicer system. The pulldown list was huge before.
I think we’re good now. Thanks all. Love Ardour. A fantastic DAW.