[PD-dev] [ pure-data-Bugs-3010589 ] PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit

[SourceForge.net]

Bugs item #3010589, was opened at 2010-06-02 13:02
Message generated for change (Comment added) made by mrpeach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.42
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Miller Puckette (millerpuckette)
Summary: PD vanilla 0.42-5 - midiout 'loses' (re-orders) bit

Initial Comment:
WinXP Pro SP3
Pd version 0.42-5
17-Jan-07 version of PortMidi

thread: http://puredata.hurleur.com/sujet-4275-vanilla-portmidi-midiout-loses-orders-bits
(see thread for text colored in where neccessary)

hey everyone,

I've been working with PD vanilla 0.42-5 - PortMidi midiout last night, trying to figure out why it wouldn't work with my AKAI MPD 24 properly. Here's what I found:

Patch (as attached:)

240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247
|
midiout

And to check the results, i used: midiout -> Midiyoke -> MidiOX (all latest versions)


Problem

The message I sent (which was a valid MPD 24 SysEx message, double-checked several times from MidiOX directly) was DEC

240, 71, 0, 104, 49, 0, 11, 8, 0, 0, 72, 97, 108, 108, 111, 32, 32, 32, 247

and should convert have converted to HEX

F0 47 00 68 31 00 0B 08 00 00 48 61 6C 6C 6F 20 20 20 F7

instead, it comes out HEX

F0 47 00 68 31 00 02 08 00 00 52 61 6C 6C 1B 20 20 20 F7

- with 3 wrong HEX pairs.


What happens

I looked a bit at the first number, DEC 11 that should come out HEX 0B but comes out HEX 02

here's how it behaves in reverse engineering:

when i send DEC 0, 1, 2 or 3, it comes out HEX 0
when i send DEC 4, 5 6 or 7, it comes out HEX 1

see table:

DEC .. DEC -> HEX

00 .. 03 -> 00
04 .. 07 -> 01
08 .. 11 -> 02
12 .. 15 -> 03
16 .. 19 -> 04
20 .. 23 -> 05
24 .. 27 -> 06
28 .. 31 -> 07
32 .. 35 -> 08
36 .. 39 -> 09
40 .. 43 -> 0A
44 .. -> 0B

etc.

When you look at the BIN, it becomes obvious what's happening:

DEC  (BIN) .. DEC  (BIN) -> HEX (BIN)

00 (        0) .. 03 (      11) -> 00 (      0)
04 (    100) .. 07 (    111) -> 01 (      1)
08 (  1000) .. 11 (  1011) -> 02 (    10)
12 ( 1100) .. 15 (  1111) -> 03 (    11)
16 (10000) .. 19 (10011) -> 04 (  100)
20 (10100) .. 23 (10111) -> 05 (  101)

.. two bits at the end are truncated.

It wouldn't surprise me if we found them somewhere in the other 'wrong numbers' ofthe original message.

When I manipulate the numbers to come out correctly in MidiOX, my MPD 24 will happily accept the sysex and execute it so the probelm is definitely not MidiOx or Midiyoke.

Questions

1) can anyone confirm this?
2) is anyone currently maintaining PortMidi, so this could maybe get fixed?

thanks
groovelastig

----------------------------------------------------------------------

>Comment By: Martin Peach (mrpeach)
Date: 2010-06-03 13:30

Message:
I tried the new portmidi and it seems to work. At least [midiin] on a
debian machine receives the exact same message.

I just replaced the portmidi folder  pd/portmidi with the new one and
recompiled:
nmake clean
nmake




----------------------------------------------------------------------

Comment By: groovelastig (groovelastig)
Date: 2010-06-03 10:40

Message:
link to portmedia / portmidi:
https://sourceforge.net/apps/trac/portmedia/wiki/portmidi

----------------------------------------------------------------------

Comment By: groovelastig (groovelastig)
Date: 2010-06-03 10:36

Message:
@mrpeach thank you for confirming!

FWIW, the 15th position DEC 111 -> HEX 1B (mis-)behaves exactly as the 7th
position, described above

the 11th DEC 72 -> HEX 52 position 'substracts' HEX 40 (DEC 64) and the
does the same

---

AFAIK there's a new(er) version of PortMIDI available (v200), and
according to the changelog it's backwards compatible. Is someone up for
trying and compiling Pd vanilla with their new files? (and pretty please? ;
) 

----------------------------------------------------------------------

Comment By: Martin Peach (mrpeach)
Date: 2010-06-03 00:43

Message:
I get this too.
You can put the 11 anywhere up to the seventh position and it transmits
OK.
The function winmm_write_byte() in pmwinmm.c doesn't get called for some
of the message. This looks like a portmidi bug.
(I think it would be better to buffer the whole sysex message at the Pd
end and use portmidi's Pm_WriteSysEx() function to send it.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3010589&group_id=55736