Bad Mood : Falcon030 'Doom'

[Trixster]

when using the 030 i'm using TOS

[dml]

when using the 030 i'm using TOS

I have not seen this effect before. It looks a bit like corrupt data but difficult to say for sure.

Does the machine have 14MB STRam when running on 030 mode?

...also, can you try clearing the FASTLOAD bit in with FileInfo CPX or PRGFLAGS? Very recent builds (since last week) have this flag set but maybe something is wrong with that. Other than corrupt files or FASTLOAD issues, can't think of anything else which could produce this and especially given decent testing so far on 030 machines.

[Trixster]

Hi!

Yes, it's got 14MB. The previous build of badmood i tried (Sat 5th Nov) worked fine with both 060 and 030.

I can play the game fine in 060 mode, so i suspect it's not corrupt data, unless 060 accesses different files to the 030 version?

I'll give FileInfo.cpx a try now

[Trixster]

Ok, removing the FASTLOAD flag in BM030.ttp doesnt seem to make a difference.

[dml]

Ive tried removing the pre-made cache and have twice tried to build a new one from fresh when running with the 030 but on both occasions badmood has crashed and the machine rebooted...

It crashed while trying to build the cache? Or when trying to launch it after building?

[Trixster]

It twice seemed to crash whilst building the cache, at different points. rebooting and then launching the game again just started rebuilding the cache from scratch. so i've added the pre-built cache again from the zip file.

[dml]

It twice seemed to crash whilst building the cache, at different points. rebooting and then launching the game again just started rebuilding the cache from scratch. so i've added the pre-built cache again from the zip file.

Ok thanks for reporting. I'm going to assume the last 030 binary is broken in some way and have missed it. I've been focusing on MIDI problems recently and while I have been testing a lot on 030 it could be something wrong with the last build.

Im hoping to be free of the MIDI stuff shortly - I just spent half a day trying to debug random looking MIDI packets, only to find its a problem with the USB MIDI adapter swapped it for the other one and now it works perfectly. Pffffffff!!! <o>

Anyway as soon as I can get this off my plate I'll look at the 030 release and see if I can reproduce that.

[Trixster]

No problem! I automatically assume it's user error so I'll try a fresh install again tomorrow - copy the zips across again, unzip and start afresh.

I did suspect maybe my machine is at fault, but I played your Quake2 Test for a few hours and all the maps on that ran smoothly, so I think my cpu/memory/fpu and dsp are all fine.

[dml]

@Eero

Think I found what is causing the corrupted SYSEX packets. It wasn't really possible to make sense of it properly without recompiling AMIDILIB with some instrumentation (for which I had to create a makefile for ELF GCC 12).

It appears there are some events in the music stream which assume direct ACIA writing and blocking flushes are possible mid-stream which is not the case when in TX interrupt (deferred) mode. The interrupt handler implements flushes after the music callback, it can't be expected to complete within the callback. Some other, related issues.

Have reworked the integration so there are clear mode switches between direct and deferred transmit modes and a flush that works in both modes, as external calls from AMIDILIB. The replayer is only permitted to append to the outgoing stream, not reset or flush the stream directly.

This has solved the broken SYSEX at the start. Not sure if it helps with Qsynth but it is at least something that needed fixed.

The faulty USB MIDI adapter wasted a bunch more time. It was somehow transmitting bytes in rearranged order (?!). The UM-ONE works properly, stuff arrives in expected order always.

Too tired to prepare builds tonight, will post a natfeats-debuggable Hatari build tomorrow sometime for testing.

[Eero Tamminen]

Have reworked the integration so there are clear mode switches between direct and deferred transmit modes and a flush that works in both modes, as external calls from AMIDILIB. The replayer is only permitted to append to the outgoing stream, not reset or flush the stream directly.

This has solved the broken SYSEX at the start. Not sure if it helps with Qsynth but it is at least something that needed fixed.

Sounds good! Was this was all on BM side, not an issue with AMIDILIB (except maybe not documenting this requirement)?

The faulty USB MIDI adapter wasted a bunch more time. It was somehow transmitting bytes in rearranged order (?!). The UM-ONE works properly, stuff arrives in expected order always.

Too tired to prepare builds tonight, will post a natfeats-debuggable Hatari build tomorrow sometime for testing.

Although stuff one has released not working properly, is always annoying and something one wants to fix, there's no hurry with anything.

We do this for fun after all, so just take a long break or skip completely MIDI debugging / fixing if it's starting to feel too much of a chore!

(One can always use your nice CPU side synthetizing, it's just a bit more overhead. I probably should try it anyway, to compare it against MIDI music.)

[dml]

Sounds good! Was this was all on BM side, not an issue with AMIDILIB (except maybe not documenting this requirement)?

Mmmm... it's a problem with integration of the two. AMIDILIB standalone seems fine. It gets complicated when AMIDILIB is a producer of the data and BM's transmit service is the consumer only. In this configuration, the lib should only append data to an outgoing stream, never flush or reset the buffer (i.e. no dependencies on the outgoing state). I had to fix some of this behaviour for the integration only (on both sides).

Although stuff one has released not working properly, is always annoying and something one wants to fix, there's no hurry with anything.

I didn't realise how broken it was, mainly because I didn't have a device to test until very recently - but even testing with that took quite a lot of time and some of the issues have been obscure to notice.

When I left it the other day it seemed like most of these issues are fixed, except the weird behaviour with Qsynth ignoring all channel commands except those on channel 0, while accepting note commands on all channels. It's a bit odd - and it does not report any logging info to indicate why - and it does not log any sysex events (which I think is probably the cause anyway) - both points annoying. I get plenty of logging from MIDI-OX but it doesn't show anything unexpected.

So my next plan was to use a midi_device_type = -1 and get AMIDILIB to treat that as 'fall through' for sysex initialization and see if Qsynth starts cooperating with no sysex messages being sent. Although I noticed some are being emitted during the early part of some songs and I don't know if those are *in* the song, or prefixed by AMIDILIB in some cases at song start. Yet to be determined.

We do this for fun after all, so just take a long break or skip completely MIDI debugging / fixing if it's starting to feel too much of a chore!
(One can always use your nice CPU side synthetizing, it's just a bit more overhead. I probably should try it anyway, to compare it against MIDI music.)

I did decide to leave it alone for a few days. But I will finish what I started, at least to release with the identified bugs fixed.

Still I had begun work on other things so I'd like to do some of that too maybe over the holidays.

[dml]

@Eero

So I modified BM/AMIDILIB to conditionally emit SYSEX messages on recognised/specified devices only.

Setting midi_device_type=99 (or any other value not recognised as a device) for testing results in fall-through behaviour for special setup messages and disables SYSEX messages. I have confirmed that no SYSEX messages are being emitted from the BM log. A copy of the BM console log is attached below.

I also confirmed with Hatari 'trace midi' that outgoing ACIA events match the data being flushed. All this traffic does is iterate through channels 0-15 and sets controller defaults for everything. The only 'special' message is the RPN(0,0)/6 which sets pitchbend range. The rest are all standard controller messages.

TX interrupts are disabled during this phase. I_FlushMIDISendBuffer(DIR) means direct/immediate-mode transfer to ACIA to keep things simple.

Qsynth's response to this is apparently to ignore everything completely. Or at least, nothing appears in the Qsynth log. I don't even see traffic for channel 0 as before. If I let it run past the init phase it does start showing note events on all channels, but only channel 0 has the correct instrument set, the rest are defaults.

What I do get is something that looks like a corrupted log, where it starts logging half way through an event (?????), apparently the end of the init phase. I don't know if this means Qsynth's logging is broken and it is just dropping the first N messages on the floor, or if it flushes only on the first note and the flush is broken, or if the incoming traffic has been missed in the first place.

Code: Select all

10:27:31.725 Qsynth1: Synthesizer engine started.
10:27:31.726 Qsynth1: fluid_synth_set_gain(1)
10:27:31.726 Qsynth1: fluid_synth_set_reverb(0.2,0,1,0.9)
10:27:31.726 Qsynth1: fluid_synth_set_chorus(3,1,0.3,8,0)

off 3 46 64   (?????????)
event_post_noteoff 3 46 64
event_pre_noteon 9 42 82
event_post_noteon 9 42 82
event_pre_noteon 0 50 100
event_post_noteon 0 50 100
event_pre_noteon 1 34 100
event_post_noteon 1 34 100
event_pre_noteon 2 58 90
event_post_noteon 2 58 90
event_pre_noteon 3 52 100
event_post_noteon 3 52 100

I have no idea what is going on with Qsynth. Unless some new information comes to light, I'm going to assume this Mac version is broken, or there is some problem in the MIDI pipe between Hatari and Qsynth on the Mac. I think trying to get any further with this would involve using a debug build of Qsynth/fluidsynth and to make it much more verbose, and maybe even to have some sort of MIDI capture device in between the two programs.

Instead I'm going to back away from this and focus on tidying up the mess made while debugging this issue and confirm it works ok on the hardware (real Falcon -> real Roland). After that I'll release an update with the recent fixes.



...outgoing traffic from BM, for init phase:

Code: Select all

audiodevice:: open
audiodevice:: start...
I_InitSound: done - sound module ready
I_InitMusic: Configuring unknown midi device.
 on channel: [ 1 ] 
NKTLib called: installMidiResetHandler()

Setting generic default on ch: 1
NKTLib called: flushMidiSendBuffer()
I_FlushMIDISendBuffer(DIR)
BM_S_FlushMIDIDirect(150)
> MIDI:D(150): b1 0 0 0 c1 1 b0 7b 0 b1 7b 0 b2 7b 0 b3 7b 0 b4 7b 0 b5 7b 0 b6 7b 0 b7 7b 0 b8 7b 0 b9 7b 0 ba 7b 0 bb 7b 0 bc 7b 0 bd 7b 0 be 7b 0 bf 7b 0 b0 79 0 b0 7c 0 b1 79 0 b1 7c 0 b2 79 0 b2 7c 0 b3 79 0 b3 7c 0 b4 79 0 b4 7c 0 b5 79 0 b5 7c 0 b6 79 0 b6 7c 0 b7 79 0 b7 7c 0 b8 79 0 b8 7c 0 b9 79 0 b9 7c 0 ba 79 0 ba 7c 0 bb 79 0 bb 7c 0 bc 79 0 bc 7c 0 bd 79 0 bd 7c 0 be 79 0 be 7c 0 bf 79 0 bf 7c 0
I_FlushMIDISendBuffer(DIR)
NktInit() done
I_ForceLoadMIDIDefaults()
I_FlushMIDISendBuffer(DIR)
I_FlushMIDISendBuffer(DIR)
BM_S_FlushMIDIDirect(990)
> MIDI:D(990): b0 7b 0 b1 7b 0 b2 7b 0 b3 7b 0 b4 7b 0 b5 7b 0 b6 7b 0 b7 7b 0 b8 7b 0 b9 7b 0 ba 7b 0 bb 7b 0 bc 7b 0 bd 7b 0 be 7b 0 bf 7b 0 b0 0 0 b0 1 0 b0 4 0 b0 7 0 b0 8 0 b0 a 0 b0 b 0 b0 40 0 b0 41 0 b0 5b 0 b0 5c 0 b0 79 0 b0 7c 0 b0 7f 0 b0 64 0 b0 65 0 b0 6 2 b0 64 7f b0 65 7f b1 0 0 b1 1 0 b1 4 0 b1 7 0 b1 8 0 b1 a 0 b1 b 0 b1 40 0 b1 41 0 b1 5b 0 b1 5c 0 b1 79 0 b1 7c 0 b1 7f 0 b1 64 0 b1 65 0 b1 6 2 b1 64 7f b1 65 7f b2 0 0 b2 1 0 b2 4 0 b2 7 0 b2 8 0 b2 a 0 b2 b 0 b2 40 0 b2 41 0 b2 5b 0 b2 5c 0 b2 79 0 b2 7c 0 b2 7f 0 b2 64 0 b2 65 0 b2 6 2 b2 64 7f b2 65 7f b3 0 0 b3 1 0 b3 4 0 b3 7 0 b3 8 0 b3 a 0 b3 b 0 b3 40 0 b3 41 0 b3 5b 0 b3 5c 0 b3 79 0 b3 7c 0 b3 7f 0 b3 64 0 b3 65 0 b3 6 2 b3 64 7f b3 65 7f b4 0 0 b4 1 0 b4 4 0 b4 7 0 b4 8 0 b4 a 0 b4 b 0 b4 40 0 b4 41 0 b4 5b 0 b4 5c 0 b4 79 0 b4 7c 0 b4 7f 0 b4 64 0 b4 65 0 b4 6 2 b4 64 7f b4 65 7f b5 0 0 b5 1 0 b5 4 0 b5 7 0 b5 8 0 b5 a 0 b5 b 0 b5 40 0 b5 41 0 b5 5b 0 b5 5c 0 b5 79 0 b5 7c 0 b5 7f 0 b5 64 0 b5 65 0 b5 6 2 b5 64 7f b5 65 7f b6 0 0 b6 1 0 b6 4 0 b6 7 0 b6 8 0 b6 a 0 b6 b 0 b6 40 0 b6 41 0 b6 5b 0 b6 5c 0 b6 79 0 b6 7c 0 b6 7f 0 b6 64 0 b6 65 0 b6 6 2 b6 64 7f b6 65 7f b7 0 0 b7 1 0 b7 4 0 b7 7 0 b7 8 0 b7 a 0 b7 b 0 b7 40 0 b7 41 0 b7 5b 0 b7 5c 0 b7 79 0 b7 7c 0 b7 7f 0 b7 64 0 b7 65 0 b7 6 2 b7 64 7f b7 65 7f b8 0 0 b8 1 0 b8 4 0 b8 7 0 b8 8 0 b8 a 0 b8 b 0 b8 40 0 b8 41 0 b8 5b 0 b8 5c 0 b8 79 0 b8 7c 0 b8 7f 0 b8 64 0 b8 65 0 b8 6 2 b8 64 7f b8 65 7f b9 0 0 b9 1 0 b9 4 0 b9 7 0 b9 8 0 b9 a 0 b9 b 0 b9 40 0 b9 41 0 b9 5b 0 b9 5c 0 b9 79 0 b9 7c 0 b9 7f 0 b9 64 0 b9 65 0 b9 6 2 b9 64 7f b9 65 7f ba 0 0 ba 1 0 ba 4 0 ba 7 0 ba 8 0 ba a 0 ba b 0 ba 40 0 ba 41 0 ba 5b 0 ba 5c 0 ba 79 0 ba 7c 0 ba 7f 0 ba 64 0 ba 65 0 ba 6 2 ba 64 7f ba 65 7f bb 0 0 bb 1 0 bb 4 0 bb 7 0 bb 8 0 bb a 0 bb b 0 bb 40 0 bb 41 0 bb 5b 0 bb 5c 0 bb 79 0 bb 7c 0 bb 7f 0 bb 64 0 bb 65 0 bb 6 2 bb 64 7f bb 65 7f bc 0 0 bc 1 0 bc 4 0 bc 7 0 bc 8 0 bc a 0 bc b 0 bc 40 0 bc 41 0 bc 5b 0 bc 5c 0 bc 79 0 bc 7c 0 bc 7f 0 bc 64 0 bc 65 0 bc 6 2 bc 64 7f bc 65 7f bd 0 0 bd 1 0 bd 4 0 bd 7 0 bd 8 0 bd a 0 bd b 0 bd 40 0 bd 41 0 bd 5b 0 bd 5c 0 bd 79 0 bd 7c 0 bd 7f 0 bd 64 0 bd 65 0 bd 6 2 bd 64 7f bd 65 7f be 0 0 be 1 0 be 4 0 be 7 0 be 8 0 be a 0 be b 0 be 40 0 be 41 0 be 5b 0 be 5c 0 be 79 0 be 7c 0 be 7f 0 be 64 0 be 65 0 be 6 2 be 64 7f be 65 7f bf 0 0 bf 1 0 bf 4 0 bf 7 0 bf 8 0 bf a 0 bf b 0 bf 40 0 bf 41 0 bf 5b 0 bf 5c 0 bf 79 0 bf 7c 0 bf 7f 0 bf 64 0 bf 65 0 bf 6 2 bf 64 7f bf 65 7f c0 1b c1 1b c2 1b c3 1b c4 1b c5 1b c6 1b c7 1b c8 1b ca 1b cb 1b cc 1b cd 1b ce 1b cf 1b

[dml]

Here is the latest build with last round of MIDI fixes:

https://www.dropbox.com/s/wspo64uuhkrhj ... 2.zip?dl=1

[saulot]

@dml: if there is demand I can just add extra device type for all of you SysEx haters in next release.... Like Pure GM/GS or something like that..

[dml]

@dml: if there is demand I can just add extra device type for all of you SysEx haters in next release.... Like Pure GM/GS or something like that..

It might be a good compatibility feature to have a 'pure' device. However as I found earlier, stopping the SYSEX messages didn't really help the situation with Qsynth anyway

[dml]

I did suspect maybe my machine is at fault, but I played your Quake2 Test for a few hours and all the maps on that ran smoothly, so I think my cpu/memory/fpu and dsp are all fine.

I forgot to make a suggestion last time - did you try running any of the other binaries, either 'bm03x.ttp' or 'bmhat.ttp'?

The '03x' build has blitter functions disabled. The 'hat'ari build has Videl rasters disabled. It might help rule out a couple of things. (The '0x0' build will not run on a vanilla machine as it has 040/060 instructions - so you can ignore that one)

It looks odd that the menus were half-rendered when it crashed. My thinking is this could involve blitter or interrupts (if not corrupt files, but you seem to have a good argument its not due to that).

I will do some testing later today on 030/HW with default config and make sure I don't see similar problems.

[Eero Tamminen]

Here is the latest build with last round of MIDI fixes:

https://www.dropbox.com/s/wspo64uuhkrhj ... 2.zip?dl=1

Unfortunately, with "midi_device_type" value "5", there's still PortMidi error with Qsynth:

Code: Select all

I_InitMusic: Configuring MT-32 compatible midi device with GM instrument patch set.
 on channel: [ 0 ]
...
MIDI: event 7F 7F 7F 7F
MIDI: write byte -> $7f
MIDI: write byte -> $7f
MIDI: write byte -> $7e
MIDI: SYX END event 7F 7E F7 0
MIDI: write byte -> $f7
MIDI: write byte -> $f0
MIDI: write byte -> $41
MIDI: write byte -> $10
MIDI: event F0 41 10 16
MIDI: write byte -> $16
MIDI: write byte -> $12
MIDI: write byte -> $f0
MIDI: write byte -> $41
MIDI: write byte -> $10
MIDI: event F0 41 10 16
WARN : MIDI: PortMidi write error -9994: 'PortMidi: `Invalid MIDI message Data''
MIDI: write error -> stop MIDI

With the other "midi_device_type" values, there are no errors, but instrument settings still does not go through.

While testing this, I noticed few extra things:

• When music is initialized, instrument on first channel changes several times (pre-existing instruments on other channels do not change). Is it possible that AMIDILIB (or BM Doom music conversion) somehow does all the instrument changes to channel 1, instead of to channels they were intended to?
• The (only) effect of "midi_channel" option on QSynth, is "Bright Yamaha Grand Piano" (bank 0, prog 1) instrument being set to a channel given for "midi_channel" option + 1. Is this what that option is supposed to do? (value 0 either has no effect or other instruments on channel 1 override it, and value 16 i.e. channel 17 does nothing, maybe because I've set 16 as max channels in Qsynth setup)
• Other Atari MIDI programs (which do work), seem to setting instruments that use only bank 0. So it's possible that use of other banks for the instruments is never tested to work OK with Hatari. Does BM try to use other banks? [1]

[1] QSynth setup has option to select between GM, GS, MMA and XG bank selection schemes.

I'm defaulting to GM, but I also tested that the other options did change anything in regards to instrument selection, or PortMidi error.

[dml]

Unfortunately, with "midi_device_type" value "5", there's still PortMidi error with Qsynth:

I think this is probably due to the *huge* quantity of SYSEX data being sent for that specific device choice. I just checked and it is over 30kb! So it is probably still overflowing the transmit buffer (i did not test this device, not knowing what it does and the transmit safety checks are disabled in the release build).

However this does not explain the remaining weird behaviour for other devices with smaller initialization messages trying to communicate with Qsynth.

With the other "midi_device_type" values, there are no errors, but instrument settings still does not go through.

This is what I was saying in my last posts while testing with Qsynth - it is ignoring controller messages except those on channel 0.

The messages are being prepared and sent, but they are being ignored by the software.

The Roland SC-88 does not ignore them however. It accepts them and sets correct instruments on requested channels.

[*] When music is initialized, instrument on first channel changes several times (pre-existing instruments on other channels do not change).

I also noticed this - but I would add that the Qsynth log does not correlate 1:1 with the number of instrument initialization commands being sent. I can see a flurry of program changes during setup and they all affect channel 0, but it is not the expected 16 being sent - only a few. This is also very strange.

There are further program changes in the songs themselves and those are sparse (a few at song start, some only on the first note on a given channel, some later in the song, changed on a channel) - this is normal. But the initialization step does not look normal, there are messages missing.

I don't trust the Qsynth log though - I have seen it printing half-messages and skipping the first N messages before it starts to actually log stuff. So it could be that all messages arrive and all are interpreted on channel 0, but only some are logged. Not very helpful as a log.

Is it possible that AMIDILIB (or BM Doom music conversion) somehow does all the instrument changes to channel 1, instead of to channels they were intended to?

I don't see how that could happen, unless a special message has 'told' Qsynth to interpret channel X commands as channel 0.

The actual commands encode the channel number in the low nibble of the CC byte and they are visible in the outgoing stream.

The init step especially encodes them directly in a for-loop, sent before song start, so no music data is involved. Even those get interpreted as channel 0.

The SC-88 is accepting these commands and setting instruments ok. So this is a mystery currently.

There may be some missing MIDI magic here but I don't know what it could be.

The (only) effect of "midi_channel" option on QSynth, is "Bright Yamaha Grand Piano" (bank 0, prog 1) instrument being set to a channel given for "midi_channel" option + 1. Is this what that option is supposed to do? (value 0 either has no effect or other instruments on channel 1 override it, and value 16 i.e. channel 17 does nothing, maybe because I've set 16 as max channels in Qsynth setup)

While I am not certain where midi_channel gets involved in songdata/nkt-init, I still think the issue is deeper. Because the BM music initialization function is also not working and this doesn't use midi_channel and doesn't refer to songdata. It is sent directly by the game, bypassing AMIDILIB. And it is still being ignored.

Again - this works on the Roland and MIDI-OX reports it all correctly coming out of the Roland's THRU port.

Other Atari MIDI programs (which do work), seem to setting instruments that use only bank 0. So it's possible that use of other banks for the instruments is never tested to work OK with Hatari. Does BM try to use other banks? [1]

BM does not use banks, and the initialization function forces a switch to bank 0 on all channels, as part of setting up default states.

This action is also reported by MIDI-OX in the status panel (it shows an excel-style sheet with a box per channel/controller axis, and the box gets filled when it receives a state on those axes).

[1] QSynth setup has option to select between GM, GS, MMA and XG bank selection schemes.

I saw this, but I expect all of them should be ok with bank 0. Unless just setting the bank number at all, is upsetting it.

I have been unable to get Qsynth to listen to controller events on any channel other than 0, i fiddled with a lot of stuff but with no success.

It is possible one of the init CC messages is just silently breaking Qsynth. Or perhaps some magic command is needed to get it to pay attention to other channels. I don't know - I can't see or reproduce this with packet capture from the Roland.

[saulot]

Yes this setting sends alot of data, it's issue is already known. It gives problems on older original devices: https://github.com/n0kturnal/amidilib/issues/5 .. And obviously it isn't a setting for QSynth. MT-32 isn't GM device, it's pre-GM...

[dml]

Had a look at the AMIDILIB device setup and it seems to perform a bank select (ch=midi_channel, bank=0) and program select (ch=midi_channel, program=1). Not all devices do the bank switch but they all do the program select.

I don't see that it does anything else.

Following that it sends all notes off across 16 channels. Sets volume, balance. Reset all controllers and omni-off across 16 channels.

BM sends its own setup messages after this (again, across 16 channels) to reset default states between songs, so by that point midi_channel is not going to have influence anyway.

I tried removing some of the less usual controller states on the BM side and it didn't help. I suppose I could remove all of them and just leave the AMIDILIB setup to test, but some of it is definitely needed to prevent songs leaving stale states (like reverb and pitch bend range).

[saulot]

I didn't thought about it much yet, but I might add some helper function to make something like device state reset for given device profile..

[dml]

@Eero

I just captured MIDI THRU traffic from the Roland again, 3 separate steps:

1) Before running BM (empty states)

cap1.jpg

2) After AMIDILIB device init & BM channel/controller reset calls. Note BM sets a guitar as a default patch/program on all channels except percussion.

cap2.jpg

3) After song start, with song setting patches itself.

cap3.jpg

Controller states are clearly seen on all channels. They are definitely being sent, and definitely understood by MIDI-OX (and by the device).

[Eero Tamminen]

It would be good to get a list of different MIDI devices that have been tested with BM, whether the music output worked OK, and did the MIDI stream come from a BM running on a real Falcon, or one running in Hatari.

I.e. are there any other MIDI devices that have problem interpreting the instrument info.

Can you record the working MIDI stream with some real MIDI device, and send that recording to QSynth?

(I looked into doing that with Linux Rosegarden sequencer, but that does not work as neither Hatari nor Rosegarden provides MIDI endpoint under ALSA, to which the other one could connect to. :-/)

[dml]

It would be good to get a list of different MIDI devices that have been tested with BM, whether the music output worked OK, and did the MIDI stream come from a BM running on a real Falcon, or one running in Hatari.

I can't manage this myself - I have a sample of 1 (or 2 if you count MIDI-OX routed to BassMIDI player on PC). Although one or two others on this forum had it working on other hardware with previous builds.

Can you record the working MIDI stream with some real MIDI device, and send that recording to QSynth?

I don't know that I can do this here, without actually writing software to run on another machine to capture it via MIDI-IN. But it's overcomplicating things.

I still find it suspicious that Qsynth behaves like this even with the SYSEX messages suppressed. There is not much outgoing traffic before the song starts, and the problem isn't with the song, because the problem is visible during the init sequence.

It could be down to a single command in the init sequence for channel 0, resulting in subsequent channels not listening. I will rearrange the order so it is feature-first with the channels as inner loops. This way it might get through a few controller features before it breaks.

[dml]

After more digging, reading and looking through the init messages, I think I have an idea what might be happening with BM/Hatari/Qsynth. But I will need to do some experiments to see if that is the case.