tflood

If I want to use a midi fader (which sends integers between 0-127) to 

control the speed of an LFO (which receives floating point values 

between 0.0 and 20.0 Hz), what is the best way to make the 2 data types 

"match"? I would like the fader to yield a smooth transition between 

values (i.e. no zipper/quantization noise)....

If I want to use a midi fader (which sends integers between 0-127) to 
control the speed of an LFO (which receives floating point values 
between 0.0 and 20.0 Hz), what is the best way to make the 2 data types 
"match"? I would like the fader to yield a smooth transition between 
values (i.e. no zipper/quantization noise)....

midi-control-of-floating-point-values

There are lots of ways to do this in max and your chosen method will depend upon how your LFO works and if you want a linear response.

I suggest the humble "*" object with the value 0.157480314961

(when you save and reload the patch this number will be truncated to 0.15748) This will scale your input to between 0. 20. It's easy to calculate the number needed for other ranges.

If you want more options you could always check out the scale object and help file and search through the tutorials it has all this info and much more!

As for eliminating zipping noises it depends on your lfo you could investigate line or line~

There are lots of ways to do this in max and your chosen method will depend upon how your LFO works and if you want a linear response. 

I suggest the humble "*" object with the value 0.157480314961
(when you save and reload the patch this number will be truncated to 0.15748) This will scale your input to between 0. 20. It's easy to calculate the number needed for other ranges.

Here's an easy way to do it - adjust to suit particulars.

On Feb 25, 2007, at 11:06 AM, Tim Flood wrote:

> If I want to use a midi fader (which sends integers between 0-127) 

> to control the speed of an LFO (which receives floating point 

> values between 0.0 and 20.0 Hz), what is the best way to make the 2 

> data types "match"? I would like the fader to yield a smooth 

> transition between values (i.e. no zipper/quantization noise)....

> Hello Everyone-
>
> If I want to use a midi fader (which sends integers between 0-127)  
> to control the speed of an LFO (which receives floating point  
> values between 0.0 and 20.0 Hz), what is the best way to make the 2  
> data types "match"? I would like the fader to yield a smooth  
> transition between values (i.e. no zipper/quantization noise)....
>

At 1:06 PM -0500 2/25/07, Tim Flood wrote:

>If I want to use a midi fader (which sends integers between 0-127) to control the speed of an LFO (which receives floating point values between 0.0 and 20.0 Hz), what is the best way to make the 2 data types "match"? I would like the fader to yield a smooth transition between values (i.e. no zipper/quantization noise)....

This doesn't address any quantitization/zipper issues, but I don't think that those are really an issue when controlling LFO speed, anyway.

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

At 1:06 PM -0500 2/25/07, Tim Flood wrote:
>If I want to use a midi fader (which sends integers between 0-127) to control the speed of an LFO (which receives floating point values between 0.0 and 20.0 Hz), what is the best way to make the 2 data types "match"? I would like the fader to yield a smooth transition between values (i.e. no zipper/quantization noise)....

-- 
Chris Muir           | "There are many futures and only one status quo.
cbm@well.com         |  This is why conservatives mostly agree,
http://www.xfade.com |  and radicals always argue." - Brian Eno


On Feb 25, 2007, at 6:28 PM, Leafcutter John wrote:

> I suggest the humble "*" object with the value 0.157480314961

> (when you save and reload the patch this number will be truncated 

> to 0.15748) This will scale your input to between 0. 20. It's easy 

> to calculate the number needed for other ranges.

This only works when the low limits are equal in both the input & 

output ranges, otherwise it's a little more complicated.

In the case where they're not equal, an algorithm is:

1) subtract lower limit from input (remove input offset)

2) divide this result by ((input upper limit - input lower limit)* 

(output upper limit - output lower limit))

(i.e., divide by (input range * output range))

3) add output lower limit (add output offset)

[expr ($f1 - $f2)/($f3-$f2)*($f5-$f4)+$f4]

where $f1 = input; $f2 = input lower limit; $f3 = input upper limit; 

$f4 = output lower limit; $f5 = output upper limit

> I suggest the humble "*" object with the value 0.157480314961
> (when you save and reload the patch this number will be truncated  
> to 0.15748) This will scale your input to between 0. 20. It's easy  
> to calculate the number needed for other ranges.
>
> hi output / hi input = scaling factor

  This only works when the low limits are equal in both the input &  
output ranges, otherwise it's a little more complicated.

In the case where they're not equal, an algorithm is:
1) subtract lower limit from input (remove input offset)

2) divide this result by ((input upper limit - input lower limit)* 
(output upper limit - output lower limit))
(i.e., divide by (input range * output range))

in other words, in Max-land:
[expr ($f1 - $f2)/($f3-$f2)*($f5-$f4)+$f4]

where $f1 = input; $f2 = input lower limit; $f3 = input upper limit;  
$f4 = output lower limit; $f5 = output upper limit

Two things. First, your 0-127 control will create only 128 different values

and even though the final output this patch is float, there will be only 128

different floats. This is perhaps not fine enough. Some stepping may be

heard although less likely in an LFO. Second, your output is frequency so

you should be using an exponential interpolation. Of course your minimum

can't be zero. You can figure out a value for the last arg of scale to

create the right shape or use this cludge that does its computations with

midi key numbers with fractional parts. (MIDI is a logarithm of frequency.)

My sliders are scaled to 1000 steps to get a finer resolution.

Two things.  First, your 0-127 control will create only 128 different values
and even though the final output this patch is float, there will be only 128
different floats.  This is perhaps not fine enough.  Some stepping may be
heard although less likely in an LFO.  Second, your output is frequency so
you should be using an exponential interpolation.  Of course your minimum
can't be zero.  You can figure out a value for the last arg of scale to
create the right shape or use this cludge that does its computations with
midi key numbers with fractional parts. (MIDI is a logarithm of frequency.)

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

Since the frequency in this case is perceived not as pitch but as 

rhythm/speed/tempo/whatever, is the log interpolation necessary? 

Given that time is perceived linearly rather than logarithmically, 

this seems to be an extra unneeded step, doesn't it?

On Feb 25, 2007, at 12:27 PM, Gary Lee Nelson wrote:

> you should be using an exponential interpolation. Of course your 

> can't be zero. You can figure out a value for the last arg of 

> create the right shape or use this cludge that does its 

> midi key numbers with fractional parts. (MIDI is a logarithm of 

Since the frequency in this case is perceived not as pitch but as  
rhythm/speed/tempo/whatever, is the log interpolation necessary?  
Given that time is perceived linearly rather than logarithmically,  
this seems to be an extra unneeded step, doesn't it?

> Second, your output is frequency so
> you should be using an exponential interpolation.  Of course your  
> minimum
> can't be zero.  You can figure out a value for the last arg of  
> scale to
> create the right shape or use this cludge that does its  
> computations with
> midi key numbers with fractional parts. (MIDI is a logarithm of  
> frequency.)
>

Tempo IS a frequency and is perceived logarithmically. 120 is twice as fast

as 60 bmp (2/1 an octave) but add 60 again to get 180 and the speed

increases by 3/2 - the third harmonic of 60.

Here is an expression/technique that I use for tempo. 0 is 60, 12 is 120

On 2/25/07 2:59 PM, "Steven Miller" wrote:

> Since the frequency in this case is perceived not as pitch but as

> rhythm/speed/tempo/whatever, is the log interpolation necessary?

> Given that time is perceived linearly rather than logarithmically,

> this seems to be an extra unneeded step, doesn't it?

Tempo IS a frequency and is perceived logarithmically.  120 is twice as fast
as 60 bmp (2/1 an octave) but add 60 again to get 180 and the speed
increases by 3/2 - the third harmonic of 60.

Here is an expression/technique that I use for tempo.  0 is 60, 12 is 120
(up an octave) and -12 is 30 (down 8va).

On 2/25/07 2:59 PM, "Steven Miller"  wrote:

> Since the frequency in this case is perceived not as pitch but as
> rhythm/speed/tempo/whatever, is the log interpolation necessary?
> Given that time is perceived linearly rather than logarithmically,
> this seems to be an extra unneeded step, doesn't it?

Well not really - I don't know exactly how you are using it, but - 

1Hz vibrato to 2Hz is twice as fast - 2Hz vibrato to 4Hz vibrato is 

twice as fast as that - ie if 1Hz is a quarter note, then 2Hz will be 

an eighth note and 4Hz will be a quarter note. The ratios are what 

counts, just as with pitches. If you slowly increase your LFO 

frequency to make an accellerando, the speed increase will actually 

be perceived logarithmically. You might be doing something where this 

On 25 Feb 2007, at 19:59, Steven Miller wrote:

> Since the frequency in this case is perceived not as pitch but as 

> rhythm/speed/tempo/whatever, is the log interpolation necessary? 

> Given that time is perceived linearly rather than logarithmically, 

Lawrence Casserley - lawrence@lcasserley.co.uk

Lawrence Electronic Operations - www.lcasserley.co.uk

Colourscape Music Festivals - www.colourscape.org.uk

Well not really - I don't know exactly how you are using it, but -  
1Hz vibrato to 2Hz is twice as fast - 2Hz vibrato to 4Hz vibrato is  
twice as fast as that - ie if 1Hz is a quarter note, then 2Hz will be  
an eighth note and 4Hz will be a quarter note. The ratios are what  
counts, just as with pitches. If you slowly increase your LFO  
frequency to make an accellerando, the speed increase will actually  
be perceived logarithmically. You might be doing something where this  
doesn't matter, but I rather doubt it.

> Since the frequency in this case is perceived not as pitch but as  
> rhythm/speed/tempo/whatever, is the log interpolation necessary?  
> Given that time is perceived linearly rather than logarithmically,  
> this seems to be an extra unneeded step, doesn't it?

Lawrence Casserley - lawrence@lcasserley.co.uk
Lawrence Electronic Operations - www.lcasserley.co.uk
Colourscape Music Festivals - www.colourscape.org.uk

You're right - I hadn't really thought of it that way. Thanks!

On Feb 25, 2007, at 1:50 PM, Gary Lee Nelson wrote:

> Tempo IS a frequency and is perceived logarithmically. 120 is 

> as 60 bmp (2/1 an octave) but add 60 again to get 180 and the speed

> increases by 3/2 - the third harmonic of 60.

> Tempo IS a frequency and is perceived logarithmically.  120 is  
> twice as fast
> as 60 bmp (2/1 an octave) but add 60 again to get 180 and the speed
> increases by 3/2 - the third harmonic of 60.
>

Yeah, good point. I was thinking about LFO speed as generally faster- 

slower, not synchronized to a tempo per se.

On Feb 25, 2007, at 1:57 PM, lawrence casserley wrote:

> Well not really - I don't know exactly how you are using it, but - 

> 1Hz vibrato to 2Hz is twice as fast - 2Hz vibrato to 4Hz vibrato is 

> twice as fast as that - ie if 1Hz is a quarter note, then 2Hz will 

> be an eighth note and 4Hz will be a quarter note. The ratios are 

> what counts, just as with pitches. If you slowly increase your LFO 

> frequency to make an accellerando, the speed increase will actually 

> be perceived logarithmically. You might be doing something where 

> this doesn't matter, but I rather doubt it.

Yeah, good point. I was thinking about LFO speed as generally faster- 
slower, not synchronized to a tempo per se.

> Well not really - I don't know exactly how you are using it, but -  
> 1Hz vibrato to 2Hz is twice as fast - 2Hz vibrato to 4Hz vibrato is  
> twice as fast as that - ie if 1Hz is a quarter note, then 2Hz will  
> be an eighth note and 4Hz will be a quarter note. The ratios are  
> what counts, just as with pitches. If you slowly increase your LFO  
> frequency to make an accellerando, the speed increase will actually  
> be perceived logarithmically. You might be doing something where  
> this doesn't matter, but I rather doubt it.
>

Hmmm, now we're getting some sophisticated LFO control going on! And 

to think I'd been happy with the plain old knob on that analog 

On Feb 25, 2007, at 2:41 PM, Peter McCulloch wrote:

> Also, you might want to consider using the left inlet of function 

> to remap the signal before sending it to the pack and line~ 

> controlling the LFO speed. Function will allow you better 

> resolution where you need it (and less where you don't) than just 

> standard arithmetic means, and it's significantly easier than 

> finding the appropriate power scaling coefficient. Also, you can 

> do things like ease-in and ease-out for your faders, etc.

Hmmm, now we're getting some sophisticated LFO control going on! And  
to think I'd been happy with the plain old knob on that analog  
modular system all this time... ;)

> Also, you might want to consider using the left inlet of function  
> to remap the signal before sending it to the pack and line~  
> controlling the LFO speed.  Function will allow you better  
> resolution where you need it (and less where you don't) than just  
> standard arithmetic means, and it's significantly easier than  
> finding the appropriate power scaling coefficient.  Also, you can  
> do things like ease-in and ease-out for your faders, etc.
>
> Peter McCulloch
>
>

As said, the function / bpfunction would be helpful, as you can set the domain (x range) to 128 total points, then draw in your desired values (y values) that you want your 0-127 input values to access. Graphical representation of your scaling function, very nice, not to mention that preset works with bpfunction... as does pattr (with lots of interpolation!) etc...

The same goes for the almighty Multislider... use a 128-point one and just draw in your data. You could also use a divisor of 128, like 16... then you'd have only 16 different values that your 0-127 maps to, which would give some "stepping", but this may be interesting too (and can be smoothed by line on the output anyway). Also presettable, and pattr-able.

Table will do this for you too, though I personally don't like dealing with external table files, would rather use a bpfunction or a multislider, with presets / pattrs.

Don't forget *mtr*! Hook one up to the desired values and record your changes until your heart's content (which seems to be never in limitless Max land).

MIDI control of floating point values