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 <aggr...@gmail.com>
> *To:* Giulio Moro <giuliom...@yahoo.it>
> *Cc:* Ticket 1272 <1...@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 <agr...@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:  aggr...@gmail.com
> WWW:    https://plus.google.com/+AlbertGraef
>
>
>
> _______________________________________________
> 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

Reply via email to