creart wrote:

on Mac I'm getting errors with the program? It doesn't work

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

Console Output: java.lang.NoClassDefFoundError: javax/swing/GroupLayout$Group

Under OS X 10.5 the default version of Java is Java 1.5. Got rid of the above error by changing the default version to Java 1.6 (Java SE 6 64-bit), by launching application Java Preferences.app located at /Applications/Utilities/Java/.

Console Output: Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 129

PtqCurveCalc.jar loads but with no GUI.

I found this article that might help you build PtqCurveCalc with NetBeans so that it will run on OS X. Check it out, if you want to run PtqCurveCalc.jar on any out-of-the-box installation of OSX.

Article: http://jimblackler.net/blog/?p=43

I checked in a new version 1.2 that has a very useful feature:
Each formula can have up to 10 named "constants" - so in order to customize a formula you just need to change the constants without having to understand much of the math behind it. I've described what the constants do in each formula's description field ...

E.g. - I made the "double hump" formula into a more generic "wrinkles" formula, where you can set the number of wrinkles, how much they are "ironed out", their phase, and an overall "belly" that gives the entire shape an "in" or "out" curve ...

Download and check it out here:
http://sites.google.com/site/eranshome/software

Enjoy,
Eran

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

that might be an idea - I am downloading the IDE right now...
It's the 'normal' Java one right?

Then I can try to compile and see what OSX comes up with...
Maybe send me a PM so I can send you my email-information

cheers
Hans

[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.)

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?

Well - let's try to break it down ...:
1) You should get to know the shapes that some functions will give you, and the useful ranges they work with e.g:

1.a) The straight line: "x", simply a rising straight line.

1.b) The square: "x*x", or "pow(x,2)". its useful range is non-negative numbers. e.g. map input from 0->1.
If you map it to negative numbers as well - e.g. -1 -> 1, you'll get a mirror image of the 0->1, i.e. a "bowl" shape - first falling, then rising. You don't want that for velocity.

1.c) sin(x) - it gives you a wave, a full cycle for x=0 -> x=2*PI. A wave in itself is not useful, because it sometimes rises, but sometimes fall - which you don't want. (In math it mean sin(x) is "not monotonously rising", or simply "not monotone"). But later we'll see how to combine functions and make sin(x) useful to create a "rising wave"
Regarding the range you either map the input from 0 -> 6.28, (== 2*PI)
but I prefer to map the input to the number of half-cycles you want,
e.g.: 0->2 for a full cycle, 0->3 for a cycle and half. You can also play with the phase by mapping 1->3, will give you a full cycle but starting on the "off beat" of the cycle.
and then write in f(x): sin(x*PI)

1.d) The cube:  "x*x*x", or "pow(x,3)" -> in the positive range it is similar to x*x, but steeper. However in the negative range it doesn't give you a mirror image, but rather a "rotated" image ,so it is monotone around (-1 -> 1), with a nice S shape.

1.e) The square root: "pow(x,0.5)" - gives a fast rising edge. Can only be used for non-negative inputs - so map your inputs to 0->1

There are more functions, the cos (similar to sin), atan (another interesting s-shape)...

2) but now you can combine them ....
So basically think of if as a "mixing console" - you can combine two (or more) shapes with different "volumes" by adding them together, and multiplying each one by its respective "volume", or coefficient.

So e.g. - if you want a "rising wave" - than you can combine the "sin" function with the straight line "x" like so:
map input to (0 -> 2)
fx: sin(x*PI) + x.
Still not steep enough - let's give "x" some more volume
   sin(x*PI) + x*2
not enough ... how about:
   sin(x*PI) + x*4
This gives a monotone shape ...

another example: say you want to combine the square-root "pow(x,.5)" with the cube S-shape  "pow(x,3)".
The problem here is that square-root can only be used in ranges >0, e.g. 0->1, and the cube you want to use in range -1->1 ...
So what you can so map the input to 0->1, and adjust X inside pow(x,3) to go from range -1->1, like so:
    pow(x*2-1, 3).
Combining the to functions together:
    pow(x,.5) + pow(x*2-1, 3)
Playing with the coefficients to get interesting results:
    30*pow(x,.5) + pow(x*2-1, 3)

Well you can use "random()" combined with some other curve, and give random a low coefficient, so that it only rises, like so:

0.1*random(1) + x
or:
0.2*random(1) + pow(x,3) + x
etc ....

Personally I'd rather have my curve precise w/o any randomness...

best,
Eran

on Mac I'm getting errors with the program? It doesn't work

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

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.

velocity = [0, 1, 9, 17, 25, 33, 41, 49, 57, 65, 73, 81, 89, 97, 105, 113, 121, 127; 0,0, 5, 12, 21, 32, 44, 53, 59, 64, 69, 76, 86, 97, 108, 117, 124, 127]

Obtain by the calculator:
input: 1->127
step: 8
map: 1 -> 5
fx: sin(x*3.14)+x*7
range: 0 -> 127

Here's the pcc file:

<?xml version="1.0" encoding="UTF-8" ?>
<curve version="1.0">
<description>A double hump shape using two cycle of sin(), off by a phase...
The "x*7" component is used to straighten it out </description>
<in_from>1</in_from>
<in_to>127</in_to>
<step>8</step>
<fx>sin(x*3.14)+x*7</fx>
<in_map_from>1</in_map_from>
<in_map_to>5</in_map_to>
<out_from>0</out_from>
<out_to>127</out_to>
</curve>

Thanks. I'm using the s_atan preset some and liking it. Seems to fit. The Satan preset?

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

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

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

Awesome...  kudos !  ...but then get back on the grand unification theory.

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