Hi Albert,

Nice to hear from you!  I looked at the code mentioned and it seems
fine to me to ignore -ENOENT.  The way I understand it, sequencer
events are not just MIDI events, so when -ENOENT is found, it's saying
"You're trying to decode this event as MIDI.  The event is indeed a
valid sequencer event, but it just doesn't happen to be a MIDI one".
The documentation for snd_midi_event_decode():

http://www.alsa-project.org/alsa-doc/alsa-lib/group___m_i_d_i___event.html#ga9ef018a85ec7f61d45d8b17083bf8cc3

lists which seq events map to MIDI.  So... I'd be in favor of the code
change proposed.

Victor: +1?

steven



On Fri, Oct 13, 2017 at 3:13 PM, Albert Graef  wrote:
> Hi everybody,
>
> my first post to this list, so please bear with me. :)
>
> I'm currently working through the excellent new Csound book (congrats to
> Victor, Steven, John and all the others who contributed, it's a very nice
> read!), running Csound version 6.09.1 (double samples) on Arch Linux
> (Manjaro, actually).
>
> I know that this has been reported before
> (https://github.com/csound/csound/issues/503), but I keep getting these
> annoying "error reading MIDI device: -2 (Unknown MIDI error)" messages
> whenever csound starts up with an alsaseq rtmidi device. It doesn't matter
> what device it is (I've tried various keyboards connected either directly
> through USB or through an USB-MIDI interface). The devices work with
> csound's alsa (rawmidi) and portmidi interfaces without any hitches, and
> they also seem to work fine with any other ALSA sequencer apps I've tried.
> Also, kmidimon doesn't report any erroneous events either when it's hooked
> up to the devices, so I'm pretty sure that those -2 status codes reported in
> csound are no real errors (I know for sure that kmidimon *does* report
> malformed MIDI messages it sees in its input).
>
> That error code obviously comes from the call to snd_midi_event_decode() in
> rtalsa.c:1447, specifically from one of the 'return -ENOENT' statements in
> ALSA's seq_midi_event.c. But as you can see in the ALSA code there (the docs
> are a bit sparse on this), this return code just is ALSA's way of saying
> "nothing to see here, move along". What's particularly suspicious to me is
> that this error message happens exactly twice after csound connects to the
> device, so it might well be those ALSA port subscription events that you can
> see, e.g., in kmidimon when you hook it up to an ALSA sequencer device. So
> my take is that this specific error code should just be ignored, i.e., the
> return statement at the end of alsaseq_in_read() at rtalsa.c:1448 should
> probably be something like this:
>
>     return (err==-ENOENT)?0:err;
>
> Victor, in https://github.com/csound/csound/issues/503 you noted that you
> consider this ENOENT error genuine? As I detailed above, I don't think it
> is, but I may be wrong. We can only be really sure if we actually take a
> look at the snd_midi_event_t struct which causes this specific error.
>
> Unfortunately, I don't have the time to dive into the code right now, would
> anyone else take to care a look? Or maybe just commit the workaround I
> suggested. I don't think that it will do any harm, whereas that error
> message looks kind of scary to me. ;-)
>
> TIA,
> Albert
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email:  aggraef@gmail.com
> WWW:    https://plus.google.com/+AlbertGraef
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Yes, we should bow to the experience here and do as you suggest.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 13 Oct 2017, at 20:42, Steven Yi  wrote:
> 
> Hi Albert,
> 
> Nice to hear from you!  I looked at the code mentioned and it seems
> fine to me to ignore -ENOENT.  The way I understand it, sequencer
> events are not just MIDI events, so when -ENOENT is found, it's saying
> "You're trying to decode this event as MIDI.  The event is indeed a
> valid sequencer event, but it just doesn't happen to be a MIDI one".
> The documentation for snd_midi_event_decode():
> 
> http://www.alsa-project.org/alsa-doc/alsa-lib/group___m_i_d_i___event.html#ga9ef018a85ec7f61d45d8b17083bf8cc3
> 
> lists which seq events map to MIDI.  So... I'd be in favor of the code
> change proposed.
> 
> Victor: +1?
> 
> steven
> 
> 
> 
>> On Fri, Oct 13, 2017 at 3:13 PM, Albert Graef  wrote:
>> Hi everybody,
>> 
>> my first post to this list, so please bear with me. :)
>> 
>> I'm currently working through the excellent new Csound book (congrats to
>> Victor, Steven, John and all the others who contributed, it's a very nice
>> read!), running Csound version 6.09.1 (double samples) on Arch Linux
>> (Manjaro, actually).
>> 
>> I know that this has been reported before
>> (https://github.com/csound/csound/issues/503), but I keep getting these
>> annoying "error reading MIDI device: -2 (Unknown MIDI error)" messages
>> whenever csound starts up with an alsaseq rtmidi device. It doesn't matter
>> what device it is (I've tried various keyboards connected either directly
>> through USB or through an USB-MIDI interface). The devices work with
>> csound's alsa (rawmidi) and portmidi interfaces without any hitches, and
>> they also seem to work fine with any other ALSA sequencer apps I've tried.
>> Also, kmidimon doesn't report any erroneous events either when it's hooked
>> up to the devices, so I'm pretty sure that those -2 status codes reported in
>> csound are no real errors (I know for sure that kmidimon *does* report
>> malformed MIDI messages it sees in its input).
>> 
>> That error code obviously comes from the call to snd_midi_event_decode() in
>> rtalsa.c:1447, specifically from one of the 'return -ENOENT' statements in
>> ALSA's seq_midi_event.c. But as you can see in the ALSA code there (the docs
>> are a bit sparse on this), this return code just is ALSA's way of saying
>> "nothing to see here, move along". What's particularly suspicious to me is
>> that this error message happens exactly twice after csound connects to the
>> device, so it might well be those ALSA port subscription events that you can
>> see, e.g., in kmidimon when you hook it up to an ALSA sequencer device. So
>> my take is that this specific error code should just be ignored, i.e., the
>> return statement at the end of alsaseq_in_read() at rtalsa.c:1448 should
>> probably be something like this:
>> 
>>    return (err==-ENOENT)?0:err;
>> 
>> Victor, in https://github.com/csound/csound/issues/503 you noted that you
>> consider this ENOENT error genuine? As I detailed above, I don't think it
>> is, but I may be wrong. We can only be really sure if we actually take a
>> look at the snd_midi_event_t struct which causes this specific error.
>> 
>> Unfortunately, I don't have the time to dive into the code right now, would
>> anyone else take to care a look? Or maybe just commit the workaround I
>> suggested. I don't think that it will do any harm, whereas that error
>> message looks kind of scary to me. ;-)
>> 
>> TIA,
>> Albert
>> 
>> --
>> Dr. Albert Gr"af
>> Computer Music Research Group, JGU Mainz, Germany
>> Email:  aggraef@gmail.com
>> WWW:    https://plus.google.com/+AlbertGraef
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Albert,

Since Victor was +1 and you've tested it there, and since this is just
a small one-liner, I went ahead and applied the change and attributed
it to you in the commit message:

https://github.com/csound/csound/commit/418fd15f591d5333958c0bddf6417d02cd5a1316

In general PRs work great for us, though!

Thanks!
steven

On Fri, Oct 13, 2017 at 3:53 PM, Albert Graef  wrote:
> Hi Steven,
>
> long time no see, how you're doing? :)
>
> Just for the record, I've tested the suggested change on top of both the
> current git and the 6.09.1 release, works fine for me. Patch against current
> HEAD attached, or would you like me to submit a pull request?
>
> Best,
> Albert
>
> On Fri, Oct 13, 2017 at 9:42 PM, Steven Yi  wrote:
>>
>> Hi Albert,
>>
>> Nice to hear from you!  I looked at the code mentioned and it seems
>> fine to me to ignore -ENOENT.  The way I understand it, sequencer
>> events are not just MIDI events, so when -ENOENT is found, it's saying
>> "You're trying to decode this event as MIDI.  The event is indeed a
>> valid sequencer event, but it just doesn't happen to be a MIDI one".
>> The documentation for snd_midi_event_decode():
>>
>>
>> http://www.alsa-project.org/alsa-doc/alsa-lib/group___m_i_d_i___event.html#ga9ef018a85ec7f61d45d8b17083bf8cc3
>>
>> lists which seq events map to MIDI.  So... I'd be in favor of the code
>> change proposed.
>>
>> Victor: +1?
>>
>> steven
>>
>>
>>
>> On Fri, Oct 13, 2017 at 3:13 PM, Albert Graef  wrote:
>> > Hi everybody,
>> >
>> > my first post to this list, so please bear with me. :)
>> >
>> > I'm currently working through the excellent new Csound book (congrats to
>> > Victor, Steven, John and all the others who contributed, it's a very
>> > nice
>> > read!), running Csound version 6.09.1 (double samples) on Arch Linux
>> > (Manjaro, actually).
>> >
>> > I know that this has been reported before
>> > (https://github.com/csound/csound/issues/503), but I keep getting these
>> > annoying "error reading MIDI device: -2 (Unknown MIDI error)" messages
>> > whenever csound starts up with an alsaseq rtmidi device. It doesn't
>> > matter
>> > what device it is (I've tried various keyboards connected either
>> > directly
>> > through USB or through an USB-MIDI interface). The devices work with
>> > csound's alsa (rawmidi) and portmidi interfaces without any hitches, and
>> > they also seem to work fine with any other ALSA sequencer apps I've
>> > tried.
>> > Also, kmidimon doesn't report any erroneous events either when it's
>> > hooked
>> > up to the devices, so I'm pretty sure that those -2 status codes
>> > reported in
>> > csound are no real errors (I know for sure that kmidimon *does* report
>> > malformed MIDI messages it sees in its input).
>> >
>> > That error code obviously comes from the call to snd_midi_event_decode()
>> > in
>> > rtalsa.c:1447, specifically from one of the 'return -ENOENT' statements
>> > in
>> > ALSA's seq_midi_event.c. But as you can see in the ALSA code there (the
>> > docs
>> > are a bit sparse on this), this return code just is ALSA's way of saying
>> > "nothing to see here, move along". What's particularly suspicious to me
>> > is
>> > that this error message happens exactly twice after csound connects to
>> > the
>> > device, so it might well be those ALSA port subscription events that you
>> > can
>> > see, e.g., in kmidimon when you hook it up to an ALSA sequencer device.
>> > So
>> > my take is that this specific error code should just be ignored, i.e.,
>> > the
>> > return statement at the end of alsaseq_in_read() at rtalsa.c:1448 should
>> > probably be something like this:
>> >
>> >     return (err==-ENOENT)?0:err;
>> >
>> > Victor, in https://github.com/csound/csound/issues/503 you noted that
>> > you
>> > consider this ENOENT error genuine? As I detailed above, I don't think
>> > it
>> > is, but I may be wrong. We can only be really sure if we actually take a
>> > look at the snd_midi_event_t struct which causes this specific error.
>> >
>> > Unfortunately, I don't have the time to dive into the code right now,
>> > would
>> > anyone else take to care a look? Or maybe just commit the workaround I
>> > suggested. I don't think that it will do any harm, whereas that error
>> > message looks kind of scary to me. ;-)
>> >
>> > TIA,
>> > Albert
>> >
>> > --
>> > Dr. Albert Gr"af
>> > Computer Music Research Group, JGU Mainz, Germany
>> > Email:  aggraef@gmail.com
>> > WWW:    https://plus.google.com/+AlbertGraef
>> > Csound mailing list Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> > https://github.com/csound/csound/issues Discussions of bugs and features
>> > can
>> > be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
>
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email:  aggraef@gmail.com
> WWW:    https://plus.google.com/+AlbertGraef
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here