written by: WM
Back to the original topic, because the REST problem is more or less solved.I'm using the MIDI hack to give me initial velocity and then OSC for all other continuous movement. Any chance of an option where the first OSC message to be sent out when touching a key would contain a velocity so that it's not necessary to use MIDI?
Hi David
That's not actually possible as MIDI velocity is always more latent than the initial Eigenharp data, it has to be in order for a velocity to be calculated (one needs a number of pressure values in the past to estimate from). This is one of the things that makes the whole velocity concept in MIDI so poor, it's an automatic latency even when one doesn't need it, and it's imposed for everything.
It is possible that we could include a calculated velocity at a later point than the initial data as another OSC data stream (one that doesn't change) and we may do that as part of a proper look at the OSC Agent in a future release. We do plan to make EigenD's inter-operate across the network nicely and this would likely form part of that effort. It won't be happening for 2.0 though as we are now feature frozen. We're just looking at the proposed feature list for 2.1 and I will raise it in the discussion to see if it's a suitable candidate.
John
Yes, I know that --- and I hate the latency it imposes, that's why I said "option". In the case where it's on, I would want OSC to not start being sent until an initial velocity was available.
However, I don't understand how one replicates the behavior (initial loudness or softness) of the initial attack of a piano, guitar, drum, or any other instrument that has an initial percussive piece to it without some way of representing an initial "how hard"
It's not urgent (the MIDI hack does work and I'm using it in live performance), but it's not "nice". I also suspect the latency would be reduced a little bit if one didn't actually have to go though the MIDI processing and transmission.
Hi David
The calculation, treatment and use of velocities in instruments that are essentially percussive in nature is actually quite complicated as soon as one wishes to move to a proper low latency world and away from the large simplifying assumption of MIDI. Even basic percussion instruments do not actually behave as if they have a simple 'velocity' - think of the effect of the continuing force on a drumstick for example, as it strikes a cymbal - if one has existing maintained pressure then what one might call 'velocity' is only one component of that pressure curve, and often not even the most important one.
The latency involved in velocity creation, and the complicated physics/acoustics of how to deal with it in a MIDI world are best illustrated by looking at how low latency MIDI guitar synths deal with it best. In order to be able to choose a sample in a MIDI style world one must ignore absolute pressure and pitch and use the first derivative of pressure over a number of measurements to obtain velocity. But guitars are not actually percussive, they are strings that are displaced then released, which does not fit this model well at all, especially as the initial displacement is by no means silent and our brains take their timing cue from the small unpitched noises this makes when deciding when the note began. Guitar trackers, that must do frequency measurement from string data as well as produce a velocity actually work best when they bodge around this by outputting a pseudo 'string pluck start' noise that is unpitched and of only vague accuracy in volume, then very quickly afterwards output a MIDI pitched note with a more accurate 'velocity'. It's a whole lot of ugly stuff to have to do to work around a limitation caused by us still using 1980's technology in 2012.
The basic assumption that two numbers, a note number and a velocity number, are adequate for even percussion style instruments is untrue. It was a great idea when we were using 8 bit CPU's as it is a good first approximation to much of the problem (and for a few limited cases it may be good enough in the long term), but that's all it will ever be. Instruments should really always calculate this number themselves from a rich pressure stream as it always involves interaction with the underlying sound generation in ways that a supplied point value of the first differential can never achieve.
We have to live with it of course, but in my opinion we should try to be less tolerant of the sometime gross but often subtle reductions in performance expression it introduces. We should, in short, moan about getting it fixed a lot more!
John
I am moaning --- I've been moaning at you guys for about three years now :-)
Your comments are of course dead right but I (and presumably many other players) have to work with what's available now. The velocity mechanism in MIDI is a kludge but it works.
As someone from Microsoft said to me many years ago, "Perfect is the enemy of good enough"
--------
we should try to be less tolerant of the sometime gross but often subtle reductions in performance expression it introduces. We should, in short, moan about getting it fixed a lot more!
I agree with John, real-life instruments, including (especially) the percussion ones, do not have such thing as an 'initial velocity'.
However, we live in a time right now where MIDI and its limitations still rule the world. The amount of synthesizers that will work with aftertouch and forget about an initial velocity completely is limited, if not completely none.
I am trying to figure the same thing out as Dhjdhj, how an estimate of a 'note-start' velocity can be programmed/calculated for use with OSC.
Do I understand you right, John, that the way to do so would be to take a few samples, take the first derivative from that, and then use that function to 'predict' a velocity in the near future?
Wiebe Marten
Hmm... Thank you. But I think you must have used a different set-up, since the experimental OSC-emitting setup found on the wiki(http://www.eigenlabs.com/wiki/2.0/Experimental_Setups/) do not send MIDI, as far as I know...
dhjdhj: Another question, do you still have the dhj.rest object somewhere? On my computer the .mxo object shows up as a folder and MAX(version 5) cannot open it. Thus I'm unable to update my LED colors with MAX as of now.
But that's enough off-topic.
I wonder how the MIDI-velocity is calculated inside the Eigenharp normally... Does this get a more accurate/useable value because of the increased latency, or is there math involved?
Wiebe-Marten
Wiebe, I forgot that some months ago I put together a horrible hack using some guidance from Geert to create a setup that generates MIDI note events where the MIDI note number corresponds to the physical key on the Eigenharp. I then modified my OSC Processor so that it uses both that MIDI data and OSC data.
I've posted a brief writeup about this at http://max4eigenharp.com/?p=77 along with the modified Eigen.OSCProcessor Max object.
Warning: it really is a hack!
Wait... how did my post end up above yours?
That's correct --- I modified the setup with guidance from Geert.
I have updated my response to your original question on the max4eigenharp site to include both the setup and the source for the REST component that I used.
(Unfortunately, the REST component is written in Objective C using Cocoa so not trivially buildable under Windows)
Back to the original topic, because the REST problem is more or less solved.
Today I had a conversation with my math teacher about how one can calculate a possible 'future' pressure state. This turned out to be actually quite simple.
To get an amount of pressure(or any displacement or movement) at a certain time, we need three data samples.
Then, we can calculate the velocity(this is the first derivative), by using:
v = (point1 - point2) / time
Where point 1 and 2 are two pressure samples, and time is the time between the two samples (aka delta time)
To calculate the second derivative (acceleration), we need to first calculate the velocity between point2 and point3, in the same way we did before:
v2 = (point2 - point3) / time
Now, we've got two velocity-values.
To calculate the acceleration, we do the same thing one more time, but now using the first derivative values:
a = (v1 - v2) / time
Now, we can build a function that is a prediction/estimation (we cannot know fore sure how the human's finger will move) of how the pressure will be in the near future.
This function would be:
f(t) = point1 + v1 * t + a * t^2
where t is a point in the future we want to know. By checking a value a few milliseconds or centiseconds in the future, we know how hard the key will have been hit by then.
I have not yet tested this with a real eigenharp yet (I don't have access to mine now) but I have a basic Max patch working with this algorithm.
I think that a latency of three times the normal throughput isn't that bad.
Something like this might be implemented in the OSC agent as well, in which case there might be an even lower latency.
I hope I was able to explain this a little. I'll post my progress and my Max/Msp patch as soon as it is more finished-like and I have tested it with my Pico.
Thanks for reading through this big rant... ^_^!
Have a great day,
Wiebe Marten
Please log in to join the discussions
UK
