Hi all, So I think I'm probably the best placed to speak since I'm using fluidsynth both as a MIDI player and as a real-time synthesizer on Android. Obviously I didn't wait for this feature to be implemented to create my applications, so I can say that I don't them... like at all.
for the player, I didn't tried 1GB SoundFont, but honest quality SoundFonts like Arachno and Fluid R3 works great and deliver a so much better sounds that the internal Android MIDI player, or other player I found on the Google Playe Store. for the real-time synthesizer, again I didn't tried 1GB SoundFonts, but with a decent device (3-4GB RAM) I don't see why it shouldn't works... And also, frankly, having a portable SoundFont MIDI synthesizer is awesome, but if you are really into that kind of stuff, the audio output quality of Android devices is not that great... and you need a real computer...with a real soundcard. Anyway, I think dynamic sample loading is a great feature for device where memory is really an issue like embedded MCU etc... just my two cents Philippe On Tue, Apr 24, 2018 at 9:01 PM, Marcus Weseloh <mar...@weseloh.cc> wrote: > Hi Tom, > > yes, it's a little hackish... but not the part you mention, I think. > Overriding the "authority" of the synth over when and which samples to load > is perfectly valid, in my opinion. Yes, those functions would also need to > be exposed to the user via the shell and API, but that would actually be > quite trivial. They would only be thin wrappers that would retrieve a > preset by sfont id, bank and program and then set or unset the > loaded_manually flag and potentially unload the preset. > > What I think is really hackish is the way my implementation needs to go > through the MIDI file and "play" all program change and bank change events > on the actual synth instance, saving the state before doing so and > resetting it after. But it was either that, or recreate a lot of logic from > the program change mechanics in the player. Not pretty eiher way. > > So all in all I agree, let's tackle this problem if and when somebody > actually needs it. > > I keep the PR open for a few days, maybe someone on this list will want to > try it out. If nobody speaks up, I'll close it beginning of next week. > > Still, it was interesting to implement it. I got to know the player a > little more :-) > > Cheers, > > Marcus > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev > >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev