Scoring Central

Wow you sfz guys blow my mind. Looking forward to checking it out when you get done.

Quote:Distinguishing between conventions is really easiest done by ear.

Sure, but anything that involves listening to samples and manually tweaking each instrument is something I'm not planning to do.   All I'm doing is writing a script to automatically generate sfz files.  Once we're happy with its behavior, I'll point it at the top level folder, let it generate many dozens of sfz files, and then add them to the repository.  The results won't be perfect and you'll certainly want to customize them.  My goal is to automate everything that can reasonably be automated and produce files that are a good starting point for further tweaking.

Alternatively if you want to use the script to generate the files yourself one instrument at a time, I can add options to it for whatever customizations you think would be most useful.  Attack, release, volume offset, and transposition are obvious ones.  What else would you like?

(04-22-2018, 04:53 AM)peastman Wrote: [ -> ]

Quote:Distinguishing between conventions is really easiest done by ear.

Sure, but anything that involves listening to samples and manually tweaking each instrument is something I'm not planning to do.   All I'm doing is writing a script to automatically generate sfz files.  Once we're happy with its behavior, I'll point it at the top level folder, let it generate many dozens of sfz files, and then add them to the repository.  The results won't be perfect and you'll certainly want to customize them.  My goal is to automate everything that can reasonably be automated and produce files that are a good starting point for further tweaking.

Alternatively if you want to use the script to generate the files yourself one instrument at a time, I can add options to it for whatever customizations you think would be most useful.  Attack, release, volume offset, and transposition are obvious ones.  What else would you like?

In that case (a bulk generation), I'd say assume C3=60. I will probably standardize to that (and the rest of the standard outlined on the readme) with the instruments that aren't yet compliant, although that may take a while and I can't promise I'll catch everything. Mostly at this point, I'm just focusing on getting the samples selected/recorded and out there for the folks that are interested in using this sample set. I figure the housekeeping can mostly come later, although I've already done some minor housekeeping so far to keep things organized.

Having something which auto adds that dynamic filter I suggested for instruments with no velocities would be good for a bulk automapper. Other than that, the attack fade for sustaining patches... that would honestly need to be done manually, as there's no 'cheap' way to determine sustains from impulses that-I-know-of.

My only other thought is possibly making a .csv sheet that has metadata on all of the samples and circumvent the annoyance of trying to dig through the samples and their data. It could be generated and manually adjusted either on a per-instrument basis or for the entire thing (although the later would be hard to update in the future. Some of the data could be flags (such as IsSustain, IsMono, IsC3, etc.) which could trigger changes, others could be metadata not included in the file such as Perceived Loudness, UACC number, location, microphones, or tags/keywords. I think it would be fairly easy for the script to read data from that.

The only problem is that would take an enormous amount of time to generate by hand, even with the help of some tools and my excel scripting skills, as a lot of the data would need to be manually entered. I did some of that stuff for VSCO 2 CE for the freesound.org upload and it was a lot of work.

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.

(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.

That sounds like it's best done by hand.  You can still use the script to generate the regions for all the samples, but then combine them and add the pedal control by hand.

I added crossfading support and checked it in.  I tried it on the Yamaha piano, but there was just enough phasing audible that I prefer it without.  It doesn't sound terrible, just like a piano where the strings for each key aren't quite in tune with each other.  If you want to try it, just add the --crossfade option when you run it.

Keyswitches are now in.  I've tried to make them completely automated.  You run a script that does the following.

• Scan the whole repository looking for filenames of the form "Instrument - Articulation.sfz".
  
• Exclude any that already contain keyswitches.
  
• Identify the range of notes for each instrument and try to intelligently decide where to put the keyswitches on the keyboard.
  
• Generate a new file called "Instrument - Keyswitch.sfz", merging all the individual files together.
  

Whenever you add a new instrument, or modify an instrument by hand, or anything else that affects the keyswitches, you just run the script.  It automatically regenerates everything, picking up the latest changes.

(04-22-2018, 11:41 PM)peastman Wrote: [ -> ]Keyswitches are now in.  I've tried to make them completely automated.  You run a script that does the following.

• Scan the whole repository looking for filenames of the form "Instrument - Articulation.sfz".
  
• Exclude any that already contain keyswitches.
  
• Identify the range of notes for each instrument and try to intelligently decide where to put the keyswitches on the keyboard.
  
• Generate a new file called "Instrument - Keyswitch.sfz", merging all the individual files together.
  

Whenever you add a new instrument, or modify an instrument by hand, or anything else that affects the keyswitches, you just run the script.  It automatically regenerates everything, picking up the latest changes.

Sounds awesome, great work!

I'm happy to hand-edit things (maybe some other forum dwellers might be able to spare some time over the next few months as the project grows too?), although my first responsibility with this project is to keep the sample content flowing. As it is freeware and I'm not getting anything out of it, I do have a limited amount of time and energy I can devote towards it versus my commercial projects.

I also completely understand any time constraints you may have and massively appreciate your work on the scripts. I think these are something that can continue to blossom into a very powerful tool for developers and hobbyists alike! If you ever want to take the scripts private or want to do a fundraiser or something, let me know. I didn't intend to inspire/arm-twist someone into making an entire sfz automapping suite in the process of this. 

No problem!  You're creating a fantastic resource for the community, and I'm happy to be able to contribute to it.  Besides, this made a fun weekend project.  

I'll try to get most of the remaining pitched instruments generated within the next few days and we can merge those.  Then I'll start work on the non-pitched ones, which look like they may require more manual work.

I'm finding the releases work much better on some instruments than others.  On the French harpsichord, for example, they sound fine.  They're just very brief clicks that add a bit of realism to the end of the note.  On others, like the Italian harpsichord and Kawai grand piano, they're terrible.  When you release the note, you get an echo a moment later.  With the Kawai, that's because they're quite loud and, in some cases, quite long.  With the Italian harpsichord, it's because each release sample really does contain an echo.  There's a bit of pitch, and then a click a moment later.  So maybe that's how it's supposed to sound, but if so, it sounds really bad.

What should I be doing about these?  Should I reduce the volume of the release samples?  Add an offset to skip the beginning of them?  Just not use them?

Then there's the Yamaha piano where the release samples are all completely silent.  Clearly something went wrong with those.