On Mon, 2014-02-24 at 15:27 +0100, Ingo wrote:
Roman,
are you using MIDI in theory or "real life"?
Frankly, I use (physical) MIDI quiet rarely and I'm far from hitting any of its limits as I mostly use some kind of MIDI controller.
"Jitter" is MIDI's "alias name".
Yeah, I guess that is true.
In practice MIDI data is being reduced as much as possible to avoid overloading the MIDI bus and in return causing serious timing problems or even missing data. Since I would not expect this signal to be the only one through the MIDI interface I would actually reduce the data on fast changes even drastically more.
All (decent) MIDI receiving devices interpolate between the values in order to avoid zipper noise.
Being even more nit-picking, I say interpolation doesn't address jitter, though I totally see what you mean. Being that precise doesn't actually matter that much.
I see your point - in fact I had the same thought that you had at first! I dropped it right away.
Working on a daily basis with MIDI I know that this is a waste of time.
Waste of programming time or waste of CPU time? The latter doesn't really make a difference.
Actually: I would add a [speedlim 5] to reduce data further and you still wouldn't hear anything unusual.
I agree that those subtleties are hardly noticable. However, I felt the need to point out the differences between our approaches, as you removed what I considered crucial parts of the example.
That reminds me a little of people asking for 14-bit pitchbend. It would take about 11 seconds to move the pitchbend wheel on a keyboard from the bottom to the top. Even a 7-bit pitchbend takes more that 80 ms sending all values. It's impossible to play music with a precise timing like this!
In practice a very fast volume change going from 0 - 127 usually gets reduced to 3-5 numbers in order to allow additional controllers like pitchbend and aftertouch to be sent at the same time and still keep the note on jitter within a range of maybe 3-8 ms (plus the jitter of the interface itself).
Sure, can't argue with that. You are assuming a scenario where this MIDI fader emulator is used to control real MIDI receivers. I was more thinking of a scenario where the emulator is used to substitute a real MIDI controller/sender. There is no precision loss within Pd, so why not use the "precise" implementation?
And BTW - why would "random" need extra precision? Doesn't the word random say it all?
No, the endpoints are supposed to be random, not the ramps in between.
Another neglected thing is the curve that the data change should have. That would obviously require some extra calculation. I don't remember reading anything about that in the original posting, though.
Me, neither, though in real that is certainly an issue.
I don't know why I'm so pig-headed with precision. I guess the mere fact that Pd allows for such implementations makes me want to use them everywhere. I personally see beauty in this ability of Pd.
Roman