Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

[MBS] re: Number of sysex bytes in a PortMidiEventMBS (MBS Xojo Plugin Mailinglist archive)

Back to the thread list
Previous thread: [MBS] re: dynapdf command for bookmarks
Next thread: [MBS] Turn


[MBS] re: Number of sysex bytes in a PortMidiEventMBS   -   Julia Truchsess
  [MBS] re: Number of sysex bytes in a PortMidiEventMBS   -   Julia Truchsess
  [MBS] re: Number of sysex bytes in a PortMidiEventMBS   -   Julia Truchsess
   Re: [MBS] re: Number of sysex bytes in a PortMidiEventMBS   -   Mark Franken
   Re: [MBS] re: Number of sysex bytes in a PortMidiEventMBS   -   Christian Schmitz
  [MBS] Re: Number of sysex bytes in a PortMidiEventMBS   -   Julia Truchsess
   Re: [MBS] Re: Number of sysex bytes in a PortMidiEventMBS   -   Christian Schmitz
  [MBS] Number of sysex bytes in a PortMidiEventMBS   -   Julia Truchsess
   Re: [MBS] Number of sysex bytes in a PortMidiEventMBS   -   Mel Patrick

[MBS] re: Number of sysex bytes in a PortMidiEventMBS
Date: 15.01.11 14:34 (Sat, 15 Jan 2011 08:34:35 -0500)
From: Julia Truchsess
Thanks Christian, that will be great.

Julia

>Date: Fri, 14 Jan 2011 23:23:39 +0100
>From: Christian Schmitz <<email address removed>>
>Subject: Re: [MBS] re: Number of sysex bytes in a PortMidiEventMBS
>
>I see. There are an extra two zero bytes.
>
>I'll put PortMidi for an update as I think I should update to the latest
>version of the lib before searching such a bug.

_______________________________________________
Mbsplugins_monkeybreadsoftware.info mailing list
<email address removed>
https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info

[MBS] re: Number of sysex bytes in a PortMidiEventMBS
Date: 15.01.11 14:33 (Sat, 15 Jan 2011 08:33:20 -0500)
From: Julia Truchsess
Thanks Mark.

MidiPacketMBS is not part of the PortMidi plugin, it's part of the
MacOSXCF plugin.

I am convinced at this point that the MIDI functions in the MacOSXCF
plugin are more robust than those of the PortMidi plugin, but PortMIDI is
cross-platform and I have (ok, my client has) a considerable investment in
my PortMidi-based code and rewriting everything to use the MacOSXCF and
WindowsMIDI plugins will be a distraction from other urgent work.

Julia

>
>Message: 2
>Date: Sat, 15 Jan 2011 21:28:46 +1100
>From: Mark Franken <<email address removed>>
>Subject: Re: [MBS] re: Number of sysex bytes in a PortMidiEventMBS
>To: MBS REALbasic Plugin List <<email address removed>>
>Message-ID: <<email address removed>>
>Content-Type: text/plain; charset=us-ascii
>
>On 15/01/2011, at 9:23 AM, Christian Schmitz wrote:
>>Did someone else on the list get it working?
>
>I've been using PortMidiMBS for over 2 years in one of my apps that reads
>SYSEX commands with no problems. The commands are transmitted from Pro
>Tools - not sure if that makes a difference. All I do is combine the
>packets of a SYSEX command in an array of MidiPacketMBS - waiting for the
>&hF7 to know when the command has ended.
>
>Regards,
>
>Mark
>

_______________________________________________
Mbsplugins_monkeybreadsoftware.info mailing list
<email address removed>
https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info

[MBS] re: Number of sysex bytes in a PortMidiEventMBS
Date: 14.01.11 21:58 (Fri, 14 Jan 2011 15:58:09 -0500)
From: Julia Truchsess
Thank you for trying, Christian, but it is still not right.

Sysex sent to the program:

F0 00 01 65 00 7F 00 F7

PortMidiEventMBS objects received:

PortMidiEventMBS(0):

PortMidiEventMBS.RawData0: F0
PortMidiEventMBS.RawData1: 00
PortMidiEventMBS.RawData2: 01
PortMidiEventMBS.RawData3: 65

PortMidiEventMBS(1):

PortMidiEventMBS.RawData0: 00
PortMidiEventMBS.RawData1: 7F
PortMidiEventMBS.RawData2: 00
PortMidiEventMBS.RawData3: 00

PortMidiEventMBS(2):

PortMidiEventMBS.RawData0: 00
PortMidiEventMBS.RawData1: F7
PortMidiEventMBS.RawData2: 00
PortMidiEventMBS.RawData3: 00

The message should have been received as two events of four bytes each but
instead the plugin is delivering it as three events with the second two
events containing only two of the message bytes each, padded to four bytes
with zeroes.

Without knowing how many actual message bytes each PortMidiEventMBS
contains, the message cannot be reconstructed.

Thanks,
Julia

>
>Message: 6
>Date: Mon, 10 Jan 2011 17:22:54 +0100
>From: Christian Schmitz <<email address removed>>
>Subject: Re: [MBS] Re: Number of sysex bytes in a PortMidiEventMBS
>
>Am 10.01.2011 um 16:04 schrieb Julia Truchsess:
>
>> My problem is at the lower level of receiving the individual bytes,
>>which
>> are received as the RawMessage property of PortMidiEventMBS objects.
>>Here
>> is my receive loop code:
>
>I could of course add a method to give you the raw message part as a 4
>byte memoryblock, but I can't do more than simply pass data through.
>
>Greetings
>Christian

_______________________________________________
Mbsplugins_monkeybreadsoftware.info mailing list
<email address removed>
https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info

Re: [MBS] re: Number of sysex bytes in a PortMidiEventMBS
Date: 15.01.11 11:28 (Sat, 15 Jan 2011 21:28:46 +1100)
From: Mark Franken

On 15/01/2011, at 9:23 AM, Christian Schmitz wrote:
> Did someone else on the list get it working?

I've been using PortMidiMBS for over 2 years in one of my apps that reads SYSEX commands with no problems. The commands are transmitted from Pro Tools - not sure if that makes a difference. All I do is combine the packets of a SYSEX command in an array of MidiPacketMBS - waiting for the &hF7 to know when the command has ended.

Regards,

Mark

_______________________________________________
Mbsplugins_monkeybreadsoftware.info mailing list
<email address removed>
https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info

Re: [MBS] re: Number of sysex bytes in a PortMidiEventMBS
Date: 14.01.11 23:23 (Fri, 14 Jan 2011 23:23:39 +0100)
From: Christian Schmitz

Am 14.01.2011 um 21:58 schrieb Julia Truchsess:

> Thank you for trying, Christian, but it is still not right.

I see. There are an extra two zero bytes.

I'll put PortMidi for an update as I think I should update to the latest version of the lib before searching such a bug.

Did someone else on the list get it working?

Greetings
Christian

[MBS] Re: Number of sysex bytes in a PortMidiEventMBS
Date: 10.01.11 16:04 (Mon, 10 Jan 2011 10:04:36 -0500)
From: Julia Truchsess
Thank you for your reply, Mel. You have misunderstood my problem/question,
however. I do read sysex just as you describe: read received bytes into a
buffer starting with reception of F0 and ending at F7, then exit to parse
the message. Of course sysex messages can be any length and I do not rely
on a message being any particular length.

My problem is at the lower level of receiving the individual bytes, which
are received as the RawMessage property of PortMidiEventMBS objects. Here
is my receive loop code:

Function ReadMIDImsg(Timeout As Integer) As String

dim d as PortMidiEventMBS
dim e, i, midievent, CharVal as integer
dim StartTime, CurTime As Double
dim ReadStr, hexstr As String

// This routine reads one MIDI message and returns on receipt of EOX or
expiration of the timeout.
// It returns a null string if timeout.

if MIDIInputStream = nil then
MsgBox("Please select a MIDI input device (Tools menu > MIDI Tools)")
Return "NoMIDI"
end

StartTime = Microseconds

Do

If MIDIInputStream.Pollthen

If (Microseconds - StartTime) > Timeout*1000 then return "" //
Timeout if no MIDI received
else

// We've got some incoming MIDI - loop here and get it

Do
e=MIDIInputStream.Read(d) // Read(d) returns # of events, -1 for
error.

If (Microseconds - StartTime) > Timeout*1000 then return "" //
Timeout

if e = -1 then
MsgBox "Port MIDI Error: "+MIDIInputStream.ErrorText(e)
return ""
end

for midievent = 1 to e
// hex(RawMessage) doesn't provide leading zeros, e.g. "1BBAAF0"
instead of "01BBAAF0"
// Pad to the next even number of digits. ### works for
handshakes but not filedumps ###

hexstr = hex(d.RawMessage)
if LenB(hexstr)/2 <> LenB(hexstr)2 then
hexstr = "0"+hexstr
end

// RawMessage, when converted to hex, is time-reversed, i.e. a
transmission of "F0,12,34,56"
// (where F0 was the first byte sent) is received as RawMessage
"563412F0"

for i = lenB(hexstr)/2 DownTo 1
CharVal = Hex2Byte(midB(hexstr,i*2-1,2))
ReadStr = ReadStr + ChrB(CharVal) // Add to binary string
if CharVal = EOX then Exit Do
next
next midievent

Loop Until InstrB(ReadStr,ChrB(EOX))<>0 // Exit on EOX

Return ReadStr // Now we've gotten an EOX
end

End

Loop

If there's a better way of doing this I'd love to hear it!

Thanks,
Julia


On 1/10/11 6:00 AM, "<email address removed>"
<<email address removed>> wrote:
>------------------------------
>
>Message: 3
>Date: Sun, 09 Jan 2011 22:12:44 -0800
>From: Mel Patrick <<email address removed>>
>Subject: Re: [MBS] Number of sysex bytes in a PortMidiEventMBS
>To: MBS REALbasic Plugin List <<email address removed>>
>Message-ID: <C94FE35C.3A764%<email address removed>>
>Content-Type: text/plain; charset="US-ASCII"
>
>I've been doing SYSEX send and receive for years with MBS and it works
>flawlessly. But you need change the way you handle the data.
>
>Relying on the size from a MIDI interface is prone to failure. A MIDI
>interface like a FastLane will break SYSEX into 3 byte messages because
>that's the way it's driver works. Others will break a large SYSEX into 256
>byte messages. Still others will pick any value they ruddy well feel like.
>You have no control over the driver. So assuming that it's all in one dump
>won't work.
>
>When you receive SYSEX it can be any number of bytes. There is no set
>standard that says it must end on 4/2 byte boundary. That goes for Roland,
>Behringer, and so on. Thus, no padding is needed if you handle the
>incoming
>data differently.
>
>What I have done and works perfectly, use the Sysex format itself to
>permit
>your routine (or class as the MBS demo has setup) to look for the SYSEX
>stop and start marker bytes. Thus it doesn't matter how many bytes are in
>between.
>
>When you get an F0, starting reading into a buffer and incrementing a
>buffer
>count. When you get an F7, then grab everything in the buffer and carry it
>to your main routine in a memoryblock. Parse it how you like. No padding
>needed, nor should there be in a SYSEX. What you get between an F0 and F7
>is
>what you work with.
>
>I commonly deal with SYSEX that ranges in sizes from 54 bytes to over 8K
>and
>it works flawlessly every time this way.
>
>A bigger SYSEX problem is that there's a whack of MIDI interfaces out
>there
>that are NOT Sysex compatible. I have a list of them if you need it (email
>me off list to save bandwidth)...
>
>Mel
>---
>
>On 01/09/11 7:25 PM, "Julia Truchsess" <<email address removed>> wrote:
>
>> I'm having a devil of a time receiving sysex data accurately with
>>PortMidiMBS
>> and I'm beginning to think it may be a problem with the MBS plugin
>> implementation. Sysex data is received in the RawMessage property of a
>> PortMidiEvent structure. RawMessage is a number, which when converted
>>to a hex
>> string, resembles the string of transmitted sysex data bytes.
>>
>> The problem is that there is no way of knowing how many sysex data
>>bytes the
>> RawMessage contains, and therefore there is no way of knowing how many
>>leading
>> zeroes to pad the hex string with.

_______________________________________________
Mbsplugins_monkeybreadsoftware.info mailing list
<email address removed>
https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info

Re: [MBS] Re: Number of sysex bytes in a PortMidiEventMBS
Date: 10.01.11 17:22 (Mon, 10 Jan 2011 17:22:54 +0100)
From: Christian Schmitz

Am 10.01.2011 um 16:04 schrieb Julia Truchsess:

> My problem is at the lower level of receiving the individual bytes, which
> are received as the RawMessage property of PortMidiEventMBS objects. Here
> is my receive loop code:

I could of course add a method to give you the raw message part as a 4 byte memoryblock, but I can't do more than simply pass data through.

Greetings
Christian

[MBS] Number of sysex bytes in a PortMidiEventMBS
Date: 10.01.11 04:25 (Sun, 9 Jan 2011 22:25:40 -0500)
From: Julia Truchsess
I'm having a devil of a time receiving sysex data accurately with PortMidiMBS and I'm beginning to think it may be a problem with the MBS plugin implementation. Sysex data is received in the RawMessage property of a PortMidiEvent structure. RawMessage is a number, which when converted to a hex string, resembles the string of transmitted sysex data bytes.

The problem is that there is no way of knowing how many sysex data bytes the RawMessage contains, and therefore there is no way of knowing how many leading zeroes to pad the hex string with. A RawMessage that converts to &h42 might be only one byte of sysex data but it might also be 42 00 00 00 or 42 00 00. The number of data bytes in each PortMidiEventMBS.RawMessage seems to vary pretty randomly – it can be anything from one to four, so I cannot choose a fixed number to pad to with zeroes. For a while I thought it was sufficient to simply pad to an even number of hex digits, and that works OK for some messages like handshakes, but now I'm receiving more lengthy filedumps and it's not working anymore and I don't see how to fix it without knowing the number of sysex bytes in each PortMidiEvent. Here's an example:

Sysex data transmitted (data verified correct by MIDIMonitor utility):

00 40 00 42 00 00 00 01 00 (this is in the middle of a sysex filedump - I'm not showing the status bytes etc.)

This is received as 3 PortMidiEventMBS structures. Here are the 3 received PortMidiEventMBS.RawMessage values after converting to hex using RealStudio's Hex() function which does not add leading zero characters:

4000
42
100

A string of hex bytes obviously needs to have an even number of digits so we pad the last one, giving us:

4000
42
0100

The hex bytes of a RawMessage have reversed time order, so after adjusting for that we have:

00 40 42 00 01

Which is wrong.

Looking back at the original transmitted data we can surmise that the first PortMidiEventMBS actually carried three bytes and its RawMessage needed to be padded with leading zeroes to

00 40 00

The second PortMidiEventMBS carried two bytes and its RawMessage needed to be padded to

00 42

The third PortMidiEventMBS carried four bytes and its RawMessage needed to be padded to

00 00 01 00

Reversing the time order and concatenating these padded strings gives us the correct message of

00 40 00 42 00 00 00 01 00

The reason I suspect MBS and not PortMIDI is that the PortMIDI documentation (http://portmedia.sourceforge.net/portmidi/doxygen/structPmEvent.html#_details) clearly states:

"A sysex message is encoded as a sequence of PmEvent structures, with each structure carrying 4 bytes of the message"

If I could rely on each PortMidiEventMBS actually carrying 4 bytes then it would be very easy to pad the hex strings appropriately, but PortMidiMBS does not seem to implement a constant 4-byte pmEvent structure and I don't see how I can accurately reconstruct the sysex data without knowing how many bytes each PortMidiEventMBS carries.

Thanks,
Julia
_______________________________________________
Mbsplugins_monkeybreadsoftware.info mailing list
<email address removed>
https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info

Re: [MBS] Number of sysex bytes in a PortMidiEventMBS
Date: 10.01.11 07:12 (Sun, 09 Jan 2011 22:12:44 -0800)
From: Mel Patrick
I've been doing SYSEX send and receive for years with MBS and it works
flawlessly. But you need change the way you handle the data.

Relying on the size from a MIDI interface is prone to failure. A MIDI
interface like a FastLane will break SYSEX into 3 byte messages because
that's the way it's driver works. Others will break a large SYSEX into 256
byte messages. Still others will pick any value they ruddy well feel like.
You have no control over the driver. So assuming that it's all in one dump
won't work.

When you receive SYSEX it can be any number of bytes. There is no set
standard that says it must end on 4/2 byte boundary. That goes for Roland,
Behringer, and so on. Thus, no padding is needed if you handle the incoming
data differently.

What I have done and works perfectly, use the Sysex format itself to permit
your routine (or class as the MBS demo has setup) to look for the SYSEX
stop and start marker bytes. Thus it doesn't matter how many bytes are in
between.

When you get an F0, starting reading into a buffer and incrementing a buffer
count. When you get an F7, then grab everything in the buffer and carry it
to your main routine in a memoryblock. Parse it how you like. No padding
needed, nor should there be in a SYSEX. What you get between an F0 and F7 is
what you work with.

I commonly deal with SYSEX that ranges in sizes from 54 bytes to over 8K and
it works flawlessly every time this way.

A bigger SYSEX problem is that there's a whack of MIDI interfaces out there
that are NOT Sysex compatible. I have a list of them if you need it (email
me off list to save bandwidth)...

Mel
---

On 01/09/11 7:25 PM, "Julia Truchsess" <<email address removed>> wrote:

> I'm having a devil of a time receiving sysex data accurately with PortMidiMBS
> and I'm beginning to think it may be a problem with the MBS plugin
> implementation. Sysex data is received in the RawMessage property of a
> PortMidiEvent structure. RawMessage is a number, which when converted to a hex
> string, resembles the string of transmitted sysex data bytes.
>
> The problem is that there is no way of knowing how many sysex data bytes the
> RawMessage contains, and therefore there is no way of knowing how many leading
> zeroes to pad the hex string with.

_______________________________________________
Mbsplugins_monkeybreadsoftware.info mailing list
<email address removed>
https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info