d.healey pretty much hit the nail on the head with HISE vs. SFZ. I would note that HISE is still a work-in-progress, but I know d.healey and others are actively developing products with it at this point, so it's definitely worth checking out as an alternative, especially for combining different instrument styles and getting some very unique sounds out of it. It has a different design paradigm than SFZ, so it's been taking me a particularly long time to warm up to it.
iurie wrote:
What do you mean by monolithic? A monolithic file format? Or you mean in general.
Yes, to bundle all of the sample data, instructions, etc. into a single file, or at the very least, bundle all the sample data together. Some users have difficulty understanding the structure of sample libraries, and they are very easy to break if they, for example, move the patches to a different location without moving the samples. So, for smaller libraries or just to keep things together, a monolithic format would be preferred. Rene (the guy who came up with SFZ) actually mentioned monolithic format being a potential future possibility for SFZ, but to my knowledge it was not implemented.
iurie wrote:
Nesting you mean to be able to specify properties of an "opcode" in a nested form?
No, I am referring to the ability to nest regions within regions, which is a result of SFZ not having closing statements for headers (such as '</region>'). For example, a SFZ file may have this structure:
Code: Select all
-> Control (only can contain some special opcodes)
-> Group (e.g. 'Vibrato Sustain')
-> Region
-> Region
-> Region
-> ...
-> Group (e.g. 'Non-Vibrato Sustain')
-> Region
-> Region
-> Region
-> ...
etc.
But you can't have this in a SFZ:
Code: Select all
-> Control (only can contain some special opcodes)
-> Group (e.g. 'Vibrato Sustain')
-> Group (e.g. 'Round Robin 1')
-> Region
-> Region
-> Region
-> ...
-> Group (e.g. 'Round Robin 2')
-> Region
-> Region
-> Region
-> ...
-> Group (e.g. 'Non-Vibrato Sustain')
etc.
i.e. you cannot 'nest' a group within a group, because as soon as you declare a new <group>, the parser automatically assumes you just closed the preceding group with a </group>. (if you actually were to write '</group>' in a SFZ, you'd get a syntax error when you went to load the file)
ARIA engine gave a small "fix" to this by adding <Global> header, which can be used to apply settings to multiple groups. This way you can organize things like round robins a bit easier with less wasted extra code, but it's still a weakness of SFZ. It makes SFZ faster to write and a little smaller in disk space, though, which is not a bad trade-off.
Note that SFZ headers inherit from their parent headers, that's why I visually nested <region>'s within <group>'s above. To reduce extra code, you can put an opcode that is standard to all regions in a group header before the regions begin. However, what if you have many groups which all should have the same opcode or two? That's where <global> comes in- to provide opcodes to groups within.
(extra side-note, note that even though they inherit, they only inherit if the opcode doesn't appear, so a <region> with a 'volume=' opcode will not inherit the 'volume=' from their <group>)
iurie wrote:
Also, you mentioned about scripting, GUI etc. My question is how this can be delivered on one file? As an zipped bundle format like OpenDocument Format? Or just in one file? Samples are still separated folder? Do yo have any thought on this?
Kontakt uses a separate 'resources' folder to contain all non-sound assets for a project, or bundles it into a .nkr. Either is perfectly valid. The issue here is rather that SFZ doesn't even have documentation for GUI creation because although ARIA and Sforzando support GUIs, they're closed source. Similarly, adding scripting functionality to SFZ would be a lot of work, and would also require either an open source or very well documented format. Kontakt has its own scripting language, HISE uses a few standard high-level languages but alters them to the task.
Consider a comparison: SFZ is like a .txt file while Kontakt and HISE are like .pdf. You can open a .pdf on any computer in the world running Adobe Acrobat and it will look visually near-identical, with characters in the exact same place, colored and hinted the same way. But, a .txt file will look different in every text editor as they each have different fonts, sizes, word wrap rules, kerning, line spacing, etc. Kontakt, HISE, PLAYER, Maize, etc. all promise a universal end result, while SFZ cannot- I would argue it's the same reason why people don't write giant pieces of software in BASIC.
iurie wrote:
I have read people use 90GB of RAM, and expect all the instruments to be loaded in this memory... do really people go to these lengths?
Well, there are people who do things like that (most I typically hear of is about 64 GB, but some very wealthy folks probably have upwards of 128 GB). However, almost everyone uses DFD streaming to greatly reduce the amount of RAM necessary to use their instruments, and with the random read speeds of SSD's compared to traditional hard drives being so powerful, it's almost silly to load samples completely into RAM when, at that price, you could just keep your samples on a bank of SSD's.
Besides, within the next decade, we're probably going to start seeing a shift away from massive sample libraries to neural-network powered modelling systems, which will be much more CPU-bound. Massive sample libraries are just too expensive to produce- hiring dozens of musicians for hundreds if not thousands of hours is financially inherently unstable in a market of heavy competition and continually decreasing product differentiation. Even as saturated and bursting as the market of composers is, there is a limit and eventually it will be reached; there will be a day when a dev goes whole-hog on a massive library, puts it out, and gets little interest. Consider all the warning signs: extreme discounts, large bundles, transition to subscription models to capture more markets, lack of product differentiation, development of increasingly esoteric and specific products, sometimes to lackluster results.