MTC and MIDI Clock port input handling was moved into the process/RT thread(s) during audioengine work, but MMC was
left orphaned. Add it to the port(s) handled by the MIDI UI thread.
Also, remove PortChange request from MidiUI because it has no meaning anymore
Unlike all the other jack backends which allow setting the number of inputs and
outputs with -i & -o, the dummy backend uses -P & -C for this. Make the jackd
command line use these options when the dummy backend is requested with a
specified input or output channel count.
The dummy jackd backend doesn't require a device to be specified, so much
of the error checking in get_jack_command_line_string() is irrelevant, if
not actively wrong, when the dummy backend is specified.
Only perform the checks if the chosen jack backend is not the dummy.
Outdated and fuzzy translations of MTC, MTC, LTC, etc caused
various issues (duplicate jack port names, exceptions, crashes).
Functionality should not be affected by translations (for now).
track-owned MIDI port buffers (at the Ardour level) get ::flush_buffers() called twice, once by Delivery::flush_buffers() which is called
at the end of MidiTrack::rol() to push data out in graph order, and then finally as a last-chance effort in PortManager::cycle_end().
This should not cause a repeated attempt to write the same data, but it was. Fixed by marking the buffer empty once its data has
been flushed into a backend port buffer.
This is necessary to get the libmidi++ test to work as libmidi++ has
unresolved symbols in libtimecode. This was not a problem when libtimecode
was statically linked into libardour if the executable depended on both
libtimecode and libardour as the symbols would get resolved.
This is not true for the midi++ test case as it doesn't depend on libardour
Also as libmidi++ only references symbols from one object file in the
libtimecode static archive only that object file gets included/exported
from libmidi++.
This is fixed by adding a dummy reference to a symbol in the other object
file in the libtimecode static archive.
This avoids having to define define LIBFOO_DLL=1 all over the place. If we ever go with static libs we will
need to define LIBFOO_STATIC=1 but hopefully in some central location like the top level wscript.
Oh, and I also dropped support for gcc older than version 4.x because ardour will already not build
on such an old version.
This is slightly awkward. It is important that we only link once to the static lib. Doing this at executable link time did not
work, possibly because waf insisted on putting the two static libraries at the front of the link list. So instead libardour
is now the point where linkage to these libraries occurs (and nowhere else). This should never be changed unless the change
just moves the linkage point to another location.
Also fix a bug with the libardour version tha was picked up by waf 1.7
