When two program change messages for two different channels are sent in quick succession, the first one is ignored.
- Create an instrument map with two programs (0, 1)
- Create two sampler channels, assign one to MIDI channel 0, assign the other to MIDI channel 1
- Assign the instrument map to both the sampler channels
- Send these two MIDI messages to linuxsampler <192, 1, 0>, <193, 1, 0>
As the result, linux sampler changes the program (i.e. loads the instrument) only on the second sampler channel (i.e. for the message <193, 1, 0>).
If however there is about 100ms delay between the two MIDI messages, everything works fine.
Yes, I am aware about this bug. It is hanging around for a while now. And I also tried to investigate it once, but could not find the root cause of this misbehavior. The problem is that quite some amount of code base involved in processing those program change messages and it is not that easy to debug it. There are several threads, FIFOs and a bunch of classes involved.
Created attachment 70 [details]
Please try this patch (apply it against latest LinuxSampler SVN version).
(In reply to comment #2)
> Created attachment 70 [details]
> Proposed fix.
> Please try this patch (apply it against latest LinuxSampler SVN version).
I'm using LinuxSampler on Windows, thus it's a bit difficult for me to recompile it. I more or less followed the instructions on https://www.linuxsampler.org/msys.html, but in the end (after all compiled successfully), the linuxsampler crashes for some reason. I would guess it's connected to some incompatibilities in the libraries (i.e. not worth investigating). Would it be possible for you to send me a Windows binary please? Alternatively, I may try Linux in VMWare.
Fastest solution would be if you try the patch out on Linux. I'm rarely using Windows and the Windows binaries of LinuxSampler are automatically build by our server once something new was commited to SVN. However I don't want to commit this yet to SVN before it has been tested.
(In reply to comment #4)
> Fastest solution would be if you try the patch out on Linux. I'm rarely using
> Windows and the Windows binaries of LinuxSampler are automatically build by our
> server once something new was commited to SVN. However I don't want to commit
> this yet to SVN before it has been tested.
Thank you Christian. I'll try it and report the result.
I made a short test and it seems the patch has solved this issue. So I commited it now to SVN. A new Windows snapshot (with this fix) should be available for you in a few minutes.
What you could test though, is whether it also works for sending program changes messages simultaniously for 16 sampler parts or more. If it only works for i.e. 10 parts or so, then it might be that some buffer somewhere is still too small.
I've tested it with simultaneous program change on 16 channels. It seems to work. Perfect! Thank you.