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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
