ADLMIDI/OPNMIDI: Added dynamically-changing options and others#78
ADLMIDI/OPNMIDI: Added dynamically-changing options and others#78madame-rachelle merged 11 commits intoZDoom:masterfrom
Conversation
Otherwise, it's too quite
|
P.S. A question: maybe add a separated option to let user adjust the gaining factor outside the general music volume level? |
It caused a bug that libOPNMIDI doesn't gets restart when changing these setup.
|
P.P.S. I added a bugfix (to bug I did by myself, that caused new-added options won't let libOPNMIDI to restart). |
|
Okay, speaking about gaining factor, I will make a similar option to that Fluidsynth already have. |
|
Don't yet merge this, I'll send in adddition the gaining options (I reviewed Fluidsynth's setup and making similar one right now). |
…OPNMIDI These settings has an ability to be changed on the fly, even bank can be changed on the fly with no hurt. However, I didn't yet implemented dynamic bank changing yet. I'll try in the next commit.
|
Huh, now another question: is ANY thread locking is set when changing settings of the synth together with the samples getting? I found the fact when I switch emulator to something heavy, it unexpectedly reports me that memory is danaged (via malloc/calloc), and sounds like no mutex is set 🤔. |
Since bank defines the volume model, and the gain factor supposed to be different, then it's need to be refreshed.
Since the same emulator is shared between both OPLSynth and libADLMIDI, and therefore they should use equal base class. And since libADLMIDI needs an extra function to get int16 samples, therefore, add a dummy call to all such emulators at OPLSynth so they has compatible API.
|
Okay, right now it's ready to merge. I finished the rest of updates regarding to this. |
Wohlstand
changed the title
|
Also, just now I implemented an option to use WAD's GENMIDI as a custom bank. |
Don't try to change settings if not the same synth is running. Otherwise, this might cause various odd behaviour cases like taking of changes at wrong synth. (Even conditions are fine)
|
Okay so, I am done everything today, I tested this deeply and seems should be fully fine from my side. |
Wohlstand
changed the title
|
I updated description to display multiple changes that were done here. |
|
@coelckers, ping? |
|
I done everything here a while ago, anything also that delays this merge than just a lack of free time? |
|
Yes, basically that, this is not a simple button-press merge since we have to update the zmusic stuff in gzdoom before fully accepting this. |
|
Do you have anything also than my updates? What about MY updates, I already made suitable update at the GZDoom too: ZDoom/gzdoom#3176. So, that GZDoom's PR awaits when ZMusic will be updated so CI will be built properly. And also, locally I tested and combined everything (that is related to my updates), and it just builds and works (at least on Linux where I am). I will probably need to try build the custom thing for my friend on Windows to let him test my updates I promised to him (he seriously asked them, and right now he sticked on my WinMM drivers to use them like system devices and they work slightly faulty because some controllers aren't properly reset while switching songs, but that probably another bug that I should report independently). |
|
|
|
Yes, I am working on testing that now. Everything seems good so far. |
|
Cool! |
2 participants
This update contains multiple changes: