MIDI lockup on 0.6.4 (Windows)

[Mark Morgan Lloyd]

First, I want to say that I think Piano Booster is great, you've saved me spending the rest of my life trying to write something that isn't half as good.

I've got it running on an NT4 laptop (not really by choice, it was what I had available) connected to a Yamaha HC-4 organ and external TG300 sound generator. I find that pressing any organ control locks up PB's MIDI input, I've got to kill it from Task Manager to get MIDI input working again although output is OK. I think it's down to sysex messages, as a particular example the expression pedal (channel 16) doesn't cause a lockup while the toe switch (sysex) does.

This is reproducible, I've gone back and find that it also happens on 0.6.2. I can't easily check what happens on Linux although it's my preferred platform.

-- MarkMLl

[Louis B.]

Can your record the output from the organ and post it here. Even better would be the hex values from a midi dump program (as well) and I'll look at it after Xmas.
L.

[Mark Morgan Lloyd]

According to the manual the sysex for the toe switch- as a convenient example- is f0 43 70 70 40 45 7f f7 for the "on" state.

Can you recommend a minimal monitor that will run under NT? It's a long time since I've tried to do this sort of thing with a scope :-)

-- MarkMLl

[Mark Morgan Lloyd]

I've spent some time tinkering with this over the last few days (in between scheduled database work) and on one occasion MIDI input didn't lock up in response to e.g. the toe switch.

Resetting the keyboard didn't change this (i.e. MIDI still worked). Stopping and restarting PB put it into a state where as soon as I touched the toe switch MIDI input locked up, I had to kill PB from Task Manager to get it to work again.

I've not looked at the code but this feels rather like an uninitialised variable somewhere. However I've not managed to duplicate whatever I did to make it not lock up... I suppose having a hard fault is good news in some ways but I'd be far happier if I were able to contribute hard facts.

-- MarkMLl

[Louis B.]

Ok,

Now we have xmas out of the way, I'll provide a debug version of PB
that prints out the hex values of the midi inputs. along with other
debug info. I tried sending PB sysexe codes but it always worked fine
for me.

Just to make things clear for me, can you always make it lock up? I.e.
is the problem repeatable?

It may take a few goes to find the problem, but if the problem is
repeatable it should make it much easier.

By the way I tested PB with valgrind that found a lot of unitilised
variables and I have fixed all that it found.

On Sun, Dec 27, 2009 at 2:37 PM, Mark Morgan Lloyd [via Piano Booster]
<[hidden email]> wrote:

> I've spent some time tinkering with this over the last few days (in between
> scheduled database work) and on one occasion MIDI input didn't lock up in
> response to e.g. the toe switch.
>
> Resetting the keyboard didn't change this (i.e. MIDI still worked). Stopping
> and restarting PB put it into a state where as soon as I touched the toe
> switch MIDI input locked up, I had to kill PB from Task Manager to get it to
> work again.
>
> I've not looked at the code but this feels rather like an uninitialised
> variable somewhere. However I've not managed to duplicate whatever I did to
> make it not lock up... I suppose having a hard fault is good news in some
> ways but I'd be far happier if I were able to contribute hard facts.
>
> -- MarkMLl
>
>
> ________________________________
> View message @
> http://n2.nabble.com/MIDI-lockup-on-0-6-4-Windows-tp4212978p4220623.html
> To start a new topic under Piano Booster Users, email
> [hidden email]
> To unsubscribe from Piano Booster Users, click here.
>

[Mark Morgan Lloyd]

> Now we have xmas out of the way, I'll provide a debug version of PB
> that prints out the hex values of the midi inputs. along with other
> debug info. I tried sending PB sysexe codes but it always worked fine
> for me.

That would be worth leaving in as an "Easter Egg".

> Just to make things clear for me, can you always make it lock up? I.e.
> is the problem repeatable?

Absolutely repeatable, apart from that one time.

-- MarkMLl

[Mark Morgan Lloyd]

Louis B. wrote

Now we have xmas out of the way, I'll provide a debug version of PB
that prints out the hex values of the midi inputs. along with other
debug info. I tried sending PB sysexe codes but it always worked fine
for me.
...
By the way I tested PB with valgrind that found a lot of unitilised
variables and I have fixed all that it found.

Are you planning on releasing a binary of this at some point? I've never tried building this sort of thing for Windows- I'm mostly developing on Linux these days (command-line stuff or Lazarus).

-- MarkMLl

[Louis B.]

Sorry I never did provide a version that prints out the sysex codes. For
me to takes this further I do need a sysex hexdump of what your keyboard
is sending out. there are various mididump programs out there for both
windows and Linux. Please try one out at let me have the results. Also
does the rtMidi example run on your laptop. That could easily be changed
to get a mididump.

L.

On Tue, 2010-06-22 at 22:49 -0700, Mark Morgan Lloyd [via Piano Booster]
wrote:

>         Louis B. wrote:
>         Now we have xmas out of the way, I'll provide a debug version
>         of PB
>         that prints out the hex values of the midi inputs. along with
>         other
>         debug info. I tried sending PB sysexe codes but it always
>         worked fine
>         for me.
>         ...
>         By the way I tested PB with valgrind that found a lot of
>         unitilised
>         variables and I have fixed all that it found.
> Are you planning on releasing a binary of this at some point? I've
> never tried building this sort of thing for Windows- I'm mostly
> developing on Linux these days (command-line stuff or Lazarus).
>
> -- MarkMLl
>
>
>
>
> ______________________________________________________________________
> View message @
> http://piano-booster.2625608.n2.nabble.com/MIDI-lockup-on-0-6-4-Windows-tp4212978p5211871.html 
> To start a new topic under Piano Booster Users, email ml-node
> +[hidden email]
> To unsubscribe from Piano Booster Users, click here.
>

[Mark Morgan Lloyd]

Louis B. wrote

Sorry I never did provide a version that prints out the sysex codes. For
me to takes this further I do need a sysex hexdump of what your keyboard
is sending out. there are various mididump programs out there for both
windows and Linux. Please try one out at let me have the results. Also
does the rtMidi example run on your laptop. That could easily be changed
to get a mididump.

L.

Sorry, I wasn't trying to prod too hard but things really did go very quiet. Considering the lockup-during-operation problem, a few days ago I thought that r94 had fixed it but I've got it again with r139- I've not yet reverted to r94 to see if that's now failing. Symptom is that MIDI input is ignored and exiting the program leaves it visible in Task Manager albeit without a window- if it were my code I'd be looking for a locked up thread.

If PianoBooster is running and I press- for example- the organ's upper-manual maximum-volume button then PB stops responding to MIDI input but otherwise appears to continue running. I've put MIDI-OX on the laptop, I'm still working my way through its basic capabilities so I'm going to transcribe manually. There's a constant stream of F8 timing which I'll assume with the button press resulting in a sysex

F0 43 70 72 41 12 00 F7

The penultimate byte is the volume or strictly the attenuation, 00 for max and 7F for min. There are other controls which give a problem but I think this is a good example since it is reasonable to use it in conjunction with the "Mute your part while playing" checkbox. One thing that /doesn't/ cause a problem is the expression pedal which appears as channel 16.

-- MarkMLl

[Louis B.]

Mark,

OK I have just added "--log --midi-input-dump" flags to the code.

Please compile the latest code from svn.

start pianobooster with the following command line arguments "-d --log --midi-input-dump".

Make your problem happen.

please post the resultant pb.log file.

Thanks

L.

[Mark Morgan Lloyd]

Louis B. wrote

start pianobooster with the following command line arguments "-d --log --midi-input-dump".

Make your problem happen.

please post the resultant pb.log file.

r142. Logfile bp.log (just to prove I'm paying attention :-) is zero bytes long. As before, terminating PB closes the window but leaves the app visible in Task Manager, suggesting a locked up thread.

I think I could usefully check the behaviour under Linux, but I'm afraid I can't easily do that at the moment. I'll see if I've got any long MIDI leads in the cable room tomorrow.

-- MarkMLl

[Louis B.]

Ok try this one in svn. it now flushes log after each line.

[Mark Morgan Lloyd]

r143. This is C4 (upper manual) followed by upper manual max volume button. Subsequent press of C4 (lower manual) didn't register on the PB display, and on termination app has to be removed with Task Manager. This is the same button that I used when I posted the sysex message earlier.

Warn: Midi Tempo 500000.000000  ppqn 96 500000
Warn: Midi Tempo 500000.000000  ppqn 96 500000
Warn: Midi Tempo 500000.000000  ppqn 96 500000
Info: Tracks 9 PPQN 384
Info: Opening song C:\Program Files\Piano Booster\Sundries\telstar2.mid
Info: Tracks 9 PPQN 384
Warn: Midi Tempo 125000.000000  ppqn 384 500000
Info: Using Pianist Channels 5 + 9
Info: midi input  0x90, 0x3c, 0x2e,
Info: midi input  0x90, 0x3c, 0x0,

Wishlist: svn revision number in the about box.

-- MarkMLl

[Louis B.]

I think the problem is in rtmidi try this file rtmidi_test.zip


to build run buildmidi.bat

run "midiprobe" first

then "cmidiin <portno>" this uses callbacks

then try "qmidiin <portno>" this uses threads (same as on PB)

Louis

[Mark Morgan Lloyd]

Sorry about the delay Louis, I've had my hands full of other stuff. I think you're right, it's something fairly basic in rtmidi. Here first is the midiprobe output:

-----8<-----
There are 1 MIDI input sources available.
  Input Port #1: ESS AudioDrive MIDI port Input

There are 2 MIDI output ports available.
  Output Port #1: ESS AudioDrive MIDI port Output
  Output Port #2: ESS AudioDrive MIDI
----->8-----

The machine is an elderly Sony Maiow in a dock with a 15-pin MIDI/game port, with an anonymous MIDI interface to standard DINs.

I'm giving it the same test as before, i.e. C4 from upper manual, upper manual max volume (which generates a sysex which I anticipate causes a lockup) followed by C4 from lower manual (which I don't expect to show).

Output from cmidiin #1 (trimmed):

-----8<-----

Reading MIDI input ... press <enter> to quit.
Byte 0 = 248, stamp = 0
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.018
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
...
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 144, Byte 1 = 60, Byte 2 = 34, stamp = 0.011
Byte 0 = 248, stamp = 0.008
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.018
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 144, Byte 1 = 60, Byte 2 = 0, stamp = 0.013
Byte 0 = 248, stamp = 0.006
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
Byte 0 = 248, stamp = 0.019
... to EOF
----->8-----

Output from cmidiin #1 is substantially the same, in neither case does the sysex appear to be getting logged :-(

I can see the scope of RtMidi.cpp but I don't pretend to follow the details. My seamanship she is not very good, I do not speak easily with her.

I haven't yet tested against Linux. One of the problems is that the obvious (i.e. movable) machine for me to use only has an 800x600 screen which is smaller than PianoBooster's default size- is there an easy way to tell it to start up with its window limited to (say) 640x480?

-- MarkMLl

[Mark Morgan Lloyd]

Mark Morgan Lloyd wrote

Output from cmidiin #1 is substantially the same, in neither case does the sysex appear to be getting logged :-(

I need to clarify that: the output was from cmidiin, qmidiin behaved substantially the same, and in both cases output stopped (i.e. there was a lockup) rather than the sysex simply vanishing.

I've now got PB (from SVN as of a couple of weeks ago) on Debian Linux attached to the organ, and I don't appear to be getting lockups. Hence I think this is probably in the Windows-specific part of rtmidi, I think it's probably not at a lower level since I've got a different app which doesn't crash.

I've got rtmidi from McGill and can compile the tests (again, Debian). midiprobe works but I can't get output from either cmidiin or qmidiin- no output after initial banner (but no lockup either) irrespective of whether I configure with --enable-debug.

-- MarkMLl

[Louis B.]

Ok just to clarify after you have sent the sysex that causes pb to
lockup does cmidiin exit when you press <enter> to quit? If <enter>
does not work it has locked up. (quit with Ctrl-C causes the OS to
kill the program)

is there any way you could get record the output from you organ on
linux using ether amidi -d
and/or aseqdump. I need to reproduce the problem here. i'll try the
f0 43 70 70 40 45 7f f7 from you organ manual here and see it it looks
up.

The next step would be to add loads of print statements to find out
where it is looking up in the rtmidi code.

L.

On Sun, Jul 18, 2010 at 2:43 PM, Mark Morgan Lloyd [via Piano Booster]
<[hidden email]> wrote:

> Mark Morgan Lloyd wrote:
> Output from cmidiin #1 is substantially the same, in neither case does the
> sysex appear to be getting logged :-(
>
> I need to clarify that: the output was from cmidiin, qmidiin behaved
> substantially the same, and in both cases output stopped (i.e. there was a
> lockup) rather than the sysex simply vanishing.
>
> I've now got PB (from SVN as of a couple of weeks ago) on Debian Linux
> attached to the organ, and I don't appear to be getting lockups. Hence I
> think this is probably in the Windows-specific part of rtmidi, I think it's
> probably not at a lower level since I've got a different app which doesn't
> crash.
>
> I've got rtmidi from McGill and can compile the tests (again, Debian).
> midiprobe works but I can't get output from either cmidiin or qmidiin- no
> output after initial banner (but no lockup either) irrespective of whether I
> configure with --enable-debug.
>
> -- MarkMLl
>
>
> ________________________________
> View message @
> http://piano-booster.2625608.n2.nabble.com/MIDI-lockup-on-0-6-4-Windows-tp4212978p5308798.html
> To start a new topic under Piano Booster Users, email
> [hidden email]
> To unsubscribe from Piano Booster Users, click here.
>

[Louis B.]

Can you try linking the midi input to the midi output with a midi cable and then try running sysextest

I get the following results on windows


D:>sysextest.exe 10

Would you like to open a virtual input port? [y/N] n
  Input port #0: SB Live! MIDI Port [1000]
  Input port #1: USB Audio Device

Choose a port number: 1


Would you like to open a virtual output port? [y/N]   Output port #0: USB Audio Device
  Output port #1: USB Audio Device [2]
  Output port #2: SB Live! Sw Synth [1000]
  Output port #3: SB Live! Synth A [1000]
  Output port #4: SB Live! Synth B [1000]
  Output port #5: SB Live! MIDI Port [1000]
  Output port #6: Microsoft GS Wavetable SW Synth

Choose a port number: 0

Byte 0 = 240
Byte 1 = 0
Byte 2 = 1
Byte 3 = 2
Byte 4 = 3
Byte 5 = 4
Byte 6 = 5
Byte 7 = 6
Byte 8 = 7
Byte 9 = 8
Byte 10 = 9
Byte 11 = 247

[Mark Morgan Lloyd]

Louis B. wrote

Ok just to clarify after you have sent the sysex that causes pb to
lockup does cmidiin exit when you press <enter> to quit? If <enter>
does not work it has locked up. (quit with Ctrl-C causes the OS to
kill the program)

[On Windows] Using test sequence as before, i.e. C4 followed by sysex, cmidiin after lockup does not terminate on <enter> but does on ^C. qmidiin does not terminate at all on <enter>, this is expected from the banner.

Louis B. wrote

is there any way you could get record the output from you organ on
linux using ether amidi -d
and/or aseqdump. I need to reproduce the problem here. i'll try the
f0 43 70 70 40 45 7f f7 from you organ manual here and see it it looks
up.

[On Linux]

$ amidi -l
Dir Device    Name
IO  hw:1,0,0  MD100 MIDI 1
$ amidi -d -p hw:1,0,0>amidi.txt

$ aseqdump -l
 Port    Client name                      Port name
  0:0    System                           Timer
  0:1    System                           Announce
 14:0    Midi Through                     Midi Through Port-0
 20:0    MD100                            MD100 MIDI 1
$ aseqdump -p 20:0>aseqdump.txt

results.tar.gz

Hope that upload worked.

-- MarkMLl

[Mark Morgan Lloyd]

Louis B. wrote

Can you try linking the midi input to the midi output with a midi cable and then try running sysextest

[On Windows]

-----8<-----
>sysextest 10

Would you like to open a virtual input port? [y/N] n

Opening ESS AudioDrive MIDI port Input


Would you like to open a virtual output port? [y/N] n
  Output port #0: ESS AudioDrive MIDI port Output
  Output port #1: ESS AudioDrive MIDI

Choose a port number: 0

^C
----->8-----

Lockup at that point. However it runs OK on Linux (Debian "Lenny") with an anonymous usb<->MIDI converter. I don't have a back-to-back MIDI cable to hand so I'm using the through-connector on a (Yamaha) sound generator.

Slightly later, I find it works on '98 which is on the same laptop, so it could be an OS version issue rather than something to do with the instrument. However as noted earlier I've not (yet) managed to get other software to lock up, only rtmidi.

We gave up on Windows for general use years ago but I've got a W2K system I can test it with at a pinch, much easier since I don't have to cable all the way to the instrument.

-- MarkMLl