That is rather odd I have downloaded the Self playing orchestra Sfz from ‘virtual playing’ and the module says it can’t open them due to the fact they are wav files but they are not wav but Sfz!
Just re-read the instructions -you have to have the wav files as well in the same folder!
I think I’ve found a tiny bug. The notes are always a step behind. For example, if I hook a keyboard to the V/Oct and gate, then press a C, it plays a C. Then I press an A, and it plays a C again. Pressing any other note then plays the A. This continues, always playing the prior note instead of the one at the input. The workaround is to delay the gate by a tiny amount, and then it plays the expected notes.
Try making the input polyphonic I think that might sort it
In general you can edit the sfz script if you like and put the wav files in e.g. a sub folder.
It does the same in polyphonic mode. I tested it with Impromptu’s Chord-Key. It’s as if the gate starts the note(s) sounding before the V/Oct input is read. Delaying the gate by the tiniest amount totally fixes the problem.
I’m pretty sure this is not true. But it is true that SFZ Player will sample the V/Oct input the instant the gate goes high. I strongly suspect this is a bug in the Impromptu module. It for sure does not happen if you use the core MIDI-CV module. @marc_boule ?
It’s not quite that simple. The samples need to be where the SFZ file expects them to be! Sometimes that is the same file, but often it is a folder below called “samples”. If the sfz and samples are downloaded at the same time, there is no issue (as they will have been zipped correctly). If they are downloaded separately there should be a readme file telling where to put things.
If you look in the VCV log we put the error message there, but with the full path to where we are looking, so you can see what happened. Also, as @Soxsa said, you can look in the SFZ file and see. If it says sample=foo.wav then they should be in the same folder. If it says sample=./samples/foo.wav, then it expects them to be in a sub-folder called samples.
Ah, I will have to try that some more! As you point out, many of the free orchestras pull their samples from some of the same free sources, so there is overlap but not 100%. And of course the SFZ files themselves tend to be quite different from each other.
After you said so, I went to test again, and it just worked properly.
[edit] Ah, I discovered the trouble. Having Oct between the sequencer and the SFZ Player does it.
No, I’m sure it really happened. I wonder if it’s possible that VCVs one sample delay somehow got applied differently to the cv and gate? Definitely something I will look for. I’d rather put in a delay as you suggest rather than have ghosts in my machine,
I don’t think there is a bug with my ChordKey, as the CV and GATE outputs are always written-to in lock-step (i.e. in the same sample), and they are process at the sample rate.
Well, I better look and see if there are any bad smells in samp.h!
Hello again, so what does this screenshot of the Sfz file on Notebook show? The wavs have to be in a samples folder?
Ah yes!! I remember now it when it happened for me I had put Oct in. Now you’ve jogged my memory. I should have hunted it down or reported it to the boss, my bad.
Instead, I just removed Oct 
So I’m guessing having the extra delay in the line between gate and voct might be cause - what do I know?
EDIT: Just tested the theory with putting MUTES in between midi and v/oct input - and yes the same effect.
oh, that makes sense! and it’s not a bug. oct delays the CV by one sample (like all VCV modules), so the cv arrives… one sample after the gate! Interesting… I might just need to put in a delay…
“Not a bug but a feature” covers it 
EDIT and you can use Oct by putting the gate through MUTES or similar.
It’s worse than that. they need to be in a samples folder coming off a lib folder that is a sibling…
If your sfz is in mystuff\programs\celesta.sfz, then your samples need to be in: mystuff\libs\stameradam\samples` at least that’s how it looks to me.
Didn’t this instrument come with any installation readme? Also if you get it wrong, look in the VCV log file to see where SFZ Sampler is actually looking.
Well, I would go so far as to say that SFZ Player is unusually susceptible to this kind of thing. It’s not unique in that way, but it is uncommon and a bit worrying. Of course any sequencer would also be sensitive to this, too.
I don’t think it’s a worry - it’s logical. As long as people know, they can easily stick some kind of delay on the Gate CV and put the V/Oct through whatever pre-processing they want. I think that understanding the CV-delay model in Rack is necessary for advanced patching isn’t it?
That said, I reckon using Oct might be a pretty common thing, so a built-in 1 sample delay might be a good thing.
I would make the sample delay a context menu option, but that is just me 
I should add, that I have a few modules with multiple inputs where sample delays can be an issue. I (1. make it a menu option so people know it is on/off (2. make it a 5 sample delay so there can be a few modules in between
