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 <giuliom...@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 <aggr...@gmail.com> > *To:* Giulio Moro <giuliom...@yahoo.it> > *Cc:* Ticket 1272 <1...@bugs.pure-data.p.re.sf.net>; "firstname.lastname@example.org" > <email@example.com> > *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 < > firstname.lastname@example.org> 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 <agr...@users.sf.net> > *To:* email@example.com > *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 firstname.lastname@example.org 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 > Pdemail@example.com > https://lists.puredata.info/ listinfo/pd-dev > <https://lists.puredata.info/listinfo/pd-dev> > > > > ______________________________ _________________ > Pd-dev mailing list > Pdfirstname.lastname@example.org > 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: aggr...@gmail.com > WWW: https://plus.google.com/+AlbertGraef > > > -- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggr...@gmail.com WWW: https://plus.google.com/+AlbertGraef
_______________________________________________ Pd-dev mailing list Pdemail@example.com https://lists.puredata.info/listinfo/pd-dev