Hello
i have asked this is a few different ways and experimented but i am wondering, how does one create "smooth random" numbers that flow between each number instead of hoping from number to number?
I would like to start creating random midi values from 0-127 and pick each number say every 5 second and have each random number then flow to the next smoothly. so if say the first number is 60 and the second is 85, the data stream would flow from 60, 61, 62 63.....until it reached 85 and then from 85 smoothly to the next random selection.
I have not had the luck i was hoping with Vline, someone suggested an array but i am hoping someone might share some math or abstraction so i can get a handle on how to implement it
thank you
Patrick
Patrick Pagano B.S, M.F.A Audio and Projection Design Faculty Digital Worlds Institute University of Florida, USA (352)294-2020
I guess you should just use [line] and make sure the line time is equal or just a bit shorter than the object you use to ask random for a new number.
-- Lic. José Rafael Subía Valdez www.jrsv.net
On 22/02/2014, at 16:54, "Pagano, Patrick" pat@digitalworlds.ufl.edu wrote:
Hello
i have asked this is a few different ways and experimented but i am wondering, how does one create "smooth random" numbers that flow between each number instead of hoping from number to number?
I would like to start creating random midi values from 0-127 and pick each number say every 5 second and have each random number then flow to the next smoothly. so if say the first number is 60 and the second is 85, the data stream would flow from 60, 61, 62 63.....until it reached 85 and then from 85 smoothly to the next random selection.
I have not had the luck i was hoping with Vline, someone suggested an array but i am hoping someone might share some math or abstraction so i can get a handle on how to implement it
thank you
Patrick
Patrick Pagano B.S, M.F.A Audio and Projection Design Faculty Digital Worlds Institute University of Florida, USA (352)294-2020 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sam, 2014-02-22 at 21:54 +0000, Pagano, Patrick wrote:
I would like to start creating random midi values from 0-127 and pick each number say every 5 second and have each random number then flow to the next smoothly. so if say the first number is 60 and the second is 85, the data stream would flow from 60, 61, 62 63.....until it reached 85 and then from 85 smoothly to the next random selection.
See attached patch.
I have not had the luck i was hoping with Vline, someone suggested an array but i am hoping someone might share some math or abstraction so i can get a handle on how to implement it
Though one could do it with [vline~ ], it is probably cheaper (cpu-wise) and actually simpler with [line]. The trick is to adjust the time grain to make it output only integer numbers.
Roman
Starting from Roman's patch I would probably do it like the attached patch.
Ingo
#N canvas 988 0 286 367 10; #X obj 71 76 random 128; #X obj 71 49 metro 5000; #X obj 71 31 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 130 line; #X obj 71 150 i; #X obj 71 103 pack f 5000; #X msg 184 32 5000; #X obj 161 325 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 306 5 0 0 0 - - -; #X obj 71 172 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 900 1; #X floatatom 71 306 5 0 0 0 - - -; #X text 197 304 target; #X text 217 20 time; #X obj 14 14 loadbang; #X msg 183 10 1000; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 1 1; #X connect 6 0 5 1; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 1 1; #X connect 14 0 5 1;
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von Roman Haefeli Gesendet: Samstag, 22. Februar 2014 23:27 An: pd-list@iem.at Betreff: Re: [PD] smooth random numbers
On Sam, 2014-02-22 at 21:54 +0000, Pagano, Patrick wrote:
I would like to start creating random midi values from 0-127 and pick each number say every 5 second and have each random number then flow to the next smoothly. so if say the first number is 60 and the second is 85, the data stream would flow from 60, 61, 62 63.....until it reached 85 and then from 85 smoothly to the next random selection.
See attached patch.
I have not had the luck i was hoping with Vline, someone suggested an array but i am hoping someone might share some math or abstraction so i can get a handle on how to implement it
Though one could do it with [vline~ ], it is probably cheaper (cpu-wise) and actually simpler with [line]. The trick is to adjust the time grain to make it output only integer numbers.
Roman
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
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?
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@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
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-bounces@iem.at [mailto:pd-list-bounces@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
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-bounces@iem.at [mailto:pd-list-bounces@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-bounces@iem.at [mailto:pd-list-bounces@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
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
On 2014-02-22 16:54, Pagano, Patrick wrote:
Hello
i have asked this is a few different ways and experimented but i am wondering, how does one create "smooth random" numbers that flow between each number instead of hoping from number to number?
One way is to do a random walk, where you would start with 64 and then add one if random(128) is greater than 63 or subtract one if it's less. (or add zero for some deadband around 63). You could use a constant sample rate or vary that as well with random delays between samples. Random walks tend to walk outside the range so you also need a way to bring it back when it crosses a boundary (0 or 127).
Martin
Hi,
Pagano, Patrick wrote:
i have asked this is a few different ways and experimented but i am wondering, how does one create "smooth random" numbers that flow between each number instead of hoping from number to number?
Maybe you can also use Perlin noise to get deviation rather than pure random ?
There's been a thread about that a few months ago on the list.
On Sat, Feb 22, 2014 at 10:54 PM, Pagano, Patrick pat@digitalworlds.ufl.edu wrote:
Hello
i have asked this is a few different ways and experimented but i am wondering, how does one create "smooth random" numbers that flow between each number instead of hoping from number to number?
When trying to translate the settings of a 10 band graphic equalizer to a smooth spectrum I had a similar issue for which I used cubic interpolation in three steps. The first two steps involves factor 2 'upsampling' each, which renders a 40 point (+interpolation points) curve smooth enough for interpolation to 1024 points in one last step. Attached patch cubic_upsampling.pd shows the interpolation steps done on a sequence of random numbers.
Katja
-
Charles Goyard -
Ingo -
jrsv -
katja -
Martin Peach -
Pagano, Patrick -
Roman Haefeli