[PD-dev] [pure-data:bugs] #1272 midiout not working correctly on ALSA

[Albert Graef]

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 at 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 at gmail.com>
> *To:* Giulio Moro <giuliomoro at yahoo.it>
> *Cc:* Ticket 1272 <1272 at bugs.pure-data.p.re.sf.net>; "pd-dev at lists.iem.at"
> <pd-dev at 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 at 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 at users.sf.net>
> *To:* pd-dev at 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 at 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 at lists.iem.at
> https://lists.puredata.info/ listinfo/pd-dev
> <https://lists.puredata.info/listinfo/pd-dev>
>
>
>
> ______________________________ _________________
> Pd-dev mailing list
> Pd-dev at 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 at gmail.com
> WWW:    https://plus.google.com/+AlbertGraef
>
>
>


-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20161018/441d50a9/attachment.html>