Velocity Mapping For iOS Pianos (and other cool info)

LinearLineman

TECHNICAL DETAILS:

LAYERS and VELOCITY MAPPING

Here's what I know about velocity. The midi spec ties a velocity value from 0-127 to every note. So a keyboard app would map some ranges it detects to values between 0-127. A velocity map in the App would align these input velocity numbers with 2 things:

a sample from a specific layer (softest to hardest)

layer 1 - velocities from 1-10
layer 2 - velocites from 11-20
etc.

then output that sample with an adjustment in volume to smooth out the jumps from 10 to 21 for example.

The layers allow the tone of the piano at various volumes to come through increasing the realism BUT they increase the overall sample size (13GB Clossus with 24 layers).

SAMPLING FIDELITY:

Samples can be capture in 16, 24 or bits and at 41K, 44K or 96Khz. Colossus is 24-bit at 96Khz. It's a better recording essentially.

CPU, RAM RESOURCES and DISK STREAMING:

Larger samples at 96Khz consume a lot more CPU to process. To be processed the sample must be in RAM. Disk streaming means the application loads up enough sound to start any note at any volume. After a note it invoked the additional portion of that sample is brought up from the disk. Somewhere in the IOS hardware there's a buffer getting filled with sound to be played. Miss the update to that buffer for any reason and the audio gets a jump from some value to zero. That is a speaker that is effectively being asked to relocate at the speed of light... not gonna happen. It's going to make an ugly crackle while the buffer starts sending out smoother numeric sequences again that sound like music repeating at some set of combined frequencies.

Colussus set it's specs on the most difficult set of attributes: 24-bits at 96Khz with 24 layers. It's using all the capabilities of the IOS platform and obviously does disk streaming to pull it off with a 13GB sample set. I also noticed that Colussus doesn't report all the RAM used in the IOS Storage report. The only way to see what it really uses since that report doesn't factor in a lot of app data is to delete the App and look at total RAM usage anf re-install which is an over night process and then check storage use to see the real amounts used. That's the 13GB number as I recall but I now have 6 Colussus IAP's so I ain't gonna check this again thanks.

AU support. An AU may not work correctly with a DAW controlling the CPU and the AU App being coded to function as a standalone App. The devloper's will make sure the standalone app doesn't crackle but all bets are off with an AU getting the CPU's attention to load more sound before that buffer runs dry.

NOTE: Auria Pro has a sampler that provides disk streaming and can load SF2, SFZ and ESX24 sample sets. There are wonderful, really large sample sets out there to add to this product. So, glad I bought it for sale at $25 and waited to add Cubasis for $25. They have unique capabilities. Auria Pro owns the buffer and the sampler working well together to keep the output buffer happy and users away from expensive bug reports.

People want Korg and others to just slap an AU interface on their products and support the users satisfaction. Big companies usually won't take the risk of explaining that all AU's won't work all the time in all cases. It's not their fault. Supplying an AU must factor in the
consequence of handing control to another App that's scheduling resources and keeping that output buffer full with wonderful planned sounds.

POLYPHONY and LATENCY:

We only have 10 fingers so 10 notes at a time should do it right? Wrong. Enter the missing "sustain pedal". Sustain lets the piano string resonate until that pedal is lifted.

So, great piano apps can offer over 100 notes played in a stereo image (bass on the left and treble notes to the right) for additional realism. Most top end Piano Apps have MIDI Players in the product so a piano can play along with another piano with another piano... to the max polyphony. Some of the entrants in the Piano Poll were just throwing away NOTE events due to limited CPU resources or a lack of polyphony in the MIDI file player. The MIDI Clock never rests for the App to catch up. It just tells the app to make a specific note the next note using time stamps on every note. Miss a note's time stamp and just drop the event. No crackles... just missing chord tones or worse the melody. Still not sure what changed some G#'s to G natural on Contestant #19 (BeatHawk Acoustic). I think it got fixed.

Colossus specs show 140 notes in stereo and 280 in mono.

To feel real to the pianist the application has to be responsive. Less than 10 millisecond to be undetectable I think. That means the DAW has to output sound within 1/100th of second. Making that a priority over processing FX or mixing in other sounds to the output buffers.

I keep sharing the Colossus specs because Crudebyte reports them. Ravenscroft is a bit more circumspect here. They report 883 MB of disk space and not much more technical detail. They solve the problem using a totally different focus: modeling a final sound using a base set of samples rather than the multi-Gigabytes of 24-bit @ 96Khz 24-layer audio wave files. I think the trade-off of pushing more work towards the CPU to use math models is the key to making the piano a good citizen in a DAW with all the other tracks you want to render, record or playback in that one set of output buffers in realtime.

The Salamander sample set in Auria Pro is closer to the Crudebyte approach but the resource management is in the DAW's sampler. So, it sounds wonderful using great multi-GB wave files and has great tools in the DAW for EQ, Reverb, Compression and velocity mapping.

"Piano in 162" Library I thought it was a finalist has these specs:

5GB Sample Library in SFZ standard format (It's also available in Kontakt and Korg Kronos formats)

It's a Steinway B and not a Yamaha C (Players will tend to prefer one or the other for personal use vs playing live in a combo). Similar to IOS uses in a solo context vs adding it to a complex mix.

all notes have been sampled, for full duration

NOTE: Salamander's Yamaha is recorded as A's, C's, Eb's and F#'s and all the other notes are shifted from these recordings at playback

2 stereo mic positions (Close and Ambient "distant" in the room")

five dynamic levels (layers?)

two round robins: a simple way to let sample developers play back a different sampled version of the same sound each time you hit the same key, so that just like most acoustic instruments each note sounds slightly different for more realism

a separate pedal on and off samples for a true to life sound with realistic sympathetic resonance

Add in Auria doing Disk Streaming you've got a world class sounding piano. It's just not normalized in the SFZ format so you have to add a lot of compression to use it. The default Compressor in Auria Pro colors the sound too much so you need to upgrade the Compressor. I have my eye on the FabFilter Pro C 2 which just went "off sale". The AUv3 model will probably come out at the same $30 price.

[Deleted User]

@LinearLineman said:
TECHNICAL DETAILS:

LAYERS and VELOCITY MAPPING

Here's what I know about velocity. The midi spec ties a velocity value from 0-127 to every note. So a keyboard app would map some ranges it detects to values between 0-127. A velocity map in the App would align these input velocity numbers with 2 things:

a sample from a specific layer (softest to hardest)

layer 1 - velocities from 1-10
layer 2 - velocites from 11-20
etc.

then output that sample with an adjustment in volume to smooth out the jumps from 10 to 21 for example.

The layers allow the tone of the piano at various volumes to come through increasing the realism BUT they increase the overall sample size (13GB Clossus with 24 layers).

SAMPLING FIDELITY:

Samples can be capture in 16, 24 or bits and at 41K, 44K or 96Khz. Colossus is 24-bit at 96Khz. It's a better recording essentially.

CPU, RAM RESOURCES and DISK STREAMING:

Larger samples at 96Khz consume a lot more CPU to process. To be processed the sample must be in RAM. Disk streaming means the application loads up enough sound to start any note at any volume. After a note it invoked the additional portion of that sample is brought up from the disk. Somewhere in the IOS hardware there's a buffer getting filled with sound to be played. Miss the update to that buffer for any reason and the audio gets a jump from some value to zero. That is a speaker that is effectively being asked to relocate at the speed of light... not gonna happen. It's going to make an ugly crackle while the buffer starts sending out smoother numeric sequences again that sound like music repeating at some set of combined frequencies.

Colussus set it's specs on the most difficult set of attributes: 24-bits at 96Khz with 24 layers. It's using all the capabilities of the IOS platform and obviously does disk streaming to pull it off with a 13GB sample set. I also noticed that Colussus doesn't report all the RAM used in the IOS Storage report. The only way to see what it really uses since that report doesn't factor in a lot of app data is to delete the App and look at total RAM usage anf re-install which is an over night process and then check storage use to see the real amounts used. That's the 13GB number as I recall but I now have 6 Colussus IAP's so I ain't gonna check this again thanks.

AU support. An AU may not work correctly with a DAW controlling the CPU and the AU App being coded to function as a standalone App. The devloper's will make sure the standalone app doesn't crackle but all bets are off with an AU getting the CPU's attention to load more sound before that buffer runs dry.

NOTE: Auria Pro has a sampler that provides disk streaming and can load SF2, SFZ and ESX24 sample sets. There are wonderful, really large sample sets out there to add to this product. So, glad I bought it for sale at $25 and waited to add Cubasis for $25. They have unique capabilities. Auria Pro owns the buffer and the sampler working well together to keep the output buffer happy and users away from expensive bug reports.

People want Korg and others to just slap an AU interface on their products and support the users satisfaction. Big companies usually won't take the risk of explaining that all AU's won't work all the time in all cases. It's not their fault. Supplying an AU must factor in the
consequence of handing control to another App that's scheduling resources and keeping that output buffer full with wonderful planned sounds.

POLYPHONY and LATENCY:

We only have 10 fingers so 10 notes at a time should do it right? Wrong. Enter the missing "sustain pedal". Sustain lets the piano string resonate until that pedal is lifted.

So, great piano apps can offer over 100 notes played in a stereo image (bass on the left and treble notes to the right) for additional realism. Most top end Piano Apps have MIDI Players in the product so a piano can play along with another piano with another piano... to the max polyphony. Some of the entrants in the Piano Poll were just throwing away NOTE events due to limited CPU resources or a lack of polyphony in the MIDI file player. The MIDI Clock never rests for the App to catch up. It just tells the app to make a specific note the next note using time stamps on every note. Miss a note's time stamp and just drop the event. No crackles... just missing chord tones or worse the melody. Still not sure what changed some G#'s to G natural on Contestant #19 (BeatHawk Acoustic). I think it got fixed.

Colossus specs show 140 notes in stereo and 280 in mono.

To feel real to the pianist the application has to be responsive. Less than 10 millisecond to be undetectable I think. That means the DAW has to output sound within 1/100th of second. Making that a priority over processing FX or mixing in other sounds to the output buffers.

I keep sharing the Colossus specs because Crudebyte reports them. Ravenscroft is a bit more circumspect here. They report 883 MB of disk space and not much more technical detail. They solve the problem using a totally different focus: modeling a final sound using a base set of samples rather than the multi-Gigabytes of 24-bit @ 96Khz 24-layer audio wave files. I think the trade-off of pushing more work towards the CPU to use math models is the key to making the piano a good citizen in a DAW with all the other tracks you want to render, record or playback in that one set of output buffers in realtime.

The Salamander sample set in Auria Pro is closer to the Crudebyte approach but the resource management is in the DAW's sampler. So, it sounds wonderful using great multi-GB wave files and has great tools in the DAW for EQ, Reverb, Compression and velocity mapping.

"Piano in 162" Library I thought it was a finalist has these specs:

5GB Sample Library in SFZ standard format (It's also available in Kontakt and Korg Kronos formats)

It's a Steinway B and not a Yamaha C (Players will tend to prefer one or the other for personal use vs playing live in a combo). Similar to IOS uses in a solo context vs adding it to a complex mix.

all notes have been sampled, for full duration

NOTE: Salamander's Yamaha is recorded as A's, C's, Eb's and F#'s and all the other notes are shifted from these recordings at playback

2 stereo mic positions (Close and Ambient "distant" in the room")

five dynamic levels (layers?)

two round robins: a simple way to let sample developers play back a different sampled version of the same sound each time you hit the same key, so that just like most acoustic instruments each note sounds slightly different for more realism

a separate pedal on and off samples for a true to life sound with realistic sympathetic resonance

Add in Auria doing Disk Streaming you've got a world class sounding piano. It's just not normalized in the SFZ format so you have to add a lot of compression to use it. The default Compressor in Auria Pro colors the sound too much so you need to upgrade the Compressor. I have my eye on the FabFilter Pro C 2 which just went "off sale". The AUv3 model will probably come out at the same $30 price.

I posted this on the wiki at:
https://wiki.audiob.us/app_tutorials/Sample_Instrument/Piano_Sample_Instrument

espiegel123

I've updated the title and tweaked some formatting. The updated article is:
https://wiki.audiob.us/velocity_mapping_for_ios_pianos