---
** [bugs:#1272] midiout not working correctly on ALSA**
**Status:** open **Group:** v0.47 **Created:** Sun Oct 16, 2016 05:17 PM UTC by Albert Graef **Last Updated:** Sun Oct 16, 2016 05:17 PM UTC **Owner:** Miller Puckette
This has been there forever, and affects all Linux systems when using ALSA MIDI devices.
sys_alsa_putmidibyte() in s_midi_alsa.c outputs individual bytes instead of complete MIDI messages. You can clearly see this, e.g., when sending a sysex message from Pd to an ALSA MIDI output and looking at the results in kmidimon. Instead of a proper sysex message you'll get a sequence of (malformed) single-byte messages.
You can't just output single bytes of a multi-byte MIDI message with snd_seq_event_output_direct(), this only works with single-byte (such as system realtime) messages. The proper way to do this, so that it works with any MIDI message, is to use snd_midi_event_encode_byte() and output the message when it's complete. The following fix is from the pd-l2ork repo, but it should apply cleanly on the current pure-data master branch: https://github.com/pd-l2ork/pd/commit/9f5a265
---
Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Out of curiosity, is it not up to the receiving device to parse the received bytes in such a way that they form a coherent message? Or is there a "timeout" after which a sysex message is considered aborted ?I don't remember the latter from the specs, so I always assumed the former.Giulio
From: Albert Graef agraef@users.sf.net To: pd-dev@lists.iem.at Sent: Sunday, 16 October 2016, 18:17 Subject: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
[bugs:#1272] midiout not working correctly on ALSAStatus: open Group: v0.47 Created: Sun Oct 16, 2016 05:17 PM UTC by Albert Graef Last Updated: Sun Oct 16, 2016 05:17 PM UTC Owner: Miller PucketteThis has been there forever, and affects all Linux systems when using ALSA MIDI devices.sys_alsa_putmidibyte() in s_midi_alsa.c outputs individual bytes instead of complete MIDI messages. You can clearly see this, e.g., when sending a sysex message from Pd to an ALSA MIDI output and looking at the results in kmidimon. Instead of a proper sysex message you'll get a sequence of (malformed) single-byte messages.You can't just output single bytes of a multi-byte MIDI message with snd_seq_event_output_direct(), this only works with single-byte (such as system realtime) messages. The proper way to do this, so that it works with any MIDI message, is to use snd_midi_event_encode_byte() and output the message when it's complete. The following fix is from the pd-l2ork repo, but it should apply cleanly on the current pure-data master branch: https://github.com/pd-l2ork/pd/commit/9f5a265Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hi Giulio,
no, AFAICT that's not the way ALSA works. I haven't really looked in the ALSA code, but it seems that assembling the MIDI messages has to be done using the corresponding sequencer API calls. There might be some drivers which handle this, but I never had this working properly when outputting sysex using either internal ALSA connections or external MIDI gear via a USB-MIDI device.
All I can say is that the suggested patch seems to be the right way to do this (those API calls are there for a reason), and that it works for me with every MIDI equipment I tried it with.
Albert
On Sun, Oct 16, 2016 at 7:25 PM, Giulio Moro via Pd-dev <pd-dev@lists.iem.at
wrote:
Out of curiosity, is it not up to the receiving device to parse the received bytes in such a way that they form a coherent message? Or is there a "timeout" after which a sysex message is considered aborted ? I don't remember the latter from the specs, so I always assumed the former. Giulio
*From:* Albert Graef agraef@users.sf.net *To:* pd-dev@lists.iem.at *Sent:* Sunday, 16 October 2016, 18:17 *Subject:* [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
- [bugs:#1272] https://sourceforge.net/p/pure-data/bugs/1272/ midiout
not working correctly on ALSA* *Status:* open *Group:* v0.47 *Created:* Sun Oct 16, 2016 05:17 PM UTC by Albert Graef *Last Updated:* Sun Oct 16, 2016 05:17 PM UTC *Owner:* Miller Puckette This has been there forever, and affects all Linux systems when using ALSA MIDI devices. sys_alsa_putmidibyte() in s_midi_alsa.c outputs individual bytes instead of complete MIDI messages. You can clearly see this, e.g., when sending a sysex message from Pd to an ALSA MIDI output and looking at the results in kmidimon. Instead of a proper sysex message you'll get a sequence of (malformed) single-byte messages. You can't just output single bytes of a multi-byte MIDI message with snd_seq_event_output_direct(), this only works with single-byte (such as system realtime) messages. The proper way to do this, so that it works with any MIDI message, is to use snd_midi_event_encode_byte() and output the message when it's complete. The following fix is from the pd-l2ork repo, but it should apply cleanly on the current pure-data master branch: https://github.com/pd-l2ork/pd/commit/9f5a265
Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Thanks.Did the previous implementation fail with all your devices or only with some of them?Best,Giulio
From: Albert Graef aggraef@gmail.com To: Giulio Moro giuliomoro@yahoo.it Cc: Ticket 1272 1272@bugs.pure-data.p.re.sf.net; "pd-dev@lists.iem.at" pd-dev@lists.iem.at Sent: Sunday, 16 October 2016, 19:08 Subject: Re: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
Hi Giulio,
no, AFAICT that's not the way ALSA works. I haven't really looked in the ALSA code, but it seems that assembling the MIDI messages has to be done using the corresponding sequencer API calls. There might be some drivers which handle this, but I never had this working properly when outputting sysex using either internal ALSA connections or external MIDI gear via a USB-MIDI device.
All I can say is that the suggested patch seems to be the right way to do this (those API calls are there for a reason), and that it works for me with every MIDI equipment I tried it with.
Albert On Sun, Oct 16, 2016 at 7:25 PM, Giulio Moro via Pd-dev pd-dev@lists.iem.at wrote:
Out of curiosity, is it not up to the receiving device to parse the received bytes in such a way that they form a coherent message? Or is there a "timeout" after which a sysex message is considered aborted ?I don't remember the latter from the specs, so I always assumed the former.Giulio
From: Albert Graef agraef@users.sf.net To: pd-dev@lists.iem.at Sent: Sunday, 16 October 2016, 18:17 Subject: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
[bugs:#1272] midiout not working correctly on ALSAStatus: open Group: v0.47 Created: Sun Oct 16, 2016 05:17 PM UTC by Albert Graef Last Updated: Sun Oct 16, 2016 05:17 PM UTC Owner: Miller PucketteThis has been there forever, and affects all Linux systems when using ALSA MIDI devices.sys_alsa_putmidibyte() in s_midi_alsa.c outputs individual bytes instead of complete MIDI messages. You can clearly see this, e.g., when sending a sysex message from Pd to an ALSA MIDI output and looking at the results in kmidimon. Instead of a proper sysex message you'll get a sequence of (malformed) single-byte messages.You can't just output single bytes of a multi-byte MIDI message with snd_seq_event_output_direct(), this only works with single-byte (such as system realtime) messages. The proper way to do this, so that it works with any MIDI message, is to use snd_midi_event_encode_byte() and output the message when it's complete. The following fix is from the pd-l2ork repo, but it should apply cleanly on the current pure-data master branch: https://github.com/pd-l2ork/ pd/commit/9f5a265Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to https://sourceforge.net/p/ pure-data/bugs/To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/ pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. ______________________________ _________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev
______________________________ _________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev
sorry I read your message again and found the answer to the latest question, so I have a new one, if you don't mind:in kmidimon did you see ALL of your bytes coming through or only some of them? My point is: I believe that if you send bytes over an old-style MIDI connector, it should not matter how spaced in time they are: the receiver should be able to reconstruct the message. I expect that the same should happen for software connections. So, if bytes are dropped because of improper use of the API, then I understand the issue.But I would struggle to understand why it should fail if all the bytes are actually delivered. I must say that a long time ago I was successfully controlling a Roland Sound Canvas over sysex generated in Pd-Extended 0.43. Best,Giulio
From: Albert Graef aggraef@gmail.com To: Giulio Moro giuliomoro@yahoo.it Cc: Ticket 1272 1272@bugs.pure-data.p.re.sf.net; "pd-dev@lists.iem.at" pd-dev@lists.iem.at Sent: Sunday, 16 October 2016, 19:08 Subject: Re: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
Hi Giulio,
no, AFAICT that's not the way ALSA works. I haven't really looked in the ALSA code, but it seems that assembling the MIDI messages has to be done using the corresponding sequencer API calls. There might be some drivers which handle this, but I never had this working properly when outputting sysex using either internal ALSA connections or external MIDI gear via a USB-MIDI device.
All I can say is that the suggested patch seems to be the right way to do this (those API calls are there for a reason), and that it works for me with every MIDI equipment I tried it with.
Albert On Sun, Oct 16, 2016 at 7:25 PM, Giulio Moro via Pd-dev pd-dev@lists.iem.at wrote:
Out of curiosity, is it not up to the receiving device to parse the received bytes in such a way that they form a coherent message? Or is there a "timeout" after which a sysex message is considered aborted ?I don't remember the latter from the specs, so I always assumed the former.Giulio
From: Albert Graef agraef@users.sf.net To: pd-dev@lists.iem.at Sent: Sunday, 16 October 2016, 18:17 Subject: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
[bugs:#1272] midiout not working correctly on ALSAStatus: open Group: v0.47 Created: Sun Oct 16, 2016 05:17 PM UTC by Albert Graef Last Updated: Sun Oct 16, 2016 05:17 PM UTC Owner: Miller PucketteThis has been there forever, and affects all Linux systems when using ALSA MIDI devices.sys_alsa_putmidibyte() in s_midi_alsa.c outputs individual bytes instead of complete MIDI messages. You can clearly see this, e.g., when sending a sysex message from Pd to an ALSA MIDI output and looking at the results in kmidimon. Instead of a proper sysex message you'll get a sequence of (malformed) single-byte messages.You can't just output single bytes of a multi-byte MIDI message with snd_seq_event_output_direct(), this only works with single-byte (such as system realtime) messages. The proper way to do this, so that it works with any MIDI message, is to use snd_midi_event_encode_byte() and output the message when it's complete. The following fix is from the pd-l2ork repo, but it should apply cleanly on the current pure-data master branch: https://github.com/pd-l2ork/ pd/commit/9f5a265Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to https://sourceforge.net/p/ pure-data/bugs/To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/ pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. ______________________________ _________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev
______________________________ _________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev
It would be a problem if there are other MIDI messages being sent, say from [noteout] or [ctlout], while the sysex message is dribbling out.
Martin
On Sun, Oct 16, 2016 at 2:27 PM, Giulio Moro via Pd-dev <pd-dev@lists.iem.at
wrote:
sorry I read your message again and found the answer to the latest question, so I have a new one, if you don't mind: in kmidimon did you see ALL of your bytes coming through or only some of them?
My point is: I believe that if you send bytes over an old-style MIDI connector, it should not matter how spaced in time they are: the receiver should be able to reconstruct the message. I expect that the same should happen for software connections. So, if bytes are dropped because of improper use of the API, then I understand the issue. But I would struggle to understand why it should fail if all the bytes are actually delivered.
I must say that a long time ago I was successfully controlling a Roland Sound Canvas over sysex generated in Pd-Extended 0.43.
Best, Giulio
*From:* Albert Graef aggraef@gmail.com *To:* Giulio Moro giuliomoro@yahoo.it *Cc:* Ticket 1272 1272@bugs.pure-data.p.re.sf.net; "pd-dev@lists.iem.at" pd-dev@lists.iem.at *Sent:* Sunday, 16 October 2016, 19:08 *Subject:* Re: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
Hi Giulio,
no, AFAICT that's not the way ALSA works. I haven't really looked in the ALSA code, but it seems that assembling the MIDI messages has to be done using the corresponding sequencer API calls. There might be some drivers which handle this, but I never had this working properly when outputting sysex using either internal ALSA connections or external MIDI gear via a USB-MIDI device.
All I can say is that the suggested patch seems to be the right way to do this (those API calls are there for a reason), and that it works for me with every MIDI equipment I tried it with.
Albert
On Sun, Oct 16, 2016 at 7:25 PM, Giulio Moro via Pd-dev < pd-dev@lists.iem.at> wrote:
Out of curiosity, is it not up to the receiving device to parse the received bytes in such a way that they form a coherent message? Or is there a "timeout" after which a sysex message is considered aborted ? I don't remember the latter from the specs, so I always assumed the former. Giulio
*From:* Albert Graef agraef@users.sf.net *To:* pd-dev@lists.iem.at *Sent:* Sunday, 16 October 2016, 18:17 *Subject:* [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
- [bugs:#1272] https://sourceforge.net/p/pure-data/bugs/1272/ midiout
not working correctly on ALSA* *Status:* open *Group:* v0.47 *Created:* Sun Oct 16, 2016 05:17 PM UTC by Albert Graef *Last Updated:* Sun Oct 16, 2016 05:17 PM UTC *Owner:* Miller Puckette This has been there forever, and affects all Linux systems when using ALSA MIDI devices. sys_alsa_putmidibyte() in s_midi_alsa.c outputs individual bytes instead of complete MIDI messages. You can clearly see this, e.g., when sending a sysex message from Pd to an ALSA MIDI output and looking at the results in kmidimon. Instead of a proper sysex message you'll get a sequence of (malformed) single-byte messages. You can't just output single bytes of a multi-byte MIDI message with snd_seq_event_output_direct(), this only works with single-byte (such as system realtime) messages. The proper way to do this, so that it works with any MIDI message, is to use snd_midi_event_encode_byte() and output the message when it's complete. The following fix is from the pd-l2ork repo, but it should apply cleanly on the current pure-data master branch: https://github.com/pd-l2ork/ pd/commit/9f5a265
https://github.com/pd-l2ork/pd/commit/9f5a265
Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to https://sourceforge.net/p/ pure-data/bugs/ https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/ pure-data/admin/bugs/options. https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
-- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggraef@gmail.com WWW: https://plus.google.com/+AlbertGraef
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
The bytes all come through, but they're not being recognized as a single message. Same with other ALSA sequencer clients such as fluidsynth. Depending on the client, it will then just throw away these single byte messages or, worse, misinterpret them. I suspect that the same happens in the USB-MIDI driver.
On Sun, Oct 16, 2016 at 8:27 PM, Giulio Moro giuliomoro@yahoo.it wrote:
sorry I read your message again and found the answer to the latest question, so I have a new one, if you don't mind: in kmidimon did you see ALL of your bytes coming through or only some of them?
My point is: I believe that if you send bytes over an old-style MIDI connector, it should not matter how spaced in time they are: the receiver should be able to reconstruct the message. I expect that the same should happen for software connections. So, if bytes are dropped because of improper use of the API, then I understand the issue. But I would struggle to understand why it should fail if all the bytes are actually delivered.
I must say that a long time ago I was successfully controlling a Roland Sound Canvas over sysex generated in Pd-Extended 0.43.
Best, Giulio
*From:* Albert Graef aggraef@gmail.com *To:* Giulio Moro giuliomoro@yahoo.it *Cc:* Ticket 1272 1272@bugs.pure-data.p.re.sf.net; "pd-dev@lists.iem.at" pd-dev@lists.iem.at *Sent:* Sunday, 16 October 2016, 19:08 *Subject:* Re: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
Hi Giulio,
no, AFAICT that's not the way ALSA works. I haven't really looked in the ALSA code, but it seems that assembling the MIDI messages has to be done using the corresponding sequencer API calls. There might be some drivers which handle this, but I never had this working properly when outputting sysex using either internal ALSA connections or external MIDI gear via a USB-MIDI device.
All I can say is that the suggested patch seems to be the right way to do this (those API calls are there for a reason), and that it works for me with every MIDI equipment I tried it with.
Albert
On Sun, Oct 16, 2016 at 7:25 PM, Giulio Moro via Pd-dev < pd-dev@lists.iem.at> wrote:
Out of curiosity, is it not up to the receiving device to parse the received bytes in such a way that they form a coherent message? Or is there a "timeout" after which a sysex message is considered aborted ? I don't remember the latter from the specs, so I always assumed the former. Giulio
*From:* Albert Graef agraef@users.sf.net *To:* pd-dev@lists.iem.at *Sent:* Sunday, 16 October 2016, 18:17 *Subject:* [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
- [bugs:#1272] https://sourceforge.net/p/pure-data/bugs/1272/ midiout
not working correctly on ALSA* *Status:* open *Group:* v0.47 *Created:* Sun Oct 16, 2016 05:17 PM UTC by Albert Graef *Last Updated:* Sun Oct 16, 2016 05:17 PM UTC *Owner:* Miller Puckette This has been there forever, and affects all Linux systems when using ALSA MIDI devices. sys_alsa_putmidibyte() in s_midi_alsa.c outputs individual bytes instead of complete MIDI messages. You can clearly see this, e.g., when sending a sysex message from Pd to an ALSA MIDI output and looking at the results in kmidimon. Instead of a proper sysex message you'll get a sequence of (malformed) single-byte messages. You can't just output single bytes of a multi-byte MIDI message with snd_seq_event_output_direct(), this only works with single-byte (such as system realtime) messages. The proper way to do this, so that it works with any MIDI message, is to use snd_midi_event_encode_byte() and output the message when it's complete. The following fix is from the pd-l2ork repo, but it should apply cleanly on the current pure-data master branch: https://github.com/pd-l2ork/ pd/commit/9f5a265
https://github.com/pd-l2ork/pd/commit/9f5a265
Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to https://sourceforge.net/p/ pure-data/bugs/ https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/ pure-data/admin/bugs/options. https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
-- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggraef@gmail.com WWW: https://plus.google.com/+AlbertGraef
I see. It makes completely sense to me if other messages get interleaved within the bytes of sysex message, does not make much sense otherwise.I guess if I'll have some time I'll look into this oddity (or maybe just re-read the specifications and find out if/why this is expected!)ThanksGiulio
From: Albert Graef aggraef@gmail.com To: Giulio Moro giuliomoro@yahoo.it Cc: Ticket 1272 1272@bugs.pure-data.p.re.sf.net; "pd-dev@lists.iem.at" pd-dev@lists.iem.at Sent: Tuesday, 18 October 2016, 7:59 Subject: Re: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
The bytes all come through, but they're not being recognized as a single message. Same with other ALSA sequencer clients such as fluidsynth. Depending on the client, it will then just throw away these single byte messages or, worse, misinterpret them. I suspect that the same happens in the USB-MIDI driver.
On Sun, Oct 16, 2016 at 8:27 PM, Giulio Moro giuliomoro@yahoo.it wrote:
sorry I read your message again and found the answer to the latest question, so I have a new one, if you don't mind:in kmidimon did you see ALL of your bytes coming through or only some of them? My point is: I believe that if you send bytes over an old-style MIDI connector, it should not matter how spaced in time they are: the receiver should be able to reconstruct the message. I expect that the same should happen for software connections. So, if bytes are dropped because of improper use of the API, then I understand the issue.But I would struggle to understand why it should fail if all the bytes are actually delivered. I must say that a long time ago I was successfully controlling a Roland Sound Canvas over sysex generated in Pd-Extended 0.43. Best,Giulio
From: Albert Graef aggraef@gmail.com To: Giulio Moro giuliomoro@yahoo.it Cc: Ticket 1272 <1272@bugs.pure-data.p.re.sf. net>; "pd-dev@lists.iem.at" pd-dev@lists.iem.at Sent: Sunday, 16 October 2016, 19:08 Subject: Re: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
Hi Giulio,
no, AFAICT that's not the way ALSA works. I haven't really looked in the ALSA code, but it seems that assembling the MIDI messages has to be done using the corresponding sequencer API calls. There might be some drivers which handle this, but I never had this working properly when outputting sysex using either internal ALSA connections or external MIDI gear via a USB-MIDI device.
All I can say is that the suggested patch seems to be the right way to do this (those API calls are there for a reason), and that it works for me with every MIDI equipment I tried it with.
Albert On Sun, Oct 16, 2016 at 7:25 PM, Giulio Moro via Pd-dev pd-dev@lists.iem.at wrote:
Out of curiosity, is it not up to the receiving device to parse the received bytes in such a way that they form a coherent message? Or is there a "timeout" after which a sysex message is considered aborted ?I don't remember the latter from the specs, so I always assumed the former.Giulio
From: Albert Graef agraef@users.sf.net To: pd-dev@lists.iem.at Sent: Sunday, 16 October 2016, 18:17 Subject: [PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA
[bugs:#1272] midiout not working correctly on ALSAStatus: open Group: v0.47 Created: Sun Oct 16, 2016 05:17 PM UTC by Albert Graef Last Updated: Sun Oct 16, 2016 05:17 PM UTC Owner: Miller PucketteThis has been there forever, and affects all Linux systems when using ALSA MIDI devices.sys_alsa_putmidibyte() in s_midi_alsa.c outputs individual bytes instead of complete MIDI messages. You can clearly see this, e.g., when sending a sysex message from Pd to an ALSA MIDI output and looking at the results in kmidimon. Instead of a proper sysex message you'll get a sequence of (malformed) single-byte messages.You can't just output single bytes of a multi-byte MIDI message with snd_seq_event_output_direct(), this only works with single-byte (such as system realtime) messages. The proper way to do this, so that it works with any MIDI message, is to use snd_midi_event_encode_byte() and output the message when it's complete. The following fix is from the pd-l2ork repo, but it should apply cleanly on the current pure-data master branch: https://github.com/pd-l2ork/ pd/commit/9f5a265Sent from sourceforge.net because pd-dev@lists.iem.at is subscribed to https://sourceforge.net/p/ pure-data/bugs/To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/ pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. ______________________________ _________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev
______________________________ _________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev
-
Albert Graef -
Albert Graef -
Giulio Moro -
Martin Peach