For the transition: Either convert the keys, or invalidate old configurations when compiled with 4.2.0.

If you are interested, the problem was, that the key values were ordered like:

normal keys .. modifier keys

So every time a new key was added, all modifier key values increased by one. Right now, the limit of 128 keys is hit - so probably in the compatibility layer, the values won't change anymore (but we'll have to find a way to support more keys, 128 is not enough for many keyboards).

Generally, directly using internal values like the KEY_* values isn't a good idea. But in this case, I guess it is quite safe.. the compatibility layer can't get more than 128 keys, and in 4.3.x I hope we'll simply have an int for every key, so there also will be no need to ever change the values.

Well there's a function scancode_to_name for that... pity it wasn't in 4.0

Pete

Well, I think I might have another bug for y'all to chew on...

<edit>
Os: Windows XP SP2
AMD Athlon 64 3400+
SoundMax Integrated Audio ( comes on NForce 3 mobo's )
GeForce 440 Go 64MB
768MB Ram
</edit>

I've been doing some research into the weird minimizing bug that I have been having with the setup program, and I have been able to reproduce a bug similar to it with the following test program (not the exact same error, but it brings about some interesting results)...

test.c:

The code above is built with this command, FYI: gcc -o test.exe test.c -lalleg

Now, on my system, it outputs the following...

 MIDI Testing Program
 MIDI: Driver Detected, but no way to determine voices
 DIGI: Digital Device Detected, Voices = 65535
 Everything installed fine, I'm lost...
 The Midi Loaded fine, do you hear anything? I'm guessing not

..and then waits for the escape key ( expected ).

However, this is where the "interesting" results come in. Here is what I have noticed. The allegro application creates what is basically a "null" window on the task bar and assigns focus to it (this, I assume, has something to do with grabbing keypresses or something). However, whenever the null window is in focus, the MIDI will not play. If any other window is in focus, the midi does play, which presents us with an interesting problem.

I'm not sure how to further proceed debugging this problem. I can debug my own programs just fine, but a library I'm not exactly sure how to proceed with debugging.

Any ideas?

Also, some other people might want to test this just to make sure I'm not going crazy or that it is just some increadibly wacko hardware problem or something.

I dunno, let me try that real quick... I will edit with the results.

EDIT:

It actually works even less with set_gfx_mode ( GFX_AUTODETECT_WINDOWED, 640, 480, 0, 0) added right below the voices = detect_digi_driver line.

The Midi stutters now... if you switch focus from the window to the dos window back and forth, you get what sounds like a "frame" of the midi at a time, instead of having the midi playing continuously (well, in fact it may be playing continuously, we can only hear something when we switch back and forth).

Adding set_display_switch_mode makes it revert back to the previous symptoms (if main window is in focus, no midi. Midi everywhere else).

Changing it to GFX_AUTODETECT_WINDOWED causes the stuttering effect.
Adding set_display_switch_mode ( SWITCH_BACKGROUND ) causes the suttering to disappear. Interesing, though, is that the counter on the inside of the window continues to count in both situations (meaning that when the window has focus, it is probably trying to play notes but can't).

Either method ( switch background and default switching mode (no switch line)) with GFX_AUTODETECT (fullscreen mode) fails to produce any midi output.

Thanks. I can just try it with exmidi then when I'm in windows the next time. Oh, which driver was being used?

To me it sounds that somehow Allegro blocks the windows midi player from playing.. now how it does that, I have no idea. Maybe when DX Sound is initialized, there is a flag to let the midi play? Or maybe DX can itself play midi..

Huh? You are still calling detect_digi_driver(DIGI_AUTODETECT) twice.

AHHH!!! Attack of TEH TYPOS!!!!

I'll try fixing it right now...

EDIT: See code two posts below for current test case code

GHA! Somedays even I wonder what I was smoking when I wrote stuff...

It still outputs the same thing, though. And the behaviour is still the same, no sound when main window is in focus, sound everywhere else.

As for determining the driver the program is using, anyone know of an easy way to determine it?

Okay, the driver information the program reports is the following:

 digi_driver->name = Allegmix SoundMAX Digital Audio
 digi_driver->desc = Allegmix SoundMAX Digital Audio
 midi_driver->name = Microsoft MIDI Mapper
 midi_driver->desc = Microsoft MIDI Mapper

EDIT: Placing rest(0) in the while-loop causes the same results in the test program above; no sound while main window is in focus, sound everywhere else.

EDIT:

Test program now reads:

I know. Mailing list only is fine for reporting bugs.

Who on #allegro? What did they tell you? Mailing list definitely is fine, unless you need some feedback to confirm it first by others (in which case, send first only here, then later to [AD] if no developer responds).