VCSL

[Samulis]

(04-22-2018, 07:18 PM)peastman Wrote: I just posted a new pull request with the latest changes.  Releases now work correctly.  I also renamed folders for sustains and releases to be more consistent, but I wasn't sure what to do with "Grand Piano, Steinway B" and "Upright Piano, Knight".

I added a bunch of command line options to the script for customizing the output.  I used those to reduce the attack time on the piano, and to add 5 dB of amplification to the recorder.  And I changed the default curve for mapping velocities to layers (also customizable through a command line argument).

Next I'll look into crossfading.

Steinway B has separate sustain pedal samples, separate from the typical normal/non-sustain pedal samples in most free sampled pianos. These should be mapped in a group given the following opcodes-
locc64=65
hicc64=127

The 'nosus' group(s) gets this opcode pair-
locc64=0
hicc64=64

The release samples apply to both and don't need cc opcodes to my knowledge, but if you want, you can set a locc64 to 0 and hicc64 to 127.

Knight doesn't have separate sustain pedal samples, but it does have several 'pedal' sounds of the pedal being depressed. The 'Dyn2' and 'Dyn3' are the two dynamic layers of the non-sustain pedal samples, to be mapped as usual. These pedal sounds could even be put on the other pianos if they sound good. They probably need to be attenuated or increased in volume by hand to blend well, as they may be too loud or too soft.

Map the 'on' pedal samples to the complete range of the instrument, mapped as thus-
on_locc64=65
on_hicc64=127
pitch_keytrack=0 //removes key tracking so it won't change pitch across the keyboard
amp_veltrack=-0 //removes velocity tracking, if there even is any, so it is a consistent volume level

Similarly map the 'off' samples, but with these lines instead-
on_locc64=0
on_hicc64=64
pitch_keytrack=0 //removes key tracking so it won't change pitch across the keyboard
amp_veltrack=-0 //removes velocity tracking, if there even is any, so it is a consistent volume level

I think that will work, but if you notice it acts weird or triggers the samples constantly when moving modwheel (I've never tried this myself), then set the 'on' samples' on_hicc64 to 65 and the 'off' on_locc64 to 64 and see if that works as expected.

I understand you want to make this as 'click a button and go' from your end as possible, but mapping really can't be done that simply. There are too many exceptions like this that will get in your way- sort of like trying to make a date converter that will convert any date in history, where there are all these weird exceptions and quirks from millennia of chronological development getting in your way. My best advice is to focus on getting a coherent mapping system in order, such as setting each folder to a new group or something similar, where features like this can be hand-finished. Otherwise, we will need to go with a csv file system or something to keep track of all the flags needed to determine how to map something.

As a side-note, I'd like to keep the house-keeping global across both branches for future and backwards compatibility (e.g. if I update the piano samples in the main branch, I want to be able to click a button to get that update working in the sfz branch). As a result, I would appreciate it if you would either do any housekeeping (folder renaming, file renaming, etc.) on the main branch, and push it back to the main, or submit any requests here or on github and I will handle them myself. I appreciate you want to be able to rename, map, and go in one fell swoop, but if I can't keep these things standardized and held together firmly, the project will bloat and distort all over and patching it will become a nightmare.