This problem was reported in Fedora 32 (https://bugzilla.redhat.com/show_bug.cgi?id=1822206).
Fedora 32 is the first Fedora version to ship this fork of a2jmidid.

Changing start to --start breaks some convention in starting dbus services.
Can we restore old behavior, or add some compatibility switches?

Hi,

The patch to support riscv64 on Debian is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995472

So do we have plan to support it?

Please let me know if this helps.

FYI: These two chunks were needed in order to use this program under FreeBSD.

--- meson.build.orig	2022-02-11 10:51:29 UTC
+++ meson.build
@@ -17,6 +17,7 @@ dep_jack = dependency('jack')
 dep_alsa = dependency('alsa')
 lib_dl = cc.find_library('dl')
 lib_pthread = cc.find_library('pthread')
+lib_execinfo = cc.find_library('execinfo')
 deps_a2jmidid = [dep_alsa, dep_jack, lib_dl, lib_pthread]
 
 # source definitions
@@ -50,6 +51,7 @@ if get_option('disable-dbus')
 else
   dep_dbus = dependency('dbus-1')
   deps_a2jmidid += [dep_dbus]
+  deps_a2jmidid += [lib_execinfo]
   dbus_data = configuration_data()
   dbus_data.set('bindir', join_paths(get_option('prefix'), get_option('bindir')))
   dbus_data.set('dbus_service_dir', join_paths(get_option('prefix'), 'share', 'dbus-1', 'services'))
--- sigsegv.c.orig	2022-02-11 10:51:46 UTC
+++ sigsegv.c
@@ -91,7 +91,7 @@ static void signal_segv(int signum, siginfo_t* info, v
     a2j_error("info.si_errno = %d", info->si_errno);
     a2j_error("info.si_code  = %d (%s)", info->si_code, si_codes[info->si_code]);
     a2j_error("info.si_addr  = %p", info->si_addr);
-#if !defined(__alpha__) && !defined(__ia64__) && !defined(__FreeBSD_kernel__) && !defined(__arm__) && !defined(__hppa__) && !defined(__sh__) && !defined(__aarch64__)
+#if !defined(__alpha__) && !defined(__ia64__) && !defined(__FreeBSD__) && !defined(__arm__) && !defined(__hppa__) && !defined(__sh__) && !defined(__aarch64__)
     for(i = 0; i < NGREG; i++)
         a2j_error("reg[%02d]       = 0x" REGFORMAT, i,
 #if defined(__powerpc__) && !defined(__powerpc64__)

The M-Audio Keystation Mk3 has two ports on it's Alsa device: one for the keys on the keyboard and the second for the control and transport buttons. When running the command a2jmidid -e this generates the follow messages:

JACK MIDI <-> ALSA sequencer MIDI bridge, version 9 built on Thu Jan  1 01:00:00 1970
Copyright 2006,2007 Dmitry S. Baikov
Copyright 2007,2008,2009,2011,2012 Nedko Arnaudov

Bridge starting...
Using JACK server 'default'
Hardware ports will be exported.
Bridge started
Press ctrl-c to stop the bridge
port created: Midi Through [14] (capture): Midi Through Port-0
port created: Midi Through [14] (playback): Midi Through Port-0
port created: Keystation 88 MK3 [28] (capture): Keystation 88 MK3 Keystation 88
port created: Keystation 88 MK3 [28] (playback): Keystation 88 MK3 Keystation 88
ERROR: a2j_port_create: jack_port_register() failed for 'Keystation 88 MK3 [28] (capture): Keystation 88 MK3 Keystation 88'
ERROR: a2j_port_create: jack_port_register() failed for 'Keystation 88 MK3 [28] (playback): Keystation 88 MK3 Keystation 88'

This also gives the following message on the jackd side:

port_name "a2j:Keystation 88 MK3 [28] (capture): Keystation 88 MK3 Keystation 88" already exists
port_name "a2j:Keystation 88 MK3 [28] (playback): Keystation 88 MK3 Keystation 88" already exists

This renders the control and transport buttons unusable unless you manually setup a bridge. Using the -u option does nothing to solve this problem.

1. a2jmidid when running disallows any other application to directly use a midi pad controller.

2. This creates an untenable either-or situation as applications that need direct access to midi pad controllers are cut off when a2j runs. When a2j doesnt run, on the other hand, then programs such as Mixbus loses it's midi pad controller as Mixbus only receives control midi through a2j.

3. Further I was unable to find configuration files for a2j, where I can tell it to ignore a specific pad controller. This would solve my either or situation.

Question:

1. If such a configuration (as in (3) above) currently exists, please point me to it.
2. If it doesn't exist are you willing to implement it ?

It is clearly a problem that a2j by default cut off all other applications from their midi controllers and it is good practice fir a2j to have a config file whereby it can leave specified controllers alone or ignore them altogether.

As an explicit example. I lose my control surface working with Bitwig if I start a2j, because a2j seemingly just willy-nilly confiscate all the available midi devices even though most of the devices will not be used in jack.
It would be nice if a2j can exclude specified midi devices so other applications can continue to use their control surfaces while a2j runs.

I hope you see my problem/point.

When passing note on messages with velocity zero, a2jmidid converts them to note off messages. For example, a note consisting of bytes [144, 56, 0] is converted to [128, 56, 64] while passing through the bridge. This behavior may be harmless or even desirable in many cases, but it's interfering with my ability to control the lights on my APC Mini. The Mini will only turn off it's lights if it receives a note on message with zero velocity in the form given in my example above. Note off messages won't work.

Midi is ultimately a byte wise low level protocol that's not always used to control synths in the way the spec suggests. Why not just pass through the messages as received and leave interpretation to the end points?

Commit a2138aa changed the a2j_control command-line interface in backward incompatible way.

As the commit breaks existing scripts, I've reverted the breaking change in LADI/a2jmidid codebase: LADI/a2jmidid@3f39efb
python 2to3 was trivially applied without causing any breakage: LADI/a2jmidid@955db9d

Please consider fixing this breaking change as part of jackaudio/a2jmidid code-base.

See also #2 #9 #13

Hi,
I'm just forwarding this bug report issued via Debian BTS.

Best regards,
Carlo

Hello,

a2jmidid does not seem to update port names when they are renamed.

I tried it with Rosegarden, I created a MIDI port and then renamed it. The ALSA MIDI port is renamed correctly, the JACK MIDI port created by a2jmidid kept the old name (unnamed, in this case).

Not that much has happened since the last release in 2019, but not much is more than nothing.
It would be great to see the changes finally trickle into a release/tag :)

Capture and Playback reversed (I think)

When displayed in graph in qjackctl-0.9.4-48.1 and in aconnect, the labels capture and playback seem reversed.

example

aconnect -o

client 133: 'a2j_bridge' [type=user,pid=15884]
    0 'playback        '

The -o option List existing output (writable) ports. This port is listed as playback, where capture would be anticipated.

The reverse is true for the aconnect -i, where capture is listed, and playback anticipated.

In use, this results ( as show in graph) in the output of Drumstick Metronome being connected to 0:playback of a2j_bridge, and the capture of the corresponding a2j_bridge being connected to the input of the device receiving the signal.

All works as expected, only the labels appear swapped.

Apologies if this is anticipated behavior.

Tested with 5b8f5d9

MIDI messages larger than 16 bytes are silently dropped.
This is easily triggered by sending sysex.

Dropping happens in a2j_process_outgoing()
The size is set by MAX_JACKMIDI_EV_SIZE, which is used in the definition of struct a2j_delivery_event.
The size of that struct is used in the allocation of a jack_ringbuffer.

I've changed the event size to 512 in my branch to support my use case, which involves sysex messages of 264 bytes. This seems to work fine.

Looking for feedback on what to do to fix this. I can spend some time on it.
Other people have run into this limitation:
https://linuxmusicians.com/viewtopic.php?t=25434

The core issue seems to be the size of the ring buffer, which should probably be configurable via command line options.

Additionally it is probably wise to make the ring buffer elements variable size.