About bug #252 Note pool empty
Posted: Wed Mar 29, 2017 2:41 pm
Hi,
I'm facing the same bug now.
I gave it some try, and finally found what leads the 'empty pool', and it's workround (at least on my case).
I'm using multiple sfz file on same channel.
(It means, LOAD INSTRUMENT * N times to same channel)
And these sfz files have adjacent note number as shown below.
--
sfz#1 : includes key=36
sfz#2 : includes key=37, key=38
sfz#3 : includes key=42
dmesg output of fillMapArr() is shown blow.
0 36 37 128
0 37 38 39 128
0 42 43 128
--
This setting always generate 'empty pool', and number of the dmsg output 'Engine: Note on received' (and 'off') is much greater than MIDI file's Note on/off events number.
When I spell-missed wav file's path (so, resulting specify NON-EXISTENT FILE) in the sfz file, LS does not report error, and continue processing.
If I play .mid file on this state, Note is only allocated more and more, but not freed.
So, I doubt that the cause of this bug is something like 'to play non-existent sound, and wait forever'.
(On the above case, note #37 maybe try to play sfz#1's instrumental (which only defines note #36))
Workround #1 : do not use separate sfz files on same channel.
Workround #2 : use separate sfz file on *each* channel.
Both workround fix the bug on above case.
I hope this workround works for original bug reporter...
I'm facing the same bug now.
I gave it some try, and finally found what leads the 'empty pool', and it's workround (at least on my case).
I'm using multiple sfz file on same channel.
(It means, LOAD INSTRUMENT * N times to same channel)
And these sfz files have adjacent note number as shown below.
--
sfz#1 : includes key=36
sfz#2 : includes key=37, key=38
sfz#3 : includes key=42
dmesg output of fillMapArr() is shown blow.
0 36 37 128
0 37 38 39 128
0 42 43 128
--
This setting always generate 'empty pool', and number of the dmsg output 'Engine: Note on received' (and 'off') is much greater than MIDI file's Note on/off events number.
When I spell-missed wav file's path (so, resulting specify NON-EXISTENT FILE) in the sfz file, LS does not report error, and continue processing.
If I play .mid file on this state, Note is only allocated more and more, but not freed.
So, I doubt that the cause of this bug is something like 'to play non-existent sound, and wait forever'.
(On the above case, note #37 maybe try to play sfz#1's instrumental (which only defines note #36))
Workround #1 : do not use separate sfz files on same channel.
Workround #2 : use separate sfz file on *each* channel.
Both workround fix the bug on above case.
I hope this workround works for original bug reporter...