The Future of the SFZ Format

[infectedpimple]

It occurs to me that SFZ has been around awhile now and taking a superficial survey of the current landscape suggests that it's fairly widely supported to varying degrees, but at the same time I can't help but feel that it hasn't nearly reached its full potential. I also get the general sense that it's been somewhat fractured between Plogue, NI, Cakewalk and LinuxSampler, and whoever else might have their toes in the pool.

Now I guess it should be said I'm a freeware guy, my lack of musical talent conspires with other expensive interests to limit my spending to barebones interface gear and the such; I even still use the old RGC SFZ player for most of my SFZ needs, with LinuxSampler serving for the heftier playback tasks (Salamander Piano, for instance). So maybe I'm just not floating in the right spheres that might lead me to a more rounded impression of its current state--perhaps there's some developers out there working SFZ to its full limit that I'm just not aware of. But my own experiences assembling samples into an SFZ and viewing those SFZs provided by others illustrate that authoring these is mostly a messy and tedious undertaking, often limiting these instrument sets to basic key definitions and not much else. Simple enough for basic drum kits and the such, but discouraging for larger efforts. I've seen a few comments hither and thither here that it's easier to produce a set in another format and then convert it to SFZ using one of the major format translators. That seems a little silly to me, honestly. Recently I assembled a couple of sets from messily-named samples and discovered it far easier to write a somewhat convoluted script to do it for me, rather than mucking about in the text file--and I'm not much of a programmer, so that was kind of telling.

The process of whipping up the SFZ-writing script also lead me to thinking how much easier a lot of things in SFZ would be if it had some basic scripting as part of the standard--how nice it would be replace huge blocks of opcodes with more elegant if or switch statements and the like, not to mention the alluring prospect of having a free and open rival to domain currently monopolized by NI/Kontakt.

So I guess there's a few questions wrapped up in all that, which I hope spurs a little discussion:

What options are out there, extant or pending, for elegant creation and editing of our SFZ files? Particular interest given to those that venture beyond basic key-mapping, which is helpful but at best only half-way home for more complicated projects. Are there any? One of the things that interests me in regards to this is the proliferation of high-quality freeware VST effects and instruments out there today--a lot of talented programmers trying to get noticed in an increasingly saturated field--pun somewhat intended. I'm just surprised one of three haven't aimed to make their name providing the definitive SFZ editor.

Next, iss there any sort of movement being made or growing inclination toward implementing scripting, by one of the major players or otherwise? I could see NI being resistant seeing as it would undermine their stranglehold on a powerful aspect of sampling. What exactly would it it entail drawing up the initial spec? What would be the aim to include? Etc. Etc.

What is the general overall feeling of how the various players are handling the standard? Do their implementations reinforce the spirit of its original ambition to being open and such, or are they each trying to pull the standard toward self-serving, proprietary directions (ala, for instance, Microsoft's attempt to to dictate web-standards through its IE monopoly--esp. IE6) through non-standard opcodes and idiosyncratic implementations of standard opcodes?

And finally, would the format be better served to have a central, neutral, dedicated group maintaining the standard, similar to W3C and other such organizations? The few sources of of the standard spec floating around seem to offer differing opinions of what the actual spec is--and I don't even think the 2.0 spec is available aside from in an obscure book, or am I wrong? Either way, it seems that this disorganization is a limiting factor in SFZ's evolution. Then again, does it need to evolve beyond what it is already? What needs rethinking? What need always be preserved? What do you hope it becomes or doesn't become?

My apologies for the dissertation, but hopefully those who get to the end of it will offer their thoughts and elucidations in the matter for my edification, which perhaps will prove useful to others as well, for which I now thank you kindly!

[davidv@plogue]

Hello

Where to start? I think this is going to be a long thread (and I for one look forward to it). Its a challenge for me to reply without any bias, but I'll try.

First there is nothing close to full blown graphical editor or the format, and It would be a great challenge to make one because of the flexibility of the spec and that you can 'overload' any parameter in every child 'leaf'. So the main strength of the spec, is ironically what makes building a graphical editor for it a challenge.
But for me (and my partners @ Garritan), being able to make instruments using scripts/tools and finding and replacing values/paths etc more than compensates for this.

As far as scripting goes, as SFZ is really MIDI-input centric, any implementer can create its own MIDI pre processors, either in code (what we do), LUA (what we could easily do), or some other solution. However as far as having access to the engine's internals-side of scripting (like K does), then it becomes much harder to make the script 'hooks' standard as it would enforce lots of engine-implementation-specifics to become standard, something that is clearly impossible across vendors unless they rewrite everything. Say get callbacks when note dies, callbacks when this or that.

I'm, for one hoping that a standard/neutral SFZ body becomes a reality. As the discussions we've had about this are under NDA, you can understand that I can only say so much.

or are they each trying to pull the standard toward self-serving, proprietary directions (ala, for instance, Microsoft's attempt to to dictate web-standards through its IE monopoly--esp. IE6) through non-standard opcodes and idiosyncratic implementations of standard opcodes?

This is perhaps the single most important issue we face. Bias aside (trying), as I previously mentioned in the sforzando player manual http://createdigitalmusic.com/2012/12/s ... le-player/ we tried to make sure our ad-dons make sense and didn't break SFZ 1.0 and SFZ 2.0. Some of these addons were in fact discussed with René before he left Cakewalk, but for the rest, we have products to ship which sometimes require features that are _not_ in the original spec.

Current list of our custom opcodes and some justifications have been published here
http://ariaengine.com/forums/index.php? ... des#Item_1

[pljones]

One of the things René made pretty clear when he was working on sfz.dll is that the format was open to others to extend and implement as they saw fit -- thus there was no need for anything particularly formal. It was one of the reasons I tried to capture SFZ 1.0 as clearly as I could on my site. SFZ 2.0 is anything beyond SFZ 1.0 really. It's what the various Cakewalk sampler-based synths use - each having its own version of the engine with subtle differences. Hence Simon Cann's book tried to capture as many of these as possible along with the majority of the common "2.0" opcodes. As David says, you then have the ARIA engine with its own extensions, which he has documented. Last time I looked, linuxsampler had an inaccessible page listing the opcodes it implemented but little more (read the source...).

All a "standard" for the format can ever really offer are:
- tokenisation guidelines (i.e. split on whitespace except during filenames; noting that "except during filenames" was specifically "except for the sample opcode" in SFZ 1.0 and maybe should always be..?)
- token parsing guidelines (i.e. opcode=value, <header>, comments, etc)

You could theoretically provide guidance on how to construct an opcode and how to avoid clashes if adding new ones. Here I'm thinking (for example) of how {someop}_loccNN gets constructed for the full range of MIDI CC numbers, if it makes logical sense, and so on.

What you can't do is really provide a sensible "minimum spec" as that's down to the underlying engine - maybe it doesn't have a low pass filter, for example.

So an editor could have "profiles" that define the capabilities of a set of known engines. It could then provide editing support for those engines and even guide as to when engine-specific features were available (or not). However, it would be challenging to support advanced features - such as the #define and #include directives in ARIA engine, I would imagine. (Take a look at my ARIA-SFZ mappings of Analogue Drums' Tape Series 2 kits, for example.) Notepad++ with a bit of highlighting support - and some scripts, cut'n'paste and cross-file global replace - works really well for this.

[SampleScience]

From what I've read so far, sfz seems problematic. I'd like to offer libraries in the format, but I don't feel it will be worth my time because of the issues discussed in this thread. For a sound developer, it's easier to stick to one sampler engine (ARIA for instance, or Rapture, Alchemy, etc.) and go with it.

I might do a test in the future and ask people to try a sfz instrument of mine in their sfz compliant sampler. I have a lot of them, but not all of them.

[electro]

Just about every softsampler can import .sfz

Plogue has a free .sfz sample player.
http://www.plogue.com/products/sforzando/

Do any of you know is .sfz can accommodate 24bit 192Khz samples?

[davidv@plogue]

Do any of you know is .sfz can accommodate 24bit 192Khz samples?

sfz is pretty much samplerate/bit depth and to an extent sound file format agnostic.
Dimension Pro (last update) supports wav/aiff/ogg/flac. ARIA does that and more.

[stanlea]

Maybe one major issue of sfz is that it's not a closed format. How do you protect sfz banks ?

[infectedpimple]

First there is nothing close to full blown graphical editor or the format, and It would be a great challenge to make one because of the flexibility of the spec and that you can 'overload' any parameter in every child 'leaf'. So the main strength of the spec, is ironically what makes building a graphical editor for it a challenge.
But for me (and my partners @ Garritan), being able to make instruments using scripts/tools and finding and replacing values/paths etc more than compensates for this.

Yeah, that's definitely a valid observation, and a general catch-22 of any programming/scripting language where flexibility often comes at the cost of ease of access and vice versa. Still, I'm curious at least if there's an optimum compromise to be had. I can certainly agree the text-editor based find-replace method and script/batch method offer quite a bit of automation at least for those of us who are familiar/comfortable with these already or not intimidated by the thought of taking them up. But it also seems this allows for more human-error to seep into the mix. Another of the format's double-edges is its forgiving nature, skipping what it doesn't understand, assuring in most cases some kind of playback, but not necessarily as was intended by the author, which can lead to some confusion--I know I've spent my fair share of hours scratching my head trying out why an instrument wasn't working the way i wanted only to discover some silly error as a misnamed opcode or what have you. Exasperating the issue is the wall-of-text effect where it becomes difficult to get a visual overview of how our samples our grouped--I mean you can only see so many lines of text at once. Syntax highlighting/folding as mentioned does help some but is not always the needed panacea.

I guess the main question here is whether the time/effort/resources needed to develop such a tool (at least to the point where it could offer a more accesible bridge of sorts between SFZ's flexibility and its hurdles) could be offset and then some by the potential for time saved in authoring the SFZ files as well as the possibility of increasing interest in format to those who otherwise had no interest in it or who engage with it purely at the consumer level.

As far as scripting goes, as SFZ is really MIDI-input centric, any implementer can create its own MIDI pre processors, either in code (what we do), LUA (what we could easily do), or some other solution. However as far as having access to the engine's internals-side of scripting (like K does), then it becomes much harder to make the script 'hooks' standard as it would enforce lots of engine-implementation-specifics to become standard, something that is clearly impossible across vendors unless they rewrite everything. Say get callbacks when note dies, callbacks when this or that.

That does seem to pose quite a challenge, in so far as realizing some kind of standard scripting library or whatever, probably realistically insurmountable. I guess my concern then for the future is as individual players implement and become more reliant on their individualized scripting methods, at what point do we lose the original spirit of the format? On the other hand, I guess there will always be the "vanilla" standard which presumably would still be supported in future players, however robust their proprietary aspects become, so maybe it's not as problematic an issue as my own biases make it seem. But still, it seems more likely to add to the "forking" of the standard as opposed to unifying it; in some ways maybe that's not such a bad thing, competing strains pushing developers to conjure up more useful features, and then borrowing/stealing from each other as those features work out their worthiness or unworthiness overtime--standard fare in software development. In the end, I may simply have to admit that this little dream is a case of wanting to have the cake, and eating it too. I wouldn't have expected anything close to what Kontakt has achieved in any case; just that the SFZ format seemed ripe for at least some sort of basic scripting core that that could, like the opcodes themselves, be implemented universally, but expanded upon by parties as they see fit. But I think your case has been made that that will probably remain outside the scope of the standard. I'd love for us to be wrong about that, though!

This is perhaps the single most important issue we face. Bias aside (trying), as I previously mentioned in the sforzando player manual http://createdigitalmusic.com/2012/12/s ... le-player/ we tried to make sure our ad-dons make sense and didn't break SFZ 1.0 and SFZ 2.0. Some of these addons were in fact discussed with René before he left Cakewalk, but for the rest, we have products to ship which sometimes require features that are _not_ in the original spec.

That's a philosophy I can get behind; as I mentioned above re: scripting, the variation between implementations and additions definitely has as much potential to strengthen the SFZ "species" overall as to fracture it. My hope is that SFZ files always maintain a certain level of genetic recognizability so to speak between players. But as noted the scripting conundrum might over time undermine that hope. Ultimately I suppose market forces might bear that out better than anything--people will want to use what works best for their needs, after all. I just sort of cringe at the thought of people having to employ multiple SFZ players for esoterically constructed SFZ instruments--I'm a subscriber to to Alton Brown philosophy of no single-use tools in the kitchen--no sense having different toaster with differently shaped slots for different styles of bread, just get a toaster oven, right?

One of the things René made pretty clear when he was working on sfz.dll is that the format was open to others to extend and implement as they saw fit -- thus there was no need for anything particularly formal. It was one of the reasons I tried to capture SFZ 1.0 as clearly as I could on my site. SFZ 2.0 is anything beyond SFZ 1.0 really. It's what the various Cakewalk sampler-based synths use - each having its own version of the engine with subtle differences. Hence Simon Cann's book tried to capture as many of these as possible along with the majority of the common "2.0" opcodes. As David says, you then have the ARIA engine with its own extensions, which he has documented. Last time I looked, linuxsampler had an inaccessible page listing the opcodes it implemented but little more (read the source...).

Your work detailing the SFZ 1.0 opcodes has been pretty beneficial to me as I was learning it, PL, for which I thank you, but also illustrative of my general notion of the general messiness of the whole deal, and precipitating my question as to whether some kind of central source is needed to help keep track of what's going on where, who implements what, whether a real 2.0 spec is necessary and what it would include/exclude, and certainly without the hassle of running around between various sites of half-maintained lists of supported opcodes and so forth.

You could theoretically provide guidance on how to construct an opcode and how to avoid clashes if adding new ones. Here I'm thinking (for example) of how {someop}_loccNN gets constructed for the full range of MIDI CC numbers, if it makes logical sense, and so on.What you can't do is really provide a sensible "minimum spec" as that's down to the underlying engine - maybe it doesn't have a low pass filter, for example.

I don't think a minimum spec can't be established at some point, if major parties put their weight into the effort. Aspiring to standards compliance has been a major force in the browser wars after all, at the behest of web developers who tired of having to utilize more and more hacks and work-arounds to get web pages looking right across browsers and making their GUI-based development tools more useful to them in that regard. Not to say it's not still a huge issue.

I guess here it's a matter of semantics, a distinction between engines that load SFZ files as mere sample sources and such and not necessarily as true SFZ instruments, and those engines that aspire to more compliant implementations. Electro's post reiterates the the problem alluded to in my OP, that many samplers and synths have some kind of support for importing SFZs to varying degrees, but how many of those would we call SFZ instrument players? It's blurry and messy. This is with the understanding that the shear size and necessity of the Internet demanded that something had to be done to change the cavalier, frontier, anything-goes mentalities that ruled its early days, whereas the SFZ format is a niche format in an industry ruled by niches. My hope is simply that engines wanting to call themselves compliant adhere to a widely adopted standard, even as the standard grows and changes to accommodate changes in the technologies of the industry as needed.

So again, the question I put forth is would having some kind of central group to maintain at some level the "standard" help give it more "weight" in the industry? Is there even a desire? Would developers benefit from at least bumping heads one or twice a year in some capacity, even if just on web forums, to get a feel for the direction the format is heading, how its changing, how widely it's being used, etc etc? Would they, engine-developers and instrument-assemblers alike, be interested in coming together and collectively backing an effort to create some kind well-featured, baseline editor that would benefit everyone? As I said in my OP, it just seems right now everyone is kind of doing their own thing with it after ten years or so--making me wonder what the format's true potential is, and if it can be reached through more communal efforts, whether that be through individuals or invested businesses or a combination of these, or if its future is tied inseparably to the increasingly proprietary implementations that it seems now destined for.

I guess more broadly the thing that perplexes me about SFZ is why hasn't it attracted a greater level of communality already? I look at lively projects in the open-source community for example that seem more esoteric or niche than SFZ seems relative to the music industry. Even among the numerous linux distros, despite all their differences, there seems to be a general subscription at some basic level toward advancing the underlying ambitions of open source software the whole. It's lively and philosophical and occasionally influences not only other softwares but the computer industry overall in notable ways. I won't necessarily argue that it's all roses and sunshine in those circles, but the ambition itself is noble to me. I feel like the SFZ "community" such as it is would benefit from similar discourse.

Thus springs the thread, to spark at least a momentary coming together of those who use SFZ in their music, those who create the instruments, those who code the engines that play them, and anyone else that has something invested in the future of SFZ, or is looking into investing in it in someway. A lot of my personal interest in having the discussion stems from its philosophical aspects, the broad strokes of how a more focused SFZ-format might arise, perhaps even having a front-row seat to it should it ever come to pass. Taking honest account of my own skill-level and interest in music-making and pinning it at a very hobbyist, amateur level means I probably won't ever need anything beyond what's already available to me, so long as the plugins I use still work on my host on my OS for the reasonable future. But at the same time the vast potential of the format just makes its evolution of interest to me, and being rather sympathetic to the open-source community I rather hope a great deal of that evolution can occur in the realm of similar communal efforts. Not to begrudge private developers from making their bones through closed source efforts and such--just hoping for an acknowledgement that the format is probably best served by dialogue and exchange between these two interests, and to that end wondering how alone I am in that thinking.

[infectedpimple]

Maybe one major issue of sfz is that it's not a closed format. How do you protect sfz banks ?

Obviously a major concern indeed to certain parties; above the effort just to record, edit and organize the samples itself, the authoring of SFZ files can be quite an undertaking, and sometimes requires novel solutions to work around limitations, which understandably someone looking to make a living, or at least adding to one, might wish to retain as a trade secret.

I wonder if there's a possibility of developing a SFZ-Protected format, by way of some sort of compiler that could take SFZ source files and put them in a monolithic form that could be more easily protected, to whatever extant that such things can be (some would argue not at all, realistically). But then the initial creation of these instruments would share the same (theoretical) creation tools as the open version, just with the intermediary. I guess the question then is how do the various engine-coders handle these? Perhaps as separate solutions to the current players they have the potential for adding a new revenue stream through encryption licensing or through selling the players themselves. On the other hand, added overhead. Still, the theoretical co-existence of the open form and a protected form doesn't seem terribly unrealistic. More a matter of generating interest in it and investing the man hours to to make it effective and worthwhile for all parties interested therein.

[pljones]

I have to say I think having a "protected" format could quickly kill SFZ as something people who share their work freely use - they'd be open to being copied and reused in "protected" format without their knowledge. And, given that most SFZ works is currently for free mappings, this could in turn kill off a lot of interest in SFZ, essentially turning the different engines with their own "protected" support into proprietary samplers once more.

As an example of how difficult open source projects find audio - just look at JACK. It's been around for years on Windows. It has roughly one developer. And I can't think of any Windows DAWs with native JACK support (i.e. supporting both JACK audio and MIDI and not needing JackRouter).

Another example, more close to the subject here, is LinuxSampler. I've tried it many times over the years. It edges slowly forward in stability and functionality but it's generally been unusable for me.

I use these two to highlight the sparse interest in audio in general in the open source community. It just does seem to attract that many developers who aren't just in it for the money. Fortunately there are some exceptions.

[davidv@plogue]

For some developers, the interest in the format is mainly as an insurance policy that their mapping/editing hard work will still be human/machine readable in 10 years or more, something that obviously cannot be said about much of the other 'closed' binary formats, however cute and efficient their graphical editor may be.

I think if an SFZ is wrapped, hidden or otherwise severely obfuscated for protection reasons it should not be called SFZ.

[davidv@plogue]

Another of the format's double-edges is its forgiving nature, skipping what it doesn't understand, assuring in most cases some kind of playback, but not necessarily as was intended by the author, which can lead to some confusion--

This is implementation dependent. ARIA tries to warn about any opcodes or error when it can, while sfz.dll does nothing. However, Dimension Pro starts a text editor in UNICODE with the opcode-related errors in it.

I guess the main question here is whether the time/effort/resources needed to develop such a tool

A graphical "generating" tool (not to be confused with an "editor") would be doable,
I shudder to think about the difficulty to implement an app that would parse an alien-made SFZ and try to make sense of it, building a graphical representation of its content, without losing any important info, formating, comments, etc. (makes me think of the Microsoft- MFC magical comments and characters). I think there is a place for an app that would help build a 'standard' SFZ 1.0 from a sample mapping. But then they exist already, thinking Chicken Systems Translator, Extreme Sample Converter, etc.

[stanlea]

Apart from the sfz specs, there is also a very important fact : the samplers themselves. You can have samplers "sfz compatible", free or cheap samplers. So you're happy to not have to buy Kontakt, Machfive and the likes.

[larm]

For some developers, the interest in the format is mainly as an insurance policy that their mapping/editing hard work will still be human/machine readable in 10 years or more, something that obviously cannot be said about much of the other 'closed' binary formats, however cute and efficient their graphical editor may be.

I think if an SFZ is wrapped, hidden or otherwise severely obfuscated for protection reasons it should not be called SFZ.

I 'rescued' a lot of samples from an old sample cd into 30+ sfz files. Did a dir *.wav piped to a text file, then some smart search and replace (NotePad++) and copy/paste to different text files. Could then import the sfz to the sampler and continue from there and save in native formats.

Instead of having to mess with a mouse and some custom file selector for 100+ .wav files the human readable text editing and the batch processing was a time/life saver. In this case I used the sfz format much like a .csv file.

[infectedpimple]

I have to say I think having a "protected" format could quickly kill SFZ as something people who share their work freely use - they'd be open to being copied and reused in "protected" format without their knowledge. And, given that most SFZ works is currently for free mappings, this could in turn kill off a lot of interest in SFZ, essentially turning the different engines with their own "protected" support into proprietary samplers once more.

A good point, but on the other hand is that not already an issue in the current landscape? I think I remember a couple incidents even here on KVR over the years where a couple of developers of vst romplers were called out for improper use of samples whose true sources were known. I don't necessarily disagree with you that at best having a protected derivative could muddy the waters and even undo what traction SFZ has already gained in the industry, but there's also the possibility that with creative thinking SFZ could derive from itself some alternative to improve things somehow, theoretically anyways.

As an example of how difficult open source projects find audio - just look at JACK. It's been around for years on Windows. It has roughly one developer. And I can't think of any Windows DAWs with native JACK support (i.e. supporting both JACK audio and MIDI and not needing JackRouter).Another example, more close to the subject here, is LinuxSampler. I've tried it many times over the years. It edges slowly forward in stability and functionality but it's generally been unusable for me.I use these two to highlight the sparse interest in audio in general in the open source community. It just does seem to attract that many developers who aren't just in it for the money. Fortunately there are some exceptions.

After I posted last I was thinking on it and came to realize exactly what you observe here. Expanding beyond the narrow focus of the SFZ format, I'm just surprised in general that these projects don't attract more interest in a community that seemingly has all the time in the world to debate ad nauseum digital vs analogue or the effect of bit depths and sample rates on perceived audio quality or which DAW "sounds best" and so forth. But I guess it owes to the niches within niches that is just the reality of the industry too.

For some developers, the interest in the format is mainly as an insurance policy that their mapping/editing hard work will still be human/machine readable in 10 years or more, something that obviously cannot be said about much of the other 'closed' binary formats, however cute and efficient their graphical editor may be.

I think if an SFZ is wrapped, hidden or otherwise severely obfuscated for protection reasons it should not be called SFZ.

I suppose my hope would be, if a protected form of SFZ did ever manifest, that the key to opening and accessing the human readable/portable source at some level would be available to those who invest in and use such a product, but yeah, that's quite a whole can of worms in a big ball of wax, and just further underscores how at odds the concept of the format is with certain interests in the industry, probably ensuring that it'll never be a viable option on the "secure" side. But again, whatever it's called, the possibility of a secure derivative of the format, sharing its tools and processes of creation with its open progenitor but offering a layer of security, fascinates me, and at least opening the discussion in that direction maybe helps involve developers/consumers who would happily use SFZ "if only."

This is implementation dependent. ARIA tries to warn about any opcodes or error when it can, while sfz.dll does nothing. However, Dimension Pro starts a text editor in UNICODE with the opcode-related errors in it.

Having not ventured to test the more advanced engine offerings in a while, particularly with my own broken creations as opposed to known working instruments, it's good to hear that developers are doing what they can to inform--being probably a pretty obvious causality of any decently conceived software, I probably should have expected of such from those of you whose livings are affected by user confusion over which is to blame for something not working right--the engine or in the instrument!

A graphical "generating" tool (not to be confused with an "editor") would be doable,I shudder to think about the difficulty to implement an app that would parse an alien-made SFZ and try to make sense of it, building a graphical representation of its content, without losing any important info, formating, comments, etc. (makes me think of the Microsoft- MFC magical comments and characters). I think there is a place for an app that would help build a 'standard' SFZ 1.0 from a sample mapping. But then they exist already, thinking Chicken Systems Translator, Extreme Sample Converter, etc.

Yes, having a few times needed to whip up little scripts just to parse information out of simple, well-delineated text files for one reason or another, I know it's not fun in the least, and that's the easiest part. So it comes down to really whether the "good enough" solutions are really good enough, or if there really can be something better than what exists already? And if so, what demand there would be for such a tool, and who would have the initiative to realize it. Realistically, I suppose it'd probably be a private venture, someone looking to fill a need in the industry and being well-compensated for that effort. But who knows, maybe some sort of crowd-sourcing initiative could spring up, or some altruistic-type in the vein of a Justin Frankel to lay some kind of groundwork that can built on by the community.

All of this just being mostly academic, I'm sure, going to back to quantifying to some degree what SFZ is currently, where it could be headed, what people might want it to be beyond what it already is, and the implications of any changes that might be occurring now or in the future for the format. But your insights, David and PL in particular so far, have been really illuminating, so thank you.