MIDI Input not possible: "[midi-input]: in-bus data line error"

Question

MIDI Input not possible: "[midi-input]: in-bus data line error"

chrneumann opened this issue 3 years ago · 21 comments

I built the latest (dev and release) code from source together with rtmidi (i.e., default options). The problem is that I can't get MIDI input (output works fine) working. On startup (after enabling a MIDI input in the preferences), I get the following error:
[seq66] [midi-input]: in-bus data line error [seq66] rc: '[midi-input]: in-bus data line error' [seq66] [midi-input]: in-bus data line error

Wanted to try it with portmidi, but I get build errors.

Running on Linux with Jack. Seq24/64 and other MIDI software works fine.

Any suggestions?

Answer 1 · 2022-05-04T10:34:00.000Z

Tried it with 0.9.7.2.1, works fine.

Answer 2 · 2022-05-04T10:53:34.000Z

Glad that worked. Probably some corruption in the 'rc' file. You can either delete the 'rc' or change the [midi-input] count to 0, delete all the input port lines, restart Seq66, accept the error, then quit, the restart Seq66 and it should work. By the way, is this a distro package or building from code? The current master is 0.98.6.... The portmidi build is only for testing under linux before attempting a build in Windows (which is done via qmake with a batch file in the nsis directory). Will check out the --enable-portmidi flag, though. Thanks!

…

-------- Christian Neumann 03:34 Wed 04 May --------

Tried it with 0.9.7.2.1, works fine.

-- Save energy: be apathetic.

Answer 3 · 2022-05-04T11:28:27.000Z

Oh, I meant 0.97.2.1.
I built it again with 0.98.6 (tag) code from Github. The error is gone if I remove the rc (tried that before), but still I don't have any MIDI inputs. I guess normally it should be enabled in Preferences > MIDI Input > Input Buses? I do that (enable bus [1], which is my keyboard. Then I have to check and uncheck the "Record input..." option to have the "OK" button enabled. The MIDI input won't show up in Jack (Carlas' patchbay) as it does with 0.97. If I restart seq66, I get the error again.

Answer 4 · 2022-05-04T11:36:53.000Z

Odd as heck. Can you paste the contents of the broken qseq66.rc's [midi-input] section here? Also, are you using ALSA or JACK? For JACK and USB hardware the a2jmidid daemon needs to be running (unless your version of JACK) supports aliased ports. The jack_lsp command should list the ports it sees. Adding the -A flag shows the aliases, if any (there are none on my Ubuntu 20 system). Currently, if you enable a port from the GUI, you have to restart Seq66 to use it, an issue I have started working on, but not finished. Sorry about all the issues!

…

-------- Christian Neumann 04:28 Wed 04 May --------

Oh, I meant 0.97.2.1. I built it again with 0.98.6 (tag) code from Github. The error is gone if I remove the rc (tried that before), but still I don't have any MIDI inputs. I guess normally it should be enabled in Preferences > MIDI Input > Input Buses? I do that (enable bus [1], which is my keyboard. Then I have to check and uncheck the "Record input..." option to have the "OK" button enabled. The MIDI input won't show up in Jack (Carlas' patchbay) as it does with 0.97. If I restart seq66, I get the error again.

Answer 5 · 2022-05-04T11:45:12.000Z

I'm using JACK and USB hardware. There is no a2jmidid running, but Cadence (with which I start JACK) has a ALSA MIDI Bridge enabled.

jack_lsp lists:

a2j:Midi Through [14] (capture): Midi Through Port-0
a2j:Midi Through [14] (playback): Midi Through Port-0
a2j:KeyRig 49 [20] (capture): KeyRig 49 MIDI 1
a2j:XONE:K2 [24] (capture): XONE:K2 
a2j:XONE:K2 [24] (playback): XONE:K2

The rc:

[midi-input]

 4      # number of input MIDI buses

 0  0   "[0] 0:0 a2j:Midi Through [14] (capture): Midi Through Port-0"
 1  0   "[1] 0:1 a2j:KeyRig 49 [20] (capture): KeyRig 49 MIDI 1"
 2  0   "[2] 0:2 a2j:XONE:K2 [24] (capture): XONE:K2 "
 3  0   "[3] 1:3 Output:events-out"

Thanks for the quick support :)

Answer 6 · 2022-05-04T13:02:08.000Z

I used your snippet and figured out that it is a parsing error in this line: 2 0 "[2] 0:2 a2j:XONE:K2 [24] (capture): XONE:K2 " That excess space at the end is one issue. It'll take me awhile to fix it without breaking something.

…

-------- Christian Neumann 04:45 Wed 04 May --------

Answer 7 · 2022-05-04T13:02:33.000Z

I'm trying the latest versions to see which introduced the bug. 0.98.2 works.

Answer 8 · 2022-05-04T13:39:49.000Z

Okay, that's also the latest version that works for me.

Answer 9 · 2022-07-17T19:53:42.000Z

I confirm that midi controls (in and out) do nor work in 0.98.6. I checked out 0.98.2 and it works for me (Linux, ALSA midi, built from source). Also, there seems to be a regression regarding the saving and restoring of the midi control in and out buses (works fine in 0.98.2, but needs to be set manually in the GUI at every start in 0.98.6).

Answer 10 · 2022-07-17T20:39:58.000Z

Oh wait, actually only MIDI (control automation) output works, input still doesn't (with 0.98.2). Any hints? This is quite an important feature for me, otherwise I cannot use seq66 for my live set. :-/

Answer 11 · 2022-07-18T11:10:43.000Z

Hmmm, it works for me, but getting it set back up was tricky. I had to go to Edit / Preferences / Clocks and Input and make sure the Launchpad was selected for both. Then I had to go into the 'ctrl' file and make sure that "midi-enabled" was set for both. Based on that, I will make some GUI improvements for upcoming version 0.98.10.

…

-- Q: Why did the programmer call his mother long distance? A: Because that was her name.

Answer 12 · 2022-07-18T11:45:33.000Z

Also, can you post (or donate to the project) your device's 'ctrl' file, so that I can debug and fix any issues that might be occurring with the parsing of the file? Thanks either way!

…

-------- Igor Angst 13:40 Sun 17 Jul --------

Answer 13 · 2022-07-18T15:34:23.000Z

The newest version is now in master and tagged: 0.98.10.

One nagging issue: clicking the checkbox for MIDI input or output controls doesn't save them properly, not sure why. The work-around for now is to not restart, but exit the app and restart the app, rather than clicking the restart button. Not sure what is up with that. Also check the "midi-enabled" flags in the 'ctrl' file.

Answer 14 · 2022-07-18T20:40:20.000Z

Hi, it seems MIDI input is working correctly with jack, but not with ALSA. For the moment, I can use jack, even if I'm more used to ALSA (and most of my applications use ALSA). Thanks for the quick reaction.

Answer 15 · 2022-07-18T21:45:49.000Z

I tested it on Alsa. It works. You have to account for the Alsa announce port, always port 0. Exposing that port was, in retrospect, an unfortunate move. It means that for input, port numbering differs by one. :-(

On Mon, Jul 18, 2022 at 16:40 Igor Angst ***@***.***> wrote: Hi, it seems MIDI input is working correctly with jack, but not with ALSA. For the moment, I can use jack, even if I'm more used to ALSA (and most of my applications use ALSA). Thanks for the quick reaction. — Reply to this email directly, view it on GitHub <#83 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB45LKDJ6D2XLIBRWLQ2Z23VUW6L5ANCNFSM5VBN6EMA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Chris Ahlstrom

Answer 16 · 2022-07-19T19:28:25.000Z

OK, really sorry to keep this thread going....

I am very confused now. I checkout out and compiled 0.98.10.

ALSA still does nothing. I do not understand how the whole auto connect business works, I only use virtual ports (with both ALSA and Jack) and wire them up using a patchbay tool (qjackctl). So in this case, the names or numbers of the ports should not matter (they are all named "midi in 0", "midi in 1" etc), right?

So I connect a controller (or for testing just a virtual keyboard) to one of the input ports, then I select this input port as the control input in the seq66 gui. WIth ALSA (launched with qseq66 -A -m), nothing happens, even if I wire the control keyboard to all the input ports at once.

Doing the same thing with Jack works. Again, I do not use auto-connect (qseq -t -w) and wire it up with my patch bay. So far so good.

I have another issue with the MIDI output : I never get queue events, only on and off events, even with the queue modifier on. Is this normal behavior?

Any help appreciated :-)

Answer 17 · 2022-07-20T10:56:34.000Z

Okay, I see the issue. First, auto-connect works by getting all the MIDI input and output ports that exist in the system. Once they are obtained, Seq66 makes its own corresponding ports, and then connects them to the existing ports. Then the performer object is "launched". With virtual ports connected after the fact, launch has already occurred. So I will have to see about belaying launch until virtual ports are all connected. Sounds tricky; I hadn't dealt with that use case. I think JACK handles it better internally. As for the ALSA queue, hadn't paid much attention to that, you are the first to complain. So I have some research to do. Fun stuff!

Answer 18 · 2022-07-20T16:56:55.000Z

Thanks for assuring me that I was not hallucinating :-)

Gonna try out ALSA with auto-connect, although it doesn't really integrate into my workflow. Otherwise, I'm gonna stick with Jack MIDI for the moment. Lastly, let me investigate on the queue output. I will open a separate issue if the problem is confirmed.

Let me know if I can beta-test some other features, seems that my setup is not so common :-)

Answer 19 · 2022-07-20T21:27:05.000Z

It's not that uncommon. See #60. As far as I grok, there are two classes of users; those who desire a 'lightweight' experience and just want to use the app with their hardware and not any other software and need things to just start inputting/outputting, and people invested in joining together MIDI apps and plugins in a more complex system (most often, in this day and age, using a dedicated patchbay app). Afaiu seq66 has inherited default behaviour orientated toward the first group.

Answer 20 · 2022-07-22T15:33:24.000Z

Okay, I fixed a few aspects of displaying the playing, queuing, muted, and removed/empty/deleted status, and so one should see this when patterns are present and playing: Empty slot: dark Muted slot: red Playing slot: green Queued slot: amber (this means the slot is queued to turn on) Unqueued slot: amber (this means the slot is queued to turn off) Also fixed some minor irregularities with handling the 'ctrl' file.

Answer 21 · 2023-06-27T23:57:02.000Z

I have done a lot of refactoring of the handling of ports and port-mapping. So if issues crop up, probably calls for another issue creation. So closing this one. Amazing how many tweaks are needed when refactoring! In any case, keep reporting! I'll get it right eventually! :-)