[PD] sysex messages

Alex x37v.alex at gmail.com
Thu Feb 22 23:37:44 CET 2018

Oh okay, I get it.
I'm not sure. Are you sending SYSEX from your Circuit as well?

On Thu, Feb 22, 2018 at 2:31 PM, mario buoninfante <
mario.buoninfante at gmail.com> wrote:

> yap, this makes sense. I imagined Gmidimonitor does that. but why is not
> parsing midi from Pd?
> sorry, maybe I'm just missing the point, but I'm really trying to get my
> head around with that ;)
> cheers
> On 02/22/2018 10:29 PM, Christof Ressi wrote:
>> don't confuse MIDI messages with the individual bytes which make up the
>> message. Gmidimonitor parses the byte stream so it can tell you which
>> messages it gets. [midiout] is only responsible for sending raw *bytes* to
>> a MIDI device. it's your job to assemble your MIDI *messages*.
>> Gesendet: Donnerstag, 22. Februar 2018 um 23:05 Uhr
>> Von: "mario buoninfante" <mario.buoninfante at gmail.com>
>> An: Alex <x37v.alex at gmail.com>
>> Cc: pd-list at lists.iem.at
>> Betreff: Re: [PD] sysex messages
>> yap, I know that at the end of the day MIDI is dealing with 1 byte at
>> time. I was wondering why there's a difference between 2 different piece of
>> code that generates MIDI (Pd and Hardware synth).
>> for example I just monitored (via USB) my Novation Circuit (a groovebox)
>> and Gmidimonitor receives messages 81 bytes long. with Pd as I said is
>> always 1 byte.
>> now my question would be, how is this possible?
>> I'm sure Circuit sends sysex 81 bytes long, so I know that this is
>> correct, but still I don't know why Pd doesn't allow something like that.
>>   cheers,
>> Mario
>>   On 02/22/2018 09:58 PM, Alex wrote:
>> MIDI is a serial protocol, individual bits running down a single line, we
>> now also have USB midi which is a little bit different than that but
>> usually that is abstracted for you.The software monitor you're using likely
>> groups these for you but in reality you simply have a stream of individual
>> bits on the hardware line..
>> PD's object let you do bytes at a time instead of individual bits :)
>>   On Thu, Feb 22, 2018 at 1:47 PM, mario buoninfante <
>> mario.buoninfante at gmail.com[mailto:mario.buoninfante at gmail.com]> wrote:
>> Hi Alex,
>>   thanks for your reply. I think that also using your abstraction Pd will
>> spit out 1 byte per time (I didn't check it, but I assume that cause it's
>> not an external in C).
>> about MIDI if I'm not wrong, bytes are grouped in accord with the type of
>> message, ie Note on/off and CC are 3 bytes messages, channel pressure and
>> program change are 2 bytes, sysex have variable length and so on. and I
>> presume they're sent out in group.
>> in fact when I monitor MIDI messages coming for certain applications (I'm
>> on Linux and I'm using Gmidimonitor) the console tells me the sysex size in
>> bytes. so, with Pd the size is always 1 byte, but with other programming
>> languages and softwares is variable and goes in accord with the sysex I
>> generated.
>>   cheers,
>> Mario
>> On 02/22/2018 09:34 PM, Alex wrote:
>> I haven't tested in a while but I wrote an abstraction to take a list,
>> wrap it in the sysex start and end and output it as individual bytes:
>> https://github.com/x37v/pure_data[https://github.com/x37v/pure_data]
>>   midi is a byte oriented protocol..
>>   On Thu, Feb 22, 2018 at 1:24 PM, mario buoninfante <
>> mario.buoninfante at gmail.com[mailto:mario.buoninfante at gmail.com]>
>> wrote:Hi,
>> do you guys know if there's a way to send a list of sysex messages (or 1
>> complete message, let's say 8 bytes long) rather then 1 byte per time?
>> if not, do you know if there's a particular reason why it's not possible?
>> cheers,
>> Mario
>> _______________________________________________
>> Pd-list at lists.iem.at[mailto:Pd-list at lists.iem.at] mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>> _______________________________________________ Pd-list at lists.iem.at
>> mailing list UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list[https://lists.
>> puredata.info/listinfo/pd-list]
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180222/c10e6f49/attachment-0001.html>

More information about the Pd-list mailing list