SFZ: MW XF between layers?

[Paul Battersby]

(09-11-2017, 12:51 PM)oGatoulas Wrote: My goal is to build an ensemble string patch with the dynamics controlled by the modwheel.

I actually solved this very problem a while ago when I created dynamic cross faded brass patches for my sample library.

You are right about using xfin_locc1, xfin_hicc1 etc.

I didn't use amplitude_oncc1 (I can't even find a reference for that opcode in sfz 1.0 nor sfz 2.0) I used gain_cc1=24, and then I lowered the volume of each sample by 24db (volume=-24) so that the lowest mod wheel setting uses -24db and the highest mod wheel setting gives me the max volume of the samples.

This works with Sforzando because it permits the mod wheel to control more than one parameter at a time. Other sfz players might not. I know of one that doesn't.

[Samulis]

^ I'll have to dig through Simon Cann's book, but I think that's the best bet for implementation. If you want to cheat a bit, you can use a <global> and stick the volume boost in there, UNLESS you already have volume defined in each region or group (<global> won't override local settings).

amplitude_onccX is listed in the LinxuSampler SFZ Reference, but no description or extra info is given, so I assume it is some sort of SFZ 2.0 thing or LinuxSampler-specific (see Table 1.7)-
https://docs.google.com/document/d/1UxPa...E6xino/pub

The 'unfortunate truth' Simon Cann explains is that there is actually no SFZ 2.0- there's an ARIA SFZ 2.0 spec, there's a Linux Sampler 2.0 spec, etc. but there are actually "2.0" features that aren't universally accepted. Part of this is the fact that Cakewalk maintains the format now, and basically uses it commercially for all their synthy/samplery stuff (they basically threw a synth oscillator system into the spec so that they could do that). However, ARIA = Plogue + Garritan, which =/= Cakewalk... and LinuxSampler is its own thing as well. This means that something that is "canon" according to Cakewalk may not be implemented in either, and something that is "ARIA Specific" may be found in one but not all other engines.

To complicate matters, each engine has free reign as to how to implement such features- I would be equally unsurprised if Sforzando doesn't allow these two to be combined as a bug or as a conspiracy to make people get an ARIA-based library.

A dumb-as-nails way of implementing this would be to simply have your lower velocity layers quieter- preferably at "normal"/"unaltered" loudness- i.e. to use zero volume ramping. Amplification should be null for all and this will give a realistic crossfade across the two/three layers IF the recordings/performances were done consistently. This may cause issues with the 'plateaus of unresponsiveness' between your crossfades (if you decide to have large 20+-step areas of exclusively one layer between crossfades), both at the top, middle, and bottom.

A particularly clever cookie could create a <curve> that is flat except at the very low end, where it quickly falls off, and apply this to a LP filter-

Code:

fil_type=lpf_1p
fil_random=100 //vary cutoff by 100 cents to give some free bonus 'variation'
cutoff=1600 //this is the *lowest* value you want the cutoff to go
cutoff_oncc1=4800 //will raise it 4 octaves at maximum (25,600 Hz, if I'm not mistaken, outside human hearing)
cutoff_smoothcc1=50 //smooths out the filter so it won't be too sudden
cutoff_curvecc1=# //you'd have to figure this part out
resonance=0
resonance_oncc1=3 //adds a tiny bit of resonance when it gets up to the upper register- should make a bit more "air" at louder velocities, increasing the effect... but could also sound horrible- I don't know how the resonance is implemented
resonance_smoothcc1=100 //a bit more smoothing to this

alternately to the resonance stuff above, you could try adding the loud end with the second filter (if it's implemented) OR try the new-fangled EQ (table 1.12 in the LinuxSampler SFZ reference linked above). EQ's only have a 4-octave bandwidth (at least in LinuxSampler, apparently), so they wouldn't be able to be used as a 'cheat' for gaining, at least not cleanly.

I also wonder if you could use eg#_volume_onccX as a control, but you'd still need to reduce volumes...

Code:

eg8_volume_oncc1=12

LinuxSampler SFZ Reference Wrote:Patch envelope generator N to the amplifier. The EGs normalized output will be multiplied by the opcode value and added to the destination in addition to being modulated by MIDI continuous controller X.

[Chris Spyratos]

I think I'm gonna wait until they fix this. Until then I will use different CCs and bind the modulation to them outside the sfz file.

[Samulis]

I'm not so sure they will 'fix' this anytime soon, especially if you don't let Plogue know about it. Sforzando doesn't seem to be in very active development anymore (last update was in March) and the usual "someone else will find this and report it" mentality definitely doesn't apply in my mind. Honestly this forum may very well be the second or third largest active collection of independent SFZ developers on the internet...

Honestly if you are just planning on using this project by yourself, two CC's is fine if you can fit it in your workflow, but if you plan on sharing it with the world at any point, I'd definitely recommend considering Paul's approach- it ultimately does the same thing and provides the expected result.

[Chris Spyratos]

Oh, I have already opened a thread on plogue forums for this! According to them it is a known bug.

Paul's solution seems fine but I am not sure how to play with the volumes on each region yet. And your tips sound great but I am not a developer and I have only recently begun tampering with sfz coding, only to better utilize some samples I have. I will go with the easiest solution for now but I will definitely keep checking for any progress and let you know. I appreciate all the help I got!

[Paul Battersby]

(09-12-2017, 12:21 PM)oGatoulas Wrote: I am not sure how to play with the volumes on each region yet.

You can just place the volume=-24 command inside a <group> tag, then it will apply to every region in that group. If you need to fine tune the volume of a sample, you can place a volume=-19 (or whatever number you need) command after the <region> tag and it will override the volume that was set for the group, but just for a region.

[Samulis]

If you want to apply a volume change to every region very quickly, think of a text string that is part of each region (e.g. "<region>", "sample"), then use the text editor replace function (I use notepad++ for this)-

In Notepad++, there's an option to allow advanced replace characters/functions such as '/n'. These will do things like add new lines. For example, if you have this-

Code:

<region>
sample=blah.wav

and you replace this-
.wav
with this-
.wav /n volume=24

you will get-

Code:

<region>
sample=blah.wav
volume=24

Super, super useful! This lets you insert universal opcodes across all your samples. Depending on your naming structure or mapping, you can even selectively apply to certain velocity layers or the like (e.g. if I wanted to add an ampeg_attack to my lowest velocity layer, I might replace 'hivel=40' with 'hivel=40 /n ampeg_attack=60', which just inserts that line in below the hivel line. Super sneaky!)

[Chris Spyratos]

Thank you Paul, it is not easy to test it by ear. I thought that volume opcodes in the regions are added to the global volume opcode.

Samulis I do use Notepad+ for many applications and that tip was very, beyond sfz, helpful!

(08-03-2016, 02:46 PM)Mattias Westlund Wrote: I've been creating a lot of XF patches in TX16Wx for moving between dynamic layers, and I wanted to give it a shot with SFZ as well.

Just noticed it! How can we get MW XF on TX16Wx???

[Paul Battersby]

(09-12-2017, 11:22 PM)oGatoulas Wrote: I thought that volume opcodes in the regions are added to the global volume opcode.

Definitely not. Anything after a <region> opcode, over rides the same command in a <group> opcode - at least with Sforzando. I took a quick look through the spec but couldn't find any requirement that a <region> opcode should necessarily override a <group> opcode but it does seem to be the common implementation otherwise I would have received support questions about that from users of other sample players already.