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...
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... (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...
-
SourceForge.net