-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[New feature] SiliconSFe Specification #58
Comments
SF2 sample ROMs seem to be compatible with SFe. Closing. |
Can we make a Silicon SoundFont of JBSF? |
It seems that SiliconSF only includes the samples. We can create a SiliconSF of JBSFv11, but we would need a program that can handle ROM samples. Because modern SF editor programs were not designed to create SF banks for use in legacy soundcards, they don't allow you to use ROM samples. It would be useful to keep a version of JBSF as a reference implementation for SiliconSF, however! |
Wait, so Silicon SoundFonts are NOT ROM versions of proper SoundFonts? Well, that changes things, but it DOES open up the idea of linking SoundFonts together as we discussed in 2023. @sylvia-leaf |
I misread. You are right; it does have the entire soundfont. I got confused because one of the header's values was called I'll get to work in making a ROM compatible version of JBSF. My reply kinda sounded like AI but it's not lol |
Honestly, Silicon SoundFonts is something that is cool, but it's sad that it was never used (to the best of our knowledge), especially given that because it was "never" used, WE are the pioneers of actually implementing it. All we have to go off of is the spec. This isn't a bad thing, but we have to take the spec very literally here. Now, I know Creative/EMU probably intended Silicon SoundFonts to be used in their samplers as a sample ROM, even though they never used it. But we're feeding it a chiptune SoundFont, so the first use of SiliconSF is as a new retro sound chip, which is funny. The funny thing is that they DID add 24-bit support to SiliconSF despite never using it. And yes, they did acknowledge 24-bit values being not a power of two and devised a workaround. The SoundFont spec is quite an interesting read. |
My attempt to understand historical use of SiliconSFWhat we know is that Creative/E-mu never released alternative ROMs for Sound Blaster users to use with their card. But there is something that we don't know: was SiliconSF used for the pre-installed 1MiB ROM found in the AWE32/64? Because I don't have access to an AWE sound card and/or the tools that are necessary to analyse how things work, I don't know what format the AWE32 ROM used, and if it even was SiliconSF. I suspect that SiliconSF may well have been used to construct the 1MB ROM, but many of the features in the specification given in Ultimately, to my knowledge the only ROM chip that Creative ever used in legacy sound cards was the 1MiB EMU8011 (used in the AWE), because the EMU10K1 added the ability to use system memory (due to the switch to PCI) and eliminated the need for a ROM. The EMU8000 itself did permit up to 4MiB to be used for sample ROM, but again, no sound card with this amount of ROM was ever released to my knowledge. We assume that Creative would either have used the interleaved ROMs feature for such a card, or had a successor to the EMU8011 in development before scrapping it in favour of using system memory in the Live!. What should we do regarding SiliconSF?Until more information regarding the use of SiliconSF in the AWE cards becomes available, we can't do too much. Because the chiptune SoundFont (JBSF is legacy SF2.0x, right?) is gigabyte-class and wouldn't fit into the EMU8011, we should start by constructing a SiliconSF bank using the AWE ROM emulator samples (that would fit into the EMU8011) and then find a way to test it on a hardware AWE sound card. If it does not work on such hardware, we cannot release it as the reference implementation of SiliconSF for SFe. All we need to do is to stay compliant with the specification, which is currently the only information that we have on the matter. Information for SFe program developersFor SFe program developers that implement a AWE ROM emulator in their program, they do not even need to implement the SiliconSF specification at all! What they need to do is to detect bit 15 set in ROM feature flags updateThe feature flags regarding the ROM sample systems will be updated to reflect the fact that it is extremely unlikely that E-mu released any soundcard or other hardware with a larger than 1MiB ROM, or even any ROM sets beyond the 1MiB General MIDI set that is included with most, if not all AWE sound cards. Space usage will be made significantly more efficient. This is the last time that we will move feature flags around for SFe 4. Because SFe 5 will not be 100% structurally compatible with SFe 4 and legacy SF, we may move feature flags around for that version. The possibility of third party alternate ROMs being availableThere may also be third party alternate ROMs available for the AWE soundcards, but we will need to do more research on this topic as well. I've opened some issues relating to these topics in the rom-emulator-samples repository. My opinion is that it is relatively unlikely that such alternate ROMs exist, because it would involve replacing the EMU8011 with a compatible ROM chip, which is something that seems quite difficult. Things to doWe should complete the tasks found in the checklist here. After that, we can work on making changes to the SiliconSFe specification that diverge from the Creative/E-mu version of the SiliconSF specification, such as introducing 64-bit support to the header format used in SiliconSF (planned for version 4.4). For SFe 5, we plan on completely replacing SiliconSF with a system that also allows use with ROMs, but is easier to use. DLSification is likely to happen, because we plan on DLSifying parts of SFe 5. |
I still want SoundFont-on-a-chip to be possible so I'm veto-ing completely killing Silicon. |
Legacy SiliconSF support will never be completely removed from SFe. Anyone is free to use SiliconSF headers with SFe and the resulting format is called SiliconSFe. However, the successor to SiliconSF is AL1. AL1 will permit you to include your banks in a ROM, but will use a format that is specifically designed to work well with SFe. You will continue to have the choice between SiliconSFe (using SiliconSF headers) and AL1 (using SFe-AL1 headers). You can rest assured that we will continue to allow the embedding of sound banks into ROM chips. |
Closing as completed. The SiliconSFe specification for 4.0 is identical to SiliconSF, but more features will be added. Tracking related issues in the ROM emulator samples repository. |
The
SFSPEC24.PDF
includes a section called "Silicon SoundFonts". This gives information on how to embed soundfont banks into ROMs. However, SFe does not include its own version of Silicon SoundFonts yet.Fixing it by taking the SF2.04 SiliconSF standard and adding SFe features to it.
The text was updated successfully, but these errors were encountered: