Sfz format questions

[davidv@plogue]

So if I play a ppp note or and fff note, I'll get the same trigger=release region because there's no velocity information and hence I'll get exactly the same volume for the release, regardless of my initial note velocity, i.e. the same volume release whether I'm playing heavily or softly.

trigger=release is also subjected to lovel/hivel and takes its velocity value, not of the MIDI note off velocity, but of the killed note's velocity.

[pljones]

trigger=release is also subjected to lovel/hivel and takes its velocity value, not of the MIDI note off velocity, but of the killed note's velocity.

Ah, that makes more sense -- I'm not sure whether sfz.dll did this (I don't remember and it's not something I've ever needed to actually use -- I'm going on what I wrote on my web page at the time).

[davidv@plogue]

I'm not sure whether sfz.dll did this (I don't remember and it's not something I've ever needed to actually use -- I'm going on what I wrote on my web page at the time).

This was implemented this way in ARIA very early on, and at that time I was cross checking everything in sfz.dll/Dimension for behavior.

[pljones]

Thanks -- I'll see if I can adjust how I've written that bit on my page for SFZ v1, then.

[pljones]

OK, that's updated (five years since the last time I updated it..!). Thanks David.

IIUIC, basically "trigger=release" layers actually start processing when the Note On event happens but only start playing when the Release trigger happens (i.e. Note Off) and, at that point, have all the information needed to calculate the amplitude.

[davidv@plogue]

OK, that's updated (five years since the last time I updated it..!). Thanks David.

IIUIC, basically "trigger=release" layers actually start processing when the Note On event happens but only start playing when the Release trigger happens (i.e. Note Off) and, at that point, have all the information needed to calculate the amplitude.

Thats one way to see it for the user.
It would however be not efficient to implement it this way (especially since polyphony would take a toll if you reserved release triggers ahead of time.). though opcodes like delay and start_beats etc do work this way

In my implementation the trigger=release layer does not start processing until a note on ends (can be sustain switch ended too!) with the same note number, its just that the time delta between the original note on and note off gets fed to the rt_decay calculation and processed _once_ upon release trigger layer start.

I hope this makes sense?

[pljones]

Yep - I was speaking in terms of user experience: trigger=release is delaying the when the layer plays until release but the layer was effectively selected by the Note On, which supplies input to the amplitude calculation - it's just that there's also the time delta between Note On and release time (i.e. Note Off or sustain released) available as input to rt_decay, if used. (So trigger=release makes no sense on a layer triggered by a CC.)

[DSmolken]

(Personally, I find rt_decay beyond "obscure" and fairly deep into the "avoid" side of things...)

for piano release, rt_decay is crucial, even so that it wasnt enough for us and we added other opcodes to add realism. (basically extra rt_decay stages)

Aha! I was wondering about this for plucked string note off samples - the noise of strings being muted. Great!

[oxxyyd]

The link http://www.cakewalk.com/DevXchange/article.aspx?aid=108 seems to be broken. Anybody knows where the sfz spec can be found?

[pljones]

Anybody knows where the sfz spec can be found?

There's no such thing as a spec. The doc you linked was René's write up (it's still on the old rgc:audio site indexed by The Way Back Machine) from 2004. Mine's over on http://www.drealm.info/sfz/plj-sfz.xhtml still. Neither covers SFZ 2 (used in Cakewalk synths and ARIA engine).

[oxxyyd]

Sorry for being a bit sloppy. With spec I mean specification and with specification I mean something according to the definition in http://en.wikipedia.org/wiki/Specificat ... ite_note-1

"Specification (often abbreviated as spec) may refer to an explicit set of requirements to be satisfied by a material, design, product, or service."

[pljones]

Quite. No such thing exists. There's nothing explicity required in sfz format, really. It's an open format. Whether a particular SFZ engine supports a particular op code cannot be prescribed -- it's entirely down to whoever implements the engine.

The most explicit I could ever get René to be was:
"// at the start of a line is a comment" (or it might have been single slash)
"break on whitespace except after during the sample= opcode, in which case break on end of line"

And that's it.

Effectively, an engine that doesn't understand some input it gets after applying those two rules should just quietly throw it away. Anything it does understand, it can do with as it will.

Practically, the link I gave is more complete than the Cakewalk one ever was. It's sad that it's disappeared, though.

This is where it originally lived:
http://web.archive.org/web/200703122022 ... format.htm

[oxxyyd]

No, an explicit set of requirements is not the same as a set of explicit requirements.

[Shabdahbriah]

The {formerly} Reaktor {only} map builder, now includes SFZ.

http://relivethefuture.com/choronzon/20 ... builder-2/