Improving Salamander Grand

[PetPet33]

Good points, JeffL, and thanks again for moving the Salamander a good notch forward.

I still remember the first moment I heard a pedal squeak on a mass-produced recording. 'Twas surprisingly mind-blowing. Today's gen has lifeless hurdles like P*anoteq to overcome... Understanding the infinitude of overtones seems more important than the physics of modeling hammer mechanisms... in the long run, so sound has to come first... I got a zither here that's like a proto MS2000

Btw, mr. Learman, I understand the eq mods you hard wired into your triumphant Rhodes vsti, yet from a band leader perspective, the mods push the instrument more into solo / lead category. Thanks again and kudos for your work.

[JeffLearman]

You're welcome!

from a band leader perspective, the mods push the instrument more into solo / lead category.

That's funny, because I'm a rhythm player, much much more than a lead player. I just wanted my soundfont (and later sfz) to sound the way I set up my Rhodes for playing (live or studio.)

Actually, I used my Rhodes in two modes, in both modes plugged into a mixer. The first mode was for the light sparkly tone, with treble emphasized (frankly, matching my first use of the Rhodes which was through my roommate's JC120) and the gain cranked up. I had to play very tenderly to avoid peaking out, especially in the top octaves.

The second mode was with the mixer gain backed way off, hitting the keys robustly, for a nice beefy squawk. IIRC, I didn't change the EQ. (That was in the 80's, so ... some of those brain cells may be missing now. But I'm pretty sure it was a one-knob adjustment to switch modes.)

I tried to capture both ends of this scale. I didn't quite succeed with the highest velocities at the bottom end, though I suspect the real problem there was those samples should have been a lot, lot louder, enough so that the bass didn't seem to drop out.

Anyway, lots of tradeoffs, but mainly I wanted "my Rhodes" in a box, rather than yet another copy of the classic pure Rhodes.

[JeffLearman]

I can't think of any case where variable latency is appropriate.

Well, I did think of one (or, one class of cases.)

If you want a "practice carillon" where the latency matches the real thing, then the latency would depend on the size of the bell. Likewise, if you're modeling a big pipe organ, the latency varies with the size of the pipe.

But in these cases the latency is systematic and realistic. I still can't think of a good use for arbitrary latency differences (especially, for different layers of the same note.) Well, of course you can always have fun doing something "wrong" and using it for artistic purposes. Note that I said "you" and not "I" because I'm just not that artistic.

[JeffLearman]

There's another issue where different standards for latency apply. For scored music, when the "latency" includes mechanical noise that leads up to the start of the note, a constant latency for all samples is ideal. For live playing, for most of us, minimum latency is best, and constant latency if low enough is manageable.

[enroe]

There's another issue where different standards for latency apply. For scored music, when the "latency" includes mechanical noise that leads up to the start of the note, a constant latency for all samples is ideal. For live playing, for most of us, minimum latency is best, and constant latency if low enough is manageable.

In general, the latency for a usable multisample should always be zero. Because only then
can you actually play grooves with it.

For a large multisample, determining the offsets is always a lot of work. But if someone
has time, they could do one thing: With a sample editor (Audacity, Wavosaur or something
else...) you can see how many individual samples are superfluous at the beginning of
each WAV file, and then set them as "offset=" to the respective samples in the SFZ file.
That would be a big help, and with a list of offsets anyone could easily add the offsets
into their Salamander-SFZ.

[JeffLearman]

I always build my samplesets with zero latency, because I build them to play them as instruments from my keyboard, for live use or for recording.

My nerdware that I use to create samplesets uses a pretty simple and IMHO effective algorithm to find the beginning of the note. So, it's not hard, at least, not for instruments with strong attacks like pianos. (Admittedly, I normalize samples by layer, which makes it easy, but it's not at all hard to adjust the algorithm for samples that aren't normalized. Just takes an extra pass to find the peak.) That's what I used to get the offsets for Salamander.

But for MIDI scores, as I pointed out above, it's nice to have the "pre-note" noise of certain instruments. Instruments like pianos make noise before the note begins. For people producing recordings from MIDI scores (rather than playing the instruments in MIDI record mode), this pre-note noise might be desirable. So, while I never include that pre-note noise in my own samplesets, I don't criticize those who do.

So, I wouldn't say that "in general, the latency for a usable multisample should always be zero." That's only true for certain use cases. It's true for the case of playable instruments, though, and that's what I use exclusively.

In any case, what you suggested about using `offset` has already been done to the Salamander sampleset in the sfzinstruments github, and you get your choice of choosing the zero-latency or (original) variable latency SFZ files.

Frankly, a variable latency sampleset is generally a bad idea with only oddball use cases, but the maintainers preferred to retain the original and provide the zero-latency version in addition (which is fine with me.) IMHO, what would be better is a fixed latency version that includes the pre-note noise (which again, would be fairly easy to automate, so maybe I'll do that too, someday when I'm bored.)