infectedpimple wrote:This sort of evokes a question that was floating around in my head while I was rambling, but couldn't quite articulate in previous go-arounds: is SFZ just a format then, or is it too a programming language?
No, its solely a format. Its a description of data, not a means of manipulating the data.
I can program something in C++, for instance, and you'd say its a C++ program, but not necessarily a Windows program, or a Linux one, or Mac, etc, which would (I think?) more or less determine its "format" as a particular executable for a particular platform.
Does the fact that its compilation to a binary format that obfuscates its origin change the fact of its origin being C++ source files, with standard includes and all that? Does it make C++ less useful a language?
Im not entirely sure what you're trying to say here, to be honest. Source code has to be compiled into executable code suitable for its target system for it to be executable on that target system. Im not sure what the 'origin' of that, or 'usefulness' of that comes into the equation. C++ code can be developed on one system and compiled for a completely different target system, or several target systems; those possibilities are not defined by the development system, though, they're defined by the C++ compiler. It might be impossible to test on the development system, but that's not the point.
But this has nothing
to do with the the sfz format whatsoever.
So what if, theoretically, you could write up your instruments in the SFZ language and then compile it as another format (eg the hypothetical SFZ-Protected or Super SFZ or whatever) with a theoretical SFZ compiler?
To me, you're sort of conflating the notion of a language compiler with a data translator here. You wouldnt 'compile' sfz files because they dont describe program behaviour, just data organisation. You might transliterate them into a protected format, but that's not the same thing as compiling a programming language, and theoretically you could bundle them up with some working code into something executable, but it would be the code you bundled it with that would be responsible for the program behaviour, including interpreting the sfz data.
Try thinking about it the way you'd think about any other purely descriptive data format : would you talk about 'compiling' a wordprocessor document into an executable program, or would you expect to open it in a word-processor.
Can SFZ (or maybe an evolution or of it) form the core of such a source language, somewhat more separate from its utility as a readable/editable, simple means of playing back samples?
Some theoretical evolution of it could, I guess. But it currently doesnt.
Perhaps that conflating two basic questions--there's the question of how the SFZ format might be made easier to use "as-is," then there's the question of how SFZ might be adapted into something more advanced, with perhaps a different purpose than its original...
I'd question why you'd want to do the latter (cf 'compilation') without completely negating the point of sfz
it just comes back to asking, why aren't there more sophisticated SFZ offerings?
I'd hazard the fact that there are various reasons. But the fact that sfz is an open standard allowing use by multiple tools means that multiple tools use it; the result of that is going to be that those different tools use it in different ways (ie different synthesis engines), and hence to get a specific degree of 'sophisticatation', a set would need to built with a particular tool in mind. And that makes the engine more important than the data format. When the engine becomes the primary focus, then why prioritize sfz in the first place if there's a 'better' choice of engine.
And bear in mind that many of the tools using sfz sample sets dont actually use sfz as their preset format; the tool-specific stuff is contained within their own preset information. sfz describes the sample set data, but not the audio engine data.
sfz has two types of 'utilisation' benefits, as I see it. For developers, it gives them a defined target for sample sets which they can utilise in their synth engines, which saves them having to design such a thing from scratch. For users who dont just use presets
it means they can reuse a certain amount of sample design work out there even if its not targetted for their specific tools (which is a selling-point for the tool developer).