Velocity curves calculator : java application for Pianoteq

Hi Jake

I was eager to release it - but without good documentation.
So here is some:

The input range (from -> to) is mapped to the "mapped input" (from -> to)
So the default is that velocities 0->127 are mapped to x=0.0 -> x=1.0
Now f(x) is applied to that range of x's.
Its output is always normalized so that it exactly fits between the output range.

For example: f(x) = x*x, with default parameters would give you a "slow" curve.
If you want to try an "S" shaped curve, then try:
   map input to: From: -1  To: 1
   f(x) = pow(x,3) + x/2

By the way - when you press the "calculate .. button" it already puts the result in the clipboard - so you don't have to copy it yourself.

Hope this helps,

Eran

Thanks. So x is a variable one determines by choosing what kind of curve one wants. I was confused because I thought that there might be a way of arriving at x, that there might be a way to test one's keyboard, for example, to determine the best value for x.

One thing that would be very valuable here: the ability to store the results of the calculations. But, thinking as I write, I guess that what would be saved would be a text file, and we can already store settings as text files.

Regardless, I can see many interesting things that you might dev along similar lines for other parameters. These are things that one can create a spreadsheet for, of course, but your interface is less cumbersome, and combining the calculation with copying the result to the clipboard makes it clean.

Possibly:

iH curves. Are you familiar with the Railsback curve, a representation of how inharmonicity varies from string to string along the keyboard? You might set x as an average deviation for string length? (The ideal is of course to eliminate iH, but if one wants to recreate a specific piano sound, it can be desirable to recreate its iH and then the stretching needed to compensate for it.)

Tuning, perhaps. It might be possible to set up partial matches for a pretuning with something like what you've created. Scala can do this now, but one has to create the text file by hand and load the Scala file. Would require recording all of the default partial matches and the iH on each string and more. Have to think about this. (EDIT: I do understand that PianoTeq is tuned by beat matching, instead of just partial matching. One might be able to roughly match the beats this way, however, and at least quickly compare various combinations of 4:2 or 2:1 octaves etc...?)

Those are just things that I'm thinking about now. In reality, you could set up any calculations for any single parameter that can be pasted into a PianoTeq pane.

Would it also be possible to set up (like a spreadsheet can do, but more cleanly using your interface) variations of a setting that depend on the settings for another parameter? For example, could one copy changed settings for the Piano hammer strike, say, into a java app  and then auto create similar changes for the Mezz and Hard strikes? (In other words, if you've created a fairly complex, irregular remapping of the soft hammer strikes and want to remap the other strikes by exactly the same degree, which takes a while to do manually, one could paste the figures for the soft strikes into the applet and create the same degree of change in the other strikes?) 

I didn't mean to kidnap your thread, however.

Oh, I just understood one thing, I think. To determine the values of Input, you watch the PianoTeq velocity pane and hit your very softest and hardest strikes, yes?

Won't the desired output always be 0 - 1? (Are the "Map input to" boxes needed?)

No ... so this might be a little confusing...
I could have let f(x) just take the original value (0 -> 127) and let you deal with it to produce an adequate output range... but that is not very convenient ... Instead my calculator is running your function over the entire range - it records the minimum and maximum outputs, and scales them to fit the output range that you designated ....

Now - i haven't answered the question of what the "map input" is useful for...
So if you know a little about polynomial curves - then polynoms with odd-degrees, like 3,5,7,etc... have an S shape when their input is running between negative and positive numbers...
So for instance take x to be -10,-9, ...0,...  9, 10
and run it with x*x*x, this will give you an S shape ....
Now in javascript - you can write instead of x*x*x, simply pow(x,3).
The problem now is that the input is running form 0 to 127 ...
so if I hadn't added the "map to input" feature, you'd have to write something like:
  f(x) = pow(x-64, 3) + 64
Because 64 is the middle of the 0-127 range

This is a little awkward. Instead the default input is mapped to 0.00->1.00. Again - if you couldn't change that you'd need to write:
  f(x) = pow(x-0.5,3) + 0.5
Because 0.5 is the middle of the 0 -> 1 range.

So finally - you can simple change the mapping of the input to (-1) -> (1). and have f(x) = pow(x,3).

By the way - due to the automatic normalization of the output- you'll get equivalent result for all the following input mapping:
(-1) -> (1)
-.5 -> .5
-64 -> 64
But you can get interesting result if you do
-2 -> 3

Regarding the "step" - it is not the number of points on the output graph, but rather the "sampling" step of the output. The lower this number, the more points you'll have. More precisely, the number of points is influenced both by the "step" value and the input range. For input range 0->127, and step 8, you'll get 16 points (128/8) points.
Usually you don't need to change the step value. I like 8...

So this could become very valuable as people experiment with various keyboards and match\adjust the responses to Pianoteq. Slowly catching on...

Nice tool ! I could approximate my posted curve with this:

Input Range : 10 to 117 step 16
Map to [ -1 , 1 ]
f(x)=atan(x)
Output Range : 0 to 127

So much more elegant !

I'll add it to the other forum.

Try mapping input from -2 to 2 or -3 to 3 etc. This will produce rounder curves.

atan(x) is the standard name for the arctangent trigonometric function.

See : http://fr.wikipedia.org/wiki/Fonction_arctangente

This amount of control is great. I have to wonder, though, if it might be good to simplify these things by using sliders with labels ("Curve steepness"?) and have the math done in the background, WITH the ability to enter the figures manually, as well, off to the side, or a separate tab, if Java allows tabs.

I don't mean to be critical. I just got lost fast. Thanks so much for creating this program.

I'm looking forward to seeing what people do with this.

One thing that particularly interests me is how different formulas may interact with the hammer hardness settings.

Thanks again.

Hi Cellomangler

Actually I've added drawing (but not posted it yet), and I want to add ability to save/load presets (with some examples). When I get it done i'll post it to my site and ping the forum...

I tried mapping every value from 0 to 127 and didn't notice any slowdown in pianoteq. Translating the velocity curve should take constant time, using a small 128 cell array, no matter how "complex" the velocity graph looks like. I bet this is what Pianoteq is doing... quite standard.

Thanks
Eran

Hi Folks

I posted a new version of the calculator with loading/saving of presets, some predefined presets (with descriptions), and a visualization of the curve.

http://sites.google.com/site/eranshome/software

The presets have an XML format, but their extention is .pcc (PtqCurveCalc).

Enjoy,
Eran

Ha!!! didn't notice that - seems i'm possessed by the devil ...

What I still don't get is how you determine what numbers to feed into it for the shape. Do you have a general shape in mind that you want to create, and then find the numbers that will create it?

Separate question: would it be possible to create a randomization thing for this, with some set, unvarying conditions (the scale must slant to the right, the next step can't be lower than the previous steps, etc)? Just a thought.

Enjoying satan.

That's a shame - the reason I chose java was that it would be cross platform ... It would take a few days until I can get access to a macbook pro .... in the meanwhile - if you are interested I can share the source files (I've developed it in the netbeans IDE)

-- Eran

Yikes. Programming homework. But thanks. I need to learn more of the math. Inexcusable not to, these days.

[Longish post follows.]

Thinking aloud on another subject: I wish that there was a way for users to match their velocity response with PianoTeq: Play a note at given velocities, record the response of their keyboard, and then enter the numbers into your program to establish some points on the plot, and have the program guess at various curves that would connect the points. About the only way I can imagine doing this is to:

1. Have the user listen to some midi-generated notes at specific velocities (say 15, 35, 55, 75, 100, and 127) and then play each on his or her keyboard, trying to match each in amplitude and timbre. There would be a live spectral display of the note to be matched, which would play until the user clicked on "Stop," and a live display of the spectral image as played by the user: visual feedback for the matching. The user wouldn't be trying to match the midi vel, but instead the sound.
2. Two volume meters would also be displayed, one for the recorded note and one for the notes played for the user.  Why volume meters? So users wouldn't make the very easy mistake of thinking their sound was off because they were listening at a lower volume than intended for a timbre and mistook their most audible high freqs for a thin sound. (A perhaps too complex version of this program would actually tell the user when the amplitude and spectral components were a close match, something like piano tuning software that shows a needle indicating closeness to a desired pitch.)
3. The user would also be watching a display like the PianoTeq velocity pane, and would write down what velocities he or she actually played to reach the desired amplitude and timbre for each note.
4. Said user would then enter the velocities he or she wrote down into your program, which would already know the actual velocities played by the midi file that the user listened to, and could make adjustments and  offer various curves that would connect the plot points.

Rube Goldberg? But all of the components exist--It's just a combination of PianoTeq, which can both play the model notes at specific vels and show the user the velocity he or she was playing, opening two spectral\amp displays at once, and your program. (My system, at least, lets me have two sound sources running at once.) But having to open four programs, including yours, is no fun. So could we get the two added spectral\amp displays added to your program tomorrow...?   

Yeah. But it might actually be of great value, since it would let users match their keyboard to any music program that shows a midi event list with the velocities and allows creating vel curves. Music program developers could very easily create midi files that presented the ideal sound to be achieved at given vels with their program, and then let the user recreate it. Might take users about five-ten minutes to adjust their keyboard to the music program, but it would solve the entire problem of variable velocity responses. (I wonder how many support questions relate to velocity response, although the user may not realize that the problem is velocity response?) I can't think of any other way without attaching a velocity reader or a pressure gauge to the user's keyboard and comparing the results with the midi response.

Sorry to drag on about this. I could put something like this together in SynthEdit, I guess, but someone who knows C-Sound or another program that creates active visuals could create something much better.
(Which reflects on me, not on Synthedit). I don't even know if Java can create active spectral displays, let alone two at once...

(This desire to match the keyboard to PianoTeq is why I was thinking about randomization--the thought was that the user might be able to guess a shape that would match up well, and then try out slight, random variations until a close match was achieved, and then fine-tune the match.)

Revision:

Come to think of it, the amp display wouldn't be needed, since spectral display programs show the amplitude by the height of each bar\line. A bar display might be best, for clarity...