[PD] sysex messages

Fri Feb 23 17:16:58 CET 2018

yeah, so a lot of objects in pd except lists and then fan them out to the
inputs so you can do |list 1 2( -> [+ ] -> 3 but [midiout] has a 2nd input
to indicate the port number so doing that wouldn't map to what people are
used to in most contexts.

Really, an abstraction that works how you want it to is the way to go here.
[mario_sysex].
For instance, I almost always want midi CC to come as channel, cc number,
cc val but [ctlin] is the opposite, so I use an abstraction that changes
the order for me.
I'd say, make an abstraction, likely just copy mine and have it contain the
[midiout] instead of [outlet] and maybe take an argument for port number,
and then use and share that!

It is curious that your midi monitor groups a sysex message from one source
differently than from another, I can only speculate there but as long as
the bytes are interpreted properly it shouldn't matter :)

On Fri, Feb 23, 2018 at 6:03 AM, Mario Buoninfante <
mario.buoninfante at gmail.com> wrote:

> Hi Marco,
>
> I just wanna point out that I haven't got issues with Pd, no problem at
> all. I can easily work with Sysex in various way and of course also the way
> you described. mine was more a let's call it curiosity. also because I
> think that the possibility to directly send a list to [midiout], and let Pd
> deal with parsing, would be a faster process.
>
> cheers,
> Mario
>
> 2018-02-22 22:40 GMT+00:00 mario buoninfante <mario.buoninfante at gmail.com>
> :
>
>> yap I'm sending sysex from Circuit. I'm using Components a Novation
>> website that allows you to store patches and session from Circuit. and the
>> way that Circuit sends these info is why sysex. so I'm just dumping data
>> and monitoring.
>>
>> On 02/22/2018 10:37 PM, Alex wrote:
>>
>> 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.p
>>>> uredata.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/20180223/8df2f9a0/attachment-0001.html>