Roman, are you using MIDI in theory or "real life"?
"Jitter" is MIDI's "alias name". 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. 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. Actually: I would add a [speedlim 5] to reduce data further and you still wouldn't hear anything unusual. 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). And BTW - why would "random" need extra precision? Doesn't the word random say it all? 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. Ingo > -----Ursprüngliche Nachricht----- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Roman Haefeli > Gesendet: Montag, 24. Februar 2014 14:14 > An: pd-list@iem.at > Betreff: Re: [PD] smooth random numbers > > On Mon, 2014-02-24 at 13:35 +0100, Ingo wrote: > > Sorry, > > > > forgot ta add [change -1] after the [i]. > > > > I thought this was meant to be used with a MIDI signal - maybe I got > that > > wrong? > > Yes, it is. I'm nit-picking here. The patch you posted before also > works, even without the [change -1]. But even adding the [change -1] > doesn't address the issues I mentioned. On a fast ramp, it still misses > some values and it still suffers from jitter. It's only details I'm > talking about here, yes, but since you decided to remove the features > from my version, I hoped to be able to illustrate them with words. > > Roman > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > > > Roman Haefeli > > > Gesendet: Montag, 24. Februar 2014 10:34 > > > An: pd-list@iem.at > > > Betreff: Re: [PD] smooth random numbers > > > > > > On Sun, 2014-02-23 at 04:20 +0100, Ingo wrote: > > > > Starting from Roman's patch I would probably do it like the attached > > > patch. > > > > > > Many ways might solve a certain problem and in Pd those many ways can > > > often be divided into a "subtractive" approach - more than necessary > is > > > generated and the overhead is filtered out afterwards - and an > > > "additive" approach - exactly the data needed is generated. > > > > > > I believe you totally missed the point why I chose the latter here. > > > Using a constant time grain for [line] generates too much data for > slow > > > ramps, leading to many duplicates. Attach a print to our patch and > > > you'll see. At the same time it misses some integer numbers for fast > > > ramps. Also, by having a fixed time grain the result looks like a > > > resampled ramp (which it basically is), which means it is jittery and > > > doesn't emulate a steady movement of the fader. > > > > > > > > > Roman > > > > > > > > > > > > _______________________________________________ > > > Pd-list@iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > > http://lists.puredata.info/listinfo/pd-list > > > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
