Bug #558

RampLib: scheduler have timing issue

Added by Trond Lossius over 1 year ago. Updated over 1 year ago.

Status:Closed Start date:2010-07-13
Priority:Normal Due date:
Assignee:Trond Lossius % Done:

0%
Category:- Spent time: 0.15 hour
Target version:0.5.1
Branch:master OS:

Description

The scheduler jumps immediately to the first step of the ramp instead of waiting. Hence it finish of to early.

I have just added two tests for jcom.ramp that illustrates the issue.

History

#1
Updated by Adrian Gierakowski over 1 year ago

I don't know if that is the case but maybe it has been implemented this way to be consistent with max's line. Here is what is written about it in line.maxhelp:

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.

I didn't have a chance to look at your test but I suppose this is what is happening with jcom.ramp.

#2
Updated by Trond Lossius over 1 year ago

Might be the case, but to me the line implementation is counter-intuitive, so I would personally prefer having it done differently in Jamoma.

@Tim, do you have any opinions on this?

#3
Updated by Trond Lossius over 1 year ago

  • Status changed from New to Closed

Having discussed with Tim on Skype, we agreed on implementing a behavior that differs from standard Max line, but make more sense to us:

  • jcom.ramp will output start value immediately
  • it will then start ramping towards target value.

Example:

We have a jcom.ramp object with:
- drive: scheduler
- granularity: 100 ms
- function: linear

We send the combined message 0, 1000 1000

This cause the following output:

   0 at    0 ms
 100 at  100 ms
 200 at  200 ms
 300 at  300 ms
 ...
 900 at  900 ms
1000 at 1000 ms

This is implemented in rb20a9ff7a9, and closes this issue.

Also available in: Atom PDF