[IMPORTANT] Release reference implementation before everything else #117
Comments
|
Alright, I've renamed the SFe 4.0 release to "SFe 4.0 (pre-release)". Update 4 should be the final release. Apologies for all the inconvenience! |
|
I'd honestly prefer if the reference implementation was also in at least Rust or C/C++. Many, many people deeply dislike the JavaScript language, me included; code written in it is harder to understand and reuse for non-JS projects targeting native platforms or WASM. It also doesn't help that the spec lacks a section summarizing ALL differences from SF3 and the earlier SF2 specification. For example, I had to travel rather down to see flags indicating FLAC, Opus, Vorbis and MP3 support. It definitely didn't help that this release felt very underwhelming; simply adding more sample formats and dealing with CC# 0/32 banks doesn't make it worthy of a 4.0 release in my opinion. Silicon SoundFonts should be removed from the spec completely; nobody seriously needs it. On the contrary, it should also aim to surpass the DLS specifications and target MIDI 2.0 features (adding per-note-controller sources for custom modulators with explicit text in the spec to override per-channel sources would be useful for example, also handling pitch-attribute-to-generator cases would be helpful as well). Excess bloat from the AWE32 days should be trimmed down wherever possible. I'm merely sharing my 2/4 cents on the spec here; I don't have much of a horse in the race except for developing VSBHDASF's fork of TinySoundFont. Only other thing I'd suggest is to make it implementable with the bare minimal amount of code needed to properly support new SFe features, since many projects for retro games with MIDI support are less likely to tolerate huge libraries just to render music. I'd also suggest putting in example code for new features in the spec itself to speed up adoption and implementation but it probably won't be very useful. |
I think that we are going to stick to JS for a few reasons:
All these problems are solved with the current JS synth we're forking: it supports modulators, SF3 compression, is fully compliant and allows both reading and writing SF2 files. Not to mention one last thing: I can't speak for other members, but I just don't know C very well. It's kind of hard to write a complex C program without knowing the language, isn't it? Though if you are really fixated on software written in C/C++, then you can wait for Polyphone 3 to be released as it will be the first SFe editor. And it's written in C++ :-) |
|
It's fine if you stick to JS only, but I expect friction from all other implementers that are less familiar with the language itself, slowing down adoption. TinySoundFont and everything that used it as a reference will not have modulators (RustySynth, MeltySynth and ZiggySynth uses it as one); it was a deliberate decision to not hog low-end hardware. |
We could try to port the complete thing into other languages after it's done, maybe that would help? That way we're just "translating" JS to other languages and the outcome would be the same? That would be later down the line, though. After the spec is tested via the reference implementation, refined and properly released. But I don't see why we wouldn't do it :-) |
|
Thank you everyone for all the feedback! Cacodemon's comments
This is a problem. We will add a section that summarises everything you need to know in specification update 4. Stay tuned!
I understand why you thought the 4.0 release was "underwhelming" - in fact, the original scope of the SFe specification as planned in 2020 was far wider, including:
Because adding so many features at once would make it even harder to create a reference implementation, and would likely overwhelm developers that want to make their programs compatible with SFe, we decided to only include the most important new features in the initial 4.0 release. However, many of the features originally planned for SFe 4.0 will appear in future releases:
Some of the above planned features, such as increased name size and multiple loop points, were deemed to make the file incompatible with legacy SF2.04, and were thus cut entirely. They will be reintroduced in a later version.
Talking about SiliconSF, despite our research concluding that no-one ever used it, one of the members of the SFe Team would rather it be kept in. However, what we can do is to move it to a separate specification, like we did with TSC, which was an older workaround to the 4GB limit inherent in 32-bit file formats (before we concluded 64-bit and later still, dynamic, was the future). We'll keep the AWE ROM emulator specification in because it may be useful to run really old SF2.0x banks, and we also plan on adding new, modern features that take advantage of the infrastructure of what used to be ROM samples.
Well, with SFe 4.2, we plan on incorporating SynthFont Custom Features (SFCF), a set of functions implemented by Kenneth Rundt's SF programs (including SynthFont and Viena) that includes DLS features, as well as playing the sample to the end. And by SFe 4.4, we want to have all of the DLS features that were not implemented in legacy SF2.04 added to the specification.
This is also something that we are interested in doing. There have apparently been plans by FluidSynth to extend SF2.04 to include support for MIDI 2.0, so I think the MIDI 2.0 support specification for SFe would need to be based on and be compatible with any future FluidSynth implementation. Remember that one of the main purposes of SFe 4 is to be one specification which encompasses as many existing extensions to the legacy SF2.04 format. Spessasus's comments
Do I need to say anything about Segfaults? They are annoying. That being said, Cacodemon mentioned Rust, which should have sufficient memory safety to ensure that such an error doesn't happen.
Well, I don't know JS too well either. So, I think that it's a good idea to have reference implementations in multiple programming languages. Spessasus mentions that we can make an implementation off Polyphone, which is written in C++. Questions
|
|
I'm issuing an automatic VETO on removing SiliconSF. The whole "nobody needs it" argument is fallacious and pedantic. SiliconSF will stay. It's a real version of a long-standing idea I had of SoundFonts on chips. Removing it is equivalent in my view to confiscating my computer as someone whose life is computers, and will not be tolerated here. Verdict: WONTFIX, and you can't change that. I spent hours studying the spec. I'm not throwing THAT away for anyone. SECONDLY: |
|
Sorry if I'm a bit heated, but the whole "it's redundant/useless" is EXACTLY how enshittification starts (cutting stuff just because it is "unimportant"), and I will NOT be party to that. No examples are wanted. |
|
Remember, our goal is to add features, NOT remove them. Removing SiliconSF would defeat the purpose. So please don't. |
|
Sylvia asked for splitting up the SiliconSF, similarly to what we did with TSC, not outright removal. Are you against that as well? |
But even that isn't necessary. Look, there is literally NO reason to remove or split SiliconSF, other than some people thinking it is useless. TSC on the other hand is something I like, but the separation reasons have some basis in reality. Meanwhile there is NO rational reason to remove SiliconSF or even isolate it. It does absolutely zero harm, and it isn't lawyering the SF2 spec's wording like TSC (not that I hate it). It even ADDS stuff like checksums and the Style field. Why the HELL would we throw away an upgrade for no reason based on rational thought. |
|
Please don't enable enshittification with the "redundant"/"useless" reasoning. |
|
|
|
Alright, I got it reading your first message, Stgiga. You want SiliconSF to stay. That image and comparing removing a feature to Russian roulette was unnecessary as you've already made your point. I personally am indifferent to this, as it doesn't hurt to give it a try. But since you're very interested in the SiliconSF, I hope that you will help in implementing it in the reference implementation. If it works and proves to be effective, great. If not, we'll think about it later. |
|
We've had a strong response against (re)moving SiliconSF. Therefore, it's going to stay. However, because we recognise that many programs will not be implementing it, it will only be a requirement to meet level 4 of SFe compatibility. I never wanted to remove it anyway, because while many people may not be using it, I wanted to to build features on top of the infrastructure in the future anyway. |
|
In my defense, I'm sort of unhappy with IRL matters too, so sorry for being the next Linus Torvalds. |
|
Namely, it's an issue with my group project in uni. The details don't need mentioning. |
|
Don't worry, it's fine. But don't forget to stay calm, because it makes the SFe project look more presentable. |
|
Definitely. |
|
I feel like I should go work on some stuff unrelated to the project so I can chill. |
|
Unfortunately due to my course of study at university I may not be able to get the reference implementation done for the next few weeks, but after this, hopefully I should be able to continue working on it. |
|
I think, most importantly, we SHOULD listen to the concerns that exist about elements of the standard. @sylvia-leaf There are QUITE a few things we could have and should have done better, and that has been made clear. It turns out that what prompted this entire Github issue wasn't even everything that there had been some objection to. |
|
Unfortunately there's been some pushback and I was low on time to do this but apparently we are supposed to remove saga from the credits. So I did. @sylvia-leaf |
|
Note that this will probably upset the team, but
so, what now? Do we keep going with SFe4 or do we start from scratch and create a new sound bank file format? |
|
I somewhat agree with manx's assessment of the spec to be honest. The main criticisms IMO to focus on should be:
I disagree with the idea of dropping SF2 baggage completely; this will cause the concept-to-implementation stage to take too long for existing SoundFont synths. |
|
I'm overruling you on SiliconSF removal, otherwise I don't have any objections. |
|
I'm going to amend the policy to say that feature removal is considered vandalism. |
|
I hate having to go full Linus Torvalds on the issue, but actively downgrading from SF2 is counterintuitive to our goal to extend SF2. Other changes are fine, but actively removing features is completely against this whole project and shall never be attempted or considered. No examples are wanted. |
I did, and it seems wildly pointless to be honest; quad-word fields for size is enough for everything. Instead of that, I'd suggest this: typedef struct {
uint16_t strLenOfCC; // length of string identifier.
char nameCC[strLen]; // strictly ANSI-only.
uint32_t chunkSizeLow; // same as in RF64
uint32_t chunkSizeHigh; // same as in RF64
} Riff64Named;
|
|
Also, there are reasons why my personal Discord has an ironclad rule about not endlessly picking holes into things. This isn't a blanket dismissal of the fact that work needs to be done, but what it IS is a line-item permanent veto of downgrades. |
|
I don't want to be rude, but isn't the point of this whole project to collaborate with others? Because so far your actions can be summed up as: nope, I don't agree and I have write perms and you don't so you will listen to me. The whole point of this was to collaborate with others to create a new format. Collaboration means discussing stuff with others. You for example didn't name one reason for siliconSF to stay as a required part of the SFe spec. Quoting you:
So again, is this solely your project or is it a collaborative effort? Because I'm starting to think that it's the former. Telling other team members what they can and can't do does sound a bit like a power trip, no? No explanations, no reasoning, just because I said so. Again, nobody said to entirely delete what you've created. There were ideas of splitting it up as its own thing, but you said no and nobody can say anything. Please, at least give a good reason for SSF to be an integral part of the spec, a reason that will make developers want to implement it and support it. That's all I'm asking for. |
Would you be fine with it being mandatory for Level 5 compatibility as opposed to Level 4? Level 5 would mandate Level 4 + SiliconSF, but Level 4 would make it strictly optional but make everything else mandatory to implement. I mean, some level of concession has to be made; you appear to be trying to fight a war on the losing side against at least 3/4 stakeholders not wanting SiliconSF stuff to exist in 2025. |
|
It's collaborative, but in this case removing SiliconSF is an action directly against our goal of adding features, and shouldn't be on the table. Also wasn't Format Levels part of the contention to begin with. But sure, like another removal I objected to, I'll allow it to not be completely removed, rather delegated. But removing it completely == vandalism. |
|
By the way, of the two isolations I allow, permanent complete removal of either will be rolled back for being out-of-scope. |
|
At least that's better than telling everyone to implement it for full-spec compliance. |
|
I hate being Linus here, but we are extending SF2, not trimming it. Keep in mind that I'm the person who thinks channel count on Discord servers is a non-concern. |
|
I apologize for the contention, I just felt like we shouldn't go against the entire purpose of the project. Honestly these days I've been a bit on-edge for unfortunate reasons having nothing to do with the Internet, so I may be a bit moody at times. |
|
So, there's been a lot of talk about the future of the SFe format and whether it is fit for purpose, or if we should start again from a non-soundfont-like format structure. We want to place the foundations of the functioning of the SFe team and use SFe 4 to start things off. We won't throw away the entire legacy soundfont structure in SFe 5 - we'll gradually change the structure until it may or may not be unrecognisable from legacy soundfont. This could happen in SFe 6, SFe 7 or even SFe 10 for that matter, but it won't be SFe 5. SFe 5 will be for the most part relatively similar to SFe 4 and legacy soundfont, but will have the number 5 as it will not be compatible with legacy soundfont. What I thinkSpessasus comment 1:
The consensus here is that we want to make an NGMSS. The problem is that I attempted to make an NGMSS and couldn't do it. However, if I put some more effort into making one, then it can be an option. Also, going straight to an NGMSS misses the point of SFe - extending the legacy soundfont format to give it a few more important features, and then building from there.
Yeah, we should've done this first. But we can do this for the significant bugfixes to the specification.
Not happening. We may replace it with a new system that achieves the same thing while being far more expansible, but this is a part of SFe 4.0 that will stay. However, the reference implementation will need to be able to read it.
For now, what I'll do is to remove big endian support, leaving just 32-bit RIFF and 64-bit RIFF. In a later version, we then use Spessasus's dynamic RIFF-like format, which is optional for SFe 4.x and required for SFe 5.x and later and potentially even later versions of SFe 4.x. This immediately means that the reference implementation for RIFF-like chunk formats is complete. The conclusion is that this will be done for SFe 5.x. RIFF64 is very easy to implement, however RIFF dynamic allows almost infinite scaling of the format and results in fewer unused bytes. Using dynamic field sizes throughout the format can also result in significant size optimisations elsewhere. RIFF dynamic can also be the starting point of a new format that fixes inherent problems of RIFF-like formats.
Such a format already exists. It's called SFZ. If we wanted to do that, then we should've based SFe on SFZ instead. That being said, higher SFe abstraction levels (in the future) are planned to be SFZ-based and by their very nature will be like this.
This is a good idea. We don't expect program developers to implement rarely used compression algorithms. Cacodemon comment 1:
Because SFe 4 is designed to be mostly compatible with legacy SF2.04, we may be able to add a bitdepth value in
This can be simply added to the metadata and will likely be defined in SFe 4.1 or 4.2.
If what is meant by "sample-rate specification" the 400-50000 limit the SFe specification is already unaffected by this limitation.
This would be one of the purposes of sfelint - to remove unnecessary metadata from samples.
No, we should focus on wav/opus/flac.
This could be implemented by extending RIFF dynamic into something that doesn't rely on fourcc's. Cacodemon comment 2:
The point of RIFF dynamic is not only to allow going beyond 64-bit, but also to save space by allowing 40-bit, 48-bit, 56-bit, etc. We're also able to extend RIFF dynamic to fix the problem with fourcc's, but it needs to be done slowly to ensure that the target isn't moving too quickly for program developers to adapt to and causing a version fragmentation problem. Spessasus comment 2:
I agree with spessasus here. We shouldn't be rude to each other. Cacodemon comment 3:
This is something that we can and will do. The SFe reference implementation may be released initially without SiliconSF support, but it will eventually be available. It just won't be our priority. In fact, there won't be a separate "level 5", it will be "level 4 with SiliconSFe". We chose four levels because that was the same number that the Spessasus/Falcosoft RMIDI specification included. Stgiga comment 1:
SiliconSF won't be removed but it will be explicitly made optional, similarly to TSC. Other important thingsNote that the feature set of 4.0 and 4.1 are already frozen. If we wanted to add these features to either 4.0 or 4.1 the "concept-to-implementation" time (as Cacodemon mentioned) would take even longer than it already does, considering other commitments on my part like my university degree, future projects or similar. The changes that are outlined here will be made for the next update. |
|
I apologize for my stressed response. |
|
Alienating the OpenMPT people with this mess of a spec and the miscommunication wasn't necessarily a good idea either (and it was indeed very bad). Best that can be done is attempting to get the FluidSynth guys on-board for this specification and fixing up all mistakes pointed out so far, and repairing the damage from miscommunication on the OpenMPT forums (no offense intended to stgiga). Shame that MP3 is getting excluded; it'd allow significantly reducing the file size of soundfonts. |
isn't opus better in like, every way? And MP3 is super old and saga mentioned that it could cause trouble during real-time decoding. |
|
I accept responsibility for the mess. But hopefully, we can fix it and make this something that everyone will want to implement in the future. Also, if you read the newly updated specification (Update 5), mp3 is listed as supported. |
|
We shouldn't use MP3 IMO, what advantages does it have over opus or vorbis? Quoting saga's original response:
They are right about that one, and also this introduces another codec to add as a dependency, which will increase the size of programs, such as a web synth like the reference implementation. I propose we remove MP3 as there's simply no reason to use it over vorbis or opus. Both are widely supported, open, and have better compression rates, without having problems saga mentioned. Edit 2: I am mostly against mp3 because having yet another codec will greatly increase the size of my web app and this is something I very much want to avoid. |
Now that you mention it, if Opus is supported MP3 support shouldn't matter. https://web.archive.org/web/20200530160052/https://stsaz.github.io/fmedia/audio-formats/ At least Opus managed to have lesser file size than MP3 and the latter was objected to so MP3 can be dropped. |
|
Oh and Silicon's Style and integrity checksum fields are useful even in non-Silicon contexts, just so you know. |
|
I'm going to attempt fixing Enchant and Eternal to support SC-8850 in a single part @sylvia-leaf Which parts contain what? https://archive.org/download/soundfonts-kor-ninja/Enchant%21%20%5BEOL%5D/ has Enchant in full. |
|
Well it doesn't fit, even after trimming everything that isn't SC-88x. |
|
See, you never released a bank that went for 8850 all in one file. |
https://forum.openmpt.org/index.php?topic=7297.new#new
Saga is right about one thing: we need the reference implementation now.
In hindsight, it's really silly of us to not think of that earlier. How can we release the spec before the reference implementation? Think about the developers:
So yeah, we shouldn't announce SFe as released until the reference implementation is done.
The text was updated successfully, but these errors were encountered: