You can use JUCE’s BinaryResource feature. Add the file in the Projucer, mark it as a Binary Resource, and save the project. You will then be able to access it in binary form from your project via BinaryData::Electric_Piano_sf2 and BinaryData::Electric_Piano_sf2_size.
AFAIK, you can’t get it into a juce::File object directly, as juce::File represents a file on the hard drive.
What’s the type of audioSource? The class should expose means of loading a soundfont other than from a file, e.g. from a MemoryInputStream or from the binary data directly.
BinaryResource is good for small amounts of data.
but if you’re going to have gigabytes of data it could be very frustrating resulting bugfix release to actually contain the binary data again and linking to take longer (I also remember there’s a limit due to VS linker).
You can use your sf2 files but…
as a user (and ironically a mac one ), it would be easier for everyone to allow me to set where the “soundbank” is located. Apple soldered my SSD and I’d might like to put it elsewhere. (and an end-user won’t know much about symlinks…) so…
a preference file for your product would be very useful.
Check juce::PropertiesFile.
File locations, juce::File would also provide you some common paths commonApplicationDataDirectory.
in addition, cross-platform coding with JUCE is indeed minimal branching. but you’d like to use platform specific macros. (in juce that is - #JUCE_MAC and #JUCE_WINDOWS iirc)
If you’ve already release the product you can still limit the new locations to be used on Windows.
That’s excellent advice. If the SoundFonts are large and not static, and you want to allow the user to load more of them, you should implement a file choosing mechanism. In that case, you could ship an installer, which installs the sound fonts to a system directory (like ~Library/Audio/...), and read soundfonts from that folder.