Skip to content
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

Closed
sylvia-leaf opened this issue Dec 8, 2024 · 10 comments
Closed

[New feature] SiliconSFe Specification #58

sylvia-leaf opened this issue Dec 8, 2024 · 10 comments
Assignees
Labels
feature request New features
Milestone

Comments

@sylvia-leaf
Copy link
Contributor

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.

@sylvia-leaf sylvia-leaf added the feature request New features label Dec 8, 2024
@sylvia-leaf sylvia-leaf added this to the 4.0.11 milestone Dec 8, 2024
@sylvia-leaf sylvia-leaf self-assigned this Dec 8, 2024
@sylvia-leaf
Copy link
Contributor Author

SF2 sample ROMs seem to be compatible with SFe. Closing.

@stgiga
Copy link
Contributor

stgiga commented Dec 9, 2024

Can we make a Silicon SoundFont of JBSF?
@sylvia-leaf
Also, V11 is better because it doesn't make Sky Garden's melody disappear.

@sylvia-leaf
Copy link
Contributor Author

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!

@stgiga
Copy link
Contributor

stgiga commented Dec 9, 2024

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

@sylvia-leaf
Copy link
Contributor Author

sylvia-leaf commented Dec 9, 2024

I misread. You are right; it does have the entire soundfont. I got confused because one of the header's values was called sampleStart. Sorry!

I'll get to work in making a ROM compatible version of JBSF.


My reply kinda sounded like AI but it's not lol

@sylvia-leaf sylvia-leaf reopened this Dec 9, 2024
@sylvia-leaf sylvia-leaf modified the milestones: 4.0.11, 4.0-rc1 Dec 10, 2024
@sylvia-leaf sylvia-leaf modified the milestones: 4.0-rc1a, 4.0-rc2 Dec 17, 2024
@sylvia-leaf sylvia-leaf moved this to Future version in SFe 4 Dec 17, 2024
@sylvia-leaf sylvia-leaf moved this from Future version to Backlog in SFe 4 Dec 17, 2024
@stgiga
Copy link
Contributor

stgiga commented Dec 19, 2024

I misread. You are right; it does have the entire soundfont. I got confused because one of the header's values was called sampleStart. Sorry!

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.

@sylvia-leaf
Copy link
Contributor Author

My attempt to understand historical use of SiliconSF

What 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 SFSPEC24.PDF simply went unused, for example interleaved ROMs, product names, 24-bit support, etc. We wonder why Creative specified so many features that were simply never used.

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 developers

For 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 sfSampleType and then use the sample that is stored with the program files. They should also read the irom and iver sub-chunks to ensure that they support the specific ROM that is being requested, even if their own samples are used.

ROM feature flags update

The 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 available

There 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 do

We 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.

@stgiga
Copy link
Contributor

stgiga commented Dec 21, 2024

I still want SoundFont-on-a-chip to be possible so I'm veto-ing completely killing Silicon.

@sylvia-leaf
Copy link
Contributor Author

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.

@sylvia-leaf
Copy link
Contributor Author

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.

@github-project-automation github-project-automation bot moved this from Backlog to Done in SFe 4 Dec 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New features
Projects
Archived in project
Development

No branches or pull requests

2 participants