When adding a new group of programs to a bank from the instrument db the numbers of the programs stick for two instruments. so: 0,0,1,1,2,2,3,3,and so on instead of 0,1,2,3,4,5,6,7,and so on. So I am having to manually select the program number of the patch by hand. This has proven to be an error prone process. Thanks!
Would be nice is somehow the program number reset between banks. what I mean is if I add 48 patches the program number stays at 48 in the next addition as well as stays at 48 even when I select a new number. It lets me select the new number but is reset to 48 for every other patch.
I went code diving and found a call in org.linuxsampler.lscp.Instrument that was getInstrumentIndex(). I used it instead of the call to setMidiInstrumentEntry in JSAddMidiInstrumentDlg.java. so I did this: setMidiProgram(instr.getInstrumentIndex()); instead of this a few lines down: setMidiProgram(entry.getMidiProgram()); Now this works perfect for me but I am not sure of the purpose of using the the entry object. Does it hold state? I would think that what I am doing here makes more sense but that is the way the Gigs I am importing are layed out. I want to use the index that already exists. Do you think this is a better idea or can the entry object be fixed to do the job? Thanks!
It was a concurrency issue, I think I fixed it. About the MIDI bank/program assignment algorithm you can look at org.jsampler.MidiInstrumentMap.getAvailableEntry method. I rewrote it because it was unnecessary complicated. In short, the algorithm finds the next free bank/program based on the last assigned MIDI instrument. I haven't tested it much, so it might be buggy. Of course, I can add more than one algorithm for MIDI instrument assignment if there is demand and good reason for that, so the preferred one can be set in the preferences.
btw, you should also recompile and LinuxSampler for the MIDI instrument assignment to work properly, because there was also a bug on the backend side too - the bank number provided by MIDI_INSTRUMENT_INFO notifications was incorrect
Closing this report now. If you feel that this issue is not fixed yet Chris, feel free to re-open this report. Thanks!