Forums > MaxMSP

Bug report: line ramps to new values in less time then specified

August 15, 2006 | 7:30 am


Summary:

line ramps to new values in less time then specified

Steps to Reproduce:

1) Open the patch below
2) Click each of the three message boxes at the top of the patch
3) Observe what is printed to the Max window

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 266 211 45 196617 ——-;
#P message 213 62 65 196617 0 , 12. 1201;
#N vpatcher 20 74 620 474;
#P outlet 96 82 15 0;
#P inlet 96 44 15 0;
#P connect 0 0 1 0;
#P pop;
#P newobj 65 107 37 196617 p thru;
#P message 141 62 65 196617 0 , 12. 1200;
#P newex 65 310 32 196617 print;
#P newex 65 274 139 196617 sprintf value %f at time %ld;
#P newex 219 211 20 196617 t b;
#P newex 194 173 20 196617 t b;
#P newex 194 237 35 196617 timer;
#P flonum 65 222 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 65 62 65 196617 0 , 11. 1100;
#P newex 65 151 59 196617 line 0. 200;
#P fasten 11 0 7 0 271 303 70 303;
#P connect 4 0 3 0;
#P connect 4 0 11 0;
#P connect 9 0 0 0;
#P fasten 9 0 4 0 70 132 199 132;
#P connect 0 0 2 0;
#P connect 0 0 5 0;
#P fasten 10 0 9 0 218 92 70 92;
#P fasten 8 0 9 0 146 92 70 92;
#P fasten 1 0 9 0 70 92 70 92;
#P connect 6 0 7 0;
#P connect 3 0 6 1;
#P connect 2 0 6 0;
#P connect 5 0 3 1;
#P window clipboard copycount 12;

Expected Results:

If ramp is to move from 0. to 11. in 1100 ms with a grain size of 200
ms, I would expect it to pour out values as if the line was drawn on the
time axis from (0,0) to (1100,11) and current value sampled every 200
ms. So I would have expected something like:

value 0 at time 0
value 2 at time 200
value 4 at time 400
value 6 at time 600
value 8 at time 800
value 10 at time 1000
value 11 at time 1200

If it is to ramp from 0. to 12. in 1200 ms I would expect:

value 0 at time 0
value 2 at time 200
value 4 at time 400
value 6 at time 600
value 8 at time 800
value 10 at time 1000
value 12 at time 1200

and if it is to ramp from 0. to 12. in 1201 ms I would expect numbers
that slightly smaller (1.99999, 3.99999, etc.) and a final value 12 at
time 1400.


August 15, 2006 | 7:40 am

Just want to add that this is on a Mac TiBook 1GHz (PPC) running Mac OSX
10.4.7 and Max 4.6.

Best,
Trond

Trond Lossius wrote:
> Summary:
>
> line ramps to new values in less time then specified
>
>
> Steps to Reproduce:
>
> 1) Open the patch below
> 2) Click each of the three message boxes at the top of the patch
> 3) Observe what is printed to the Max window
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 266 211 45 196617 ——-;
> #P message 213 62 65 196617 0 , 12. 1201;
> #N vpatcher 20 74 620 474;
> #P outlet 96 82 15 0;
> #P inlet 96 44 15 0;
> #P connect 0 0 1 0;
> #P pop;
> #P newobj 65 107 37 196617 p thru;
> #P message 141 62 65 196617 0 , 12. 1200;
> #P newex 65 310 32 196617 print;
> #P newex 65 274 139 196617 sprintf value %f at time %ld;
> #P newex 219 211 20 196617 t b;
> #P newex 194 173 20 196617 t b;
> #P newex 194 237 35 196617 timer;
> #P flonum 65 222 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 65 62 65 196617 0 , 11. 1100;
> #P newex 65 151 59 196617 line 0. 200;
> #P fasten 11 0 7 0 271 303 70 303;
> #P connect 4 0 3 0;
> #P connect 4 0 11 0;
> #P connect 9 0 0 0;
> #P fasten 9 0 4 0 70 132 199 132;
> #P connect 0 0 2 0;
> #P connect 0 0 5 0;
> #P fasten 10 0 9 0 218 92 70 92;
> #P fasten 8 0 9 0 146 92 70 92;
> #P fasten 1 0 9 0 70 92 70 92;
> #P connect 6 0 7 0;
> #P connect 3 0 6 1;
> #P connect 2 0 6 0;
> #P connect 5 0 3 1;
> #P window clipboard copycount 12;
>
>
> Expected Results:
>
> If ramp is to move from 0. to 11. in 1100 ms with a grain size of 200
> ms, I would expect it to pour out values as if the line was drawn on
> the time axis from (0,0) to (1100,11) and current value sampled every
> 200 ms. So I would have expected something like:
>
> value 0 at time 0
> value 2 at time 200
> value 4 at time 400
> value 6 at time 600
> value 8 at time 800
> value 10 at time 1000
> value 11 at time 1200
>
> If it is to ramp from 0. to 12. in 1200 ms I would expect:
>
> value 0 at time 0
> value 2 at time 200
> value 4 at time 400
> value 6 at time 600
> value 8 at time 800
> value 10 at time 1000
> value 12 at time 1200
>
> and if it is to ramp from 0. to 12. in 1201 ms I would expect numbers
> that slightly smaller (1.99999, 3.99999, etc.) and a final value 12 at
> time 1400.


August 15, 2006 | 7:52 am

Sorry for the traffic, I suppose I should have surveyed the help file
properly before posting:

The line object starts its progress to the destination immediately
(i.e., starts progressing FROM the specified starting point, but does
not necessarily start AT it). So it actually arrives at its destination
one grain’s worth of time EARLIER than the total time specified. In many
cases (especially using small time grains) this does not pose serious
problems, however the examples below show some tricks you can use to get
around this issue if it does pose a problem in your patch.

I suppose that it is difficult to change this for backward compatibility
reasons, but this is a cumbersome and non-intuitive implementation of a
linear ramp as far as I am concerned.

Best,
Trond

Trond Lossius wrote:
> Just want to add that this is on a Mac TiBook 1GHz (PPC) running Mac
> OSX 10.4.7 and Max 4.6.
>
> Best,
> Trond
>
> Trond Lossius wrote:
>> Summary:
>>
>> line ramps to new values in less time then specified
>>
>>
>> Steps to Reproduce:
>>
>> 1) Open the patch below
>> 2) Click each of the three message boxes at the top of the patch
>> 3) Observe what is printed to the Max window
>>
>> #P window setfont "Sans Serif" 9.;
>> #P window linecount 1;
>> #P message 266 211 45 196617 ——-;
>> #P message 213 62 65 196617 0 , 12. 1201;
>> #N vpatcher 20 74 620 474;
>> #P outlet 96 82 15 0;
>> #P inlet 96 44 15 0;
>> #P connect 0 0 1 0;
>> #P pop;
>> #P newobj 65 107 37 196617 p thru;
>> #P message 141 62 65 196617 0 , 12. 1200;
>> #P newex 65 310 32 196617 print;
>> #P newex 65 274 139 196617 sprintf value %f at time %ld;
>> #P newex 219 211 20 196617 t b;
>> #P newex 194 173 20 196617 t b;
>> #P newex 194 237 35 196617 timer;
>> #P flonum 65 222 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
>> #P message 65 62 65 196617 0 , 11. 1100;
>> #P newex 65 151 59 196617 line 0. 200;
>> #P fasten 11 0 7 0 271 303 70 303;
>> #P connect 4 0 3 0;
>> #P connect 4 0 11 0;
>> #P connect 9 0 0 0;
>> #P fasten 9 0 4 0 70 132 199 132;
>> #P connect 0 0 2 0;
>> #P connect 0 0 5 0;
>> #P fasten 10 0 9 0 218 92 70 92;
>> #P fasten 8 0 9 0 146 92 70 92;
>> #P fasten 1 0 9 0 70 92 70 92;
>> #P connect 6 0 7 0;
>> #P connect 3 0 6 1;
>> #P connect 2 0 6 0;
>> #P connect 5 0 3 1;
>> #P window clipboard copycount 12;
>>
>>
>> Expected Results:
>>
>> If ramp is to move from 0. to 11. in 1100 ms with a grain size of 200
>> ms, I would expect it to pour out values as if the line was drawn on
>> the time axis from (0,0) to (1100,11) and current value sampled
>> every 200 ms. So I would have expected something like:
>>
>> value 0 at time 0
>> value 2 at time 200
>> value 4 at time 400
>> value 6 at time 600
>> value 8 at time 800
>> value 10 at time 1000
>> value 11 at time 1200
>>
>> If it is to ramp from 0. to 12. in 1200 ms I would expect:
>>
>> value 0 at time 0
>> value 2 at time 200
>> value 4 at time 400
>> value 6 at time 600
>> value 8 at time 800
>> value 10 at time 1000
>> value 12 at time 1200
>>
>> and if it is to ramp from 0. to 12. in 1201 ms I would expect numbers
>> that slightly smaller (1.99999, 3.99999, etc.) and a final value 12
>> at time 1400.
>
>


August 15, 2006 | 9:19 am

Hi Trond,

I think the [line_timing_tricks] subpatch in line.help explains the
behavior you’re seeing, at least in part.

Line’s timing logic is not what one would necessarily expect. It
appears that line is determined to reach the target value at the very
latest by the "deadline", and if granularity is not an integral
divisor of the ramp duration, the target time is moved forward.

There is probably a place for a 3rd party line that would work as you
were looking for, interpreting parameters more strictly.

– Peter

On 15-Aug-2006, at 9:30, Trond Lossius wrote:

> Summary:
>
> line ramps to new values in less time then specified

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de


August 16, 2006 | 4:41 pm

Trond Lossius wrote:
> I suppose that it is difficult to change this for backward compatibility
> reasons, but this is a cumbersome and non-intuitive implementation of a
> linear ramp as far as I am concerned.

I agree, that’s why I just modified my lines abhaXion to correct this:
(In this case I don’t worry too much about backwards compatibility, I
assume it will correct old patches more likely than breaking them ;-)

lines will accept, as before, lists of arbitrary lengths, but will do
the timing now intuitively correct… (it will output the last value
exactly when specified, the last grain is shorter if it doesn’t fit
exactly into mutiple grain durations.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 31 263 63 196617 prepend set;
#P newex 13 286 42 196617 change;
#P newex 199 40 50 196617 zl slice 1;
#P newex 199 20 63 196617 patcherargs;
#N vpatcher 40 104 392 324;
#P window setfont "Sans Serif" 9.;
#P window linecount 0;
#P newex 152 111 50 196617 deferlow;
#P outlet 127 159 15 0;
#P newex 127 134 35 196617 zl reg;
#P outlet 205 159 15 0;
#P newex 205 111 34 196617 delay;
#P newex 205 89 34 196617 t b i;
#P newex 152 68 63 196617 zl slice 1;
#P outlet 175 159 15 0;
#P inlet 123 30 15 0;
#P newex 73 89 13 196617 b;
#P newex 73 110 60 196617 delay 20;
#P newex 73 134 51 196617 zl reg;
#P window linecount 1;
#P newex 50 50 75 196617 route int float;
#P inlet 50 30 15 0;
#P outlet 50 159 15 0;
#P connect 1 0 2 0;
#P fasten 3 0 0 0 78 155 55 155;
#P fasten 2 1 0 0 87 78 55 78;
#P connect 2 0 0 0;
#P fasten 2 2 5 0 119 84 78 84;
#P connect 5 0 4 0;
#P connect 4 0 3 0;
#P connect 2 2 3 1;
#P connect 6 0 4 1;
#P fasten 10 0 12 0 210 131 132 131;
#P connect 12 0 13 0;
#P connect 2 2 8 0;
#P connect 8 0 14 0;
#P connect 14 0 12 1;
#P fasten 6 0 7 0 128 101 180 101;
#P connect 8 1 9 0;
#P connect 9 0 10 0;
#P connect 10 0 11 0;
#P connect 9 1 10 1;
#P pop;
#P newobj 13 126 157 196617 p grain duration correction;
#P newex 213 172 29 196617 gate;
#P newex 213 84 29 196617 == 2;
#P newex 99 286 29 196617 sel 1;
#P newex 99 263 29 196617 == 1;
#P newex 130 84 31 196617 > 2;
#P newex 130 172 40 196617 gate;
#P newex 130 62 31 196617 zl len;
#P newex 130 193 51 196617 zl reg;
#P newex 13 40 178 196617 t l 2147483647 3;
#P outlet 181 317 15 0;
#P newex 181 286 33 196617 gate;
#P newex 181 263 26 196617 < = 2;
#P inlet 160 20 15 0;
#P inlet 62 20 15 0;
#P newex 130 215 85 196617 t l l b;
#P newex 130 286 47 196617 gate;
#P newex 130 263 32 196617 > 2;
#P newex 130 237 32 196617 zl len;
#P newex 13 104 168 196617 zl slice 2;
#P newex 13 148 109 196617 line $1;
#P outlet 13 316 15 0;
#P inlet 13 20 15 0;
#P window linecount 5;
#P comment 25 180 100 196617 this can replace the line object and will
do it like line~ with as many point time pairs as you want.;
#P connect 23 3 17 1;
#P connect 23 3 22 1;
#P connect 21 0 22 0;
#P connect 16 0 18 0;
#P fasten 16 0 21 0 135 81 218 81;
#P connect 8 2 12 1;
#P connect 24 0 25 0;
#P connect 12 0 13 0;
#P fasten 20 0 13 0 104 313 186 313;
#P fasten 22 0 13 0 218 313 186 313;
#P connect 11 0 12 0;
#P fasten 5 0 11 0 135 259 186 259;
#P fasten 14 2 6 0 186 259 135 259;
#P connect 14 2 11 0;
#P connect 4 1 15 1;
#P connect 8 1 7 1;
#P fasten 25 1 23 1 244 65 165 65;
#P connect 10 0 23 1;
#P connect 6 0 7 0;
#P fasten 5 0 19 0 135 259 104 259;
#P connect 5 0 6 0;
#P connect 8 0 5 0;
#P connect 15 0 8 0;
#P connect 17 0 15 0;
#P connect 18 0 17 0;
#P connect 14 0 4 0;
#P fasten 14 0 16 0 18 59 135 59;
#P connect 23 2 3 2;
#P connect 19 0 20 0;
#P connect 9 0 3 1;
#P fasten 14 1 27 0 102 249 36 249;
#P connect 26 0 2 0;
#P connect 23 1 26 0;
#P connect 3 0 26 0;
#P connect 27 0 26 0;
#P connect 23 0 3 0;
#P connect 4 0 23 0;
#P fasten 7 0 4 0 135 307 6 307 6 96 18 96;
#P connect 1 0 14 0;
#P window clipboard copycount 28;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


August 17, 2006 | 8:39 am

Stefan Tiedje wrote:
> I just modified my lines abhaXion to correct this:

The new help file with the timing test… (save the patch of the last
post as lines)

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 110 98 27 196617 stop;
#P message 185 75 207 196617 0 , 99.400002 2001 10.3 1903 449.5 2096;
#P newex 26 232 32 196617 print;
#P newex 26 196 139 196617 sprintf value %f at time %ld;
#P newex 155 150 13 196617 b;
#P newex 155 173 34 196617 timer;
#P message 36 98 71 196617 10 2000 200;
#P newex 60 232 105 196617 Abhaxions.Copyright;
#P button 84 151 15 0;
#P flonum 26 151 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 26 125 68 196617 lines 50. 200;
#P message 26 75 156 196617 0 , 100 2000 10 2100 500 2000;
#P newex 274 44 29 196617 line~;
#P newex 83 44 23 196617 line;
#P comment 26 46 56 196617 lines is like;
#P comment 107 46 166 196617 but it allows multisegment lists like;
#P newex 179 150 13 196617 b;
#P window linecount 9;
#P comment 218 109 100 196617 the timer construction shows that you
don’t need the "timing tricks" explained in the line help file to get
exact timing (they are incorporated already)…;
#P fasten 11 0 7 0 41 118 31 118;
#P fasten 16 0 7 0 190 93 31 93;
#P connect 6 0 7 0;
#P fasten 17 0 7 0 115 118 31 118;
#P connect 7 0 8 0;
#P connect 8 0 14 0;
#P connect 14 0 15 0;
#P connect 7 1 9 0;
#P fasten 11 0 13 0 41 118 160 118;
#P fasten 6 0 13 0 31 93 160 93;
#P fasten 16 0 13 0 190 93 160 93;
#P connect 13 0 12 0;
#P connect 12 0 14 1;
#P fasten 7 0 1 0 31 146 184 146;
#P connect 1 0 12 1;
#P window clipboard copycount 18;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


Viewing 6 posts - 1 through 6 (of 6 total)