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


    Aug 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
    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.

    • Aug 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.
    • Aug 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. > >
    • Aug 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
    • Aug 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.
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Aug 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)
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com