#100 Build with JACK enabled failed on Linux Debian9/amd64: 'MIDIMultiTrack' does not name a type

[Sergej M.P.]

Compilation with JACK enabled failed on the only file that is conditionally included when USE_JACK is defined. :-(
Error: 'MIDIMultiTrack' does not name a type
Debian 9.1-amd64
g++ (Debian 6.3.0-18) 6.3.0 20170516

Build output is attached.

Without JACK build was successful, I started vmpk, then Aria and I could hear and record my playing on virtual keyboard. Editing capabilities are too limited for my needs but at least program works.

Another possible issue by the way:
scons/scons.py --help says:

jack=[0/1]
whether to enable the Jack MIDI driver (on by default for non-Linux unices, disabled everywhere else by default)

It seems it is not correct, both jack=0 and jack=1 turn -DUSE_JACK on, maybe empty assignment "jack=" has to be used to turn it off? Anyway, on my platform JACK is disabled by default, and unfortunately with ALSA output I had no success too.

[Sergej M.P.]

Sorry, I see I can not edit posted text, this last phrase: "and unfortunately with ALSA output I had no success too." may be deleted.
I finally got success with keyboard connections and sound, I hope JACK will compile and work some day, JACK-apps usually are much more obvious and comfortable with virtual connection management.

[M Gagnon]

Hi, the JACK backend to Aria was contributed to the project by a third-party, sadly they did not stay around to maintain it. I am personnally not very knoweldgeable about jack and my free time is rather limited, so I might eventually get around to fix it depending on my free time, but help would definitely be welcome

[Sergej M.P.]

Now I have read compiler output more thoroughly and got his idea.
This error is not related to JACK, it is a bad inclusion graph, a kind of cycled dependency.

Here is compiler's complaints:

In file included from libjdkmidi/include/jdksmidi/world.h:91:0,
                 from libjdkmidi/include/jdksmidi/midi.h:41,
                 from libjdkmidi/include/jdksmidi/track.h:41,
                 from libjdkmidi/include/jdksmidi/multitrack.h:41,
                 from Src/Midi/Players/Jack/JackMidiManager.cpp:14:
libjdkmidi/include/jdksmidi/utils.h:34:28: error: 'MIDIMultiTrack' does not name a type

multitrack.h indirectly-implicitly includes world.h, which contains at its end directive to include util.h, which in turn starts with requirement to include multitrack.h, but inclusion of multitrack.h is already in progress, JDKSMIDI_MULTITRACK_H is defined and preprocessor believes this requirement is already satisfied, so far we got preprocessor output with code from util.h above the main code from multitrack.h (which util.h depends on).

I hope the designer of jdksmidi library knows the right way to rearrange header files and their dependencies. At my first look it seems that is messy.
My quick dirty fix for util.h header is to replace #include of multitrack.h with declarations:

class MIDIMultiTrack ;
class MIDITimedBigMessage ;
typedef unsigned long MIDIClockTime ;

AFAI see util.h need not definitions of multitrack.h's and other's types, these three lines are quite enough (although I think it is not a very nice idea to create duplicates of type declaration in various header files...)
This way it does compile and run with JACK output with tiny latencies. Unfortunately I was not successful to do usable setup with JACK, but to some extent it works.

By the way.

1.
Somewhat specific behaviour with client/port registration with ALSA sequencer.
As I see, Aria does not register ports until they are required for in/out, so I can not see, say, Aria MIDI-in port in aconnect -l or patchbays until I push "Record".
May be those old days when each DAW pretended to be a Master that was okey, now I believe it would be preferred if app exports its connection points and allows to manage them from central patchbay...
Next difficulty with Aria - it seems Aria does not "rescan" available foreign ports when I click her menu "input" or "output": menus always contain lists that were built on Aria start (?). So far I could not start Aria and then virtual keyboard, I had to start vkeyboard and fluidsynth (if I want to use it) at first and Aria at second.

2.
I noticed that when aria was connected to timidity and system suspended and then resumed from suspend-to-disk state someone ate CPU, it was timidity. If I closed Aria then timidity stops eating CPU. I do not know who is in response for this nor if it is reproduceable on other systems, Just a point to pay some attention to.

3.
Aria's ALSA MIDI-in port that exists during recording has default library name "RtMidi Input".

Thanks

[M Gagnon]

Hi, try getting the latest svn, I have fixed the compilation issue in a simpler way by simply including the utils file first.

Regarding your point 1 and 3, this sounds like legitimate concern, however those would be much bigger changes to fix probably so unfortunately I don't think I will have time soon for that

As for your point 2, I have never experienced that myself so not sure what is going on