Bug #1069

problem with ramping in jcom.ramp and jcom.parameter if ramp messages come at rate faster then ramping granularity

Added by Adrian Gierakowski over 6 years ago. Updated about 6 years ago.

Status:RejectedStart date:2012-02-05
Priority:HighDue date:
Assignee:Adrian Gierakowski% Done:


Category:-Spent time:-
Target version:core-maintenance-sprint
Branch: OS:


this cases "choppy" output or no parameter updates at all. Look attached patch

I think this is a result of ramping implementation on which we decided in this thread:

jamoma_ramping_problem.maxpat (23.3 KB) Adrian Gierakowski, 2012-02-05 01:54 pm


#1 Updated by Nils Peters over 6 years ago

  • Target version set to 0.5.5

#2 Updated by Trond Lossius over 6 years ago

  • Assignee set to Trond Lossius

I'll take a look at it, as I know the code of these objects pretty well.

#3 Updated by Trond Lossius over 6 years ago

  • Status changed from New to Assigned

#4 Updated by Trond Lossius over 6 years ago

  • Target version changed from 0.5.5 to core-maintenance-sprint

#5 Updated by Trond Lossius about 6 years ago

  • Assignee changed from Trond Lossius to Adrian Gierakowski

Hi Adrian,

do this cause serious problems for you anywhere? I'm inclined to reject this issue. You are right that if you attempt firing new ramps at a faster rate than the granularity of the ramp, you'll get erroneous behavior, but IMHO this is akin to trying to work on frequencies beyond the Nyquist frequency in regular audio processing. The solution to the problem would need to be set a smaller granularity value, so that the ramp is able to keep up with the lines triggered.

If you agree, Adrian, could you please chage the status of this issue to rejected, and if not elaborate further so that we might consider it further?


#6 Updated by Trond Lossius about 6 years ago

I'd like to add that if you want to do very rapid ramps, the proper solution would probably be the introduction of a new jcom.parameter~ object, producing output at audio rate, with the possibility of audio rate ramping. But this is better suited as a feature request for 0.6.

#7 Updated by Trond Lossius about 6 years ago

  • Status changed from Assigned to Rejected

I'm rejecting this issue.

#8 Updated by Adrian Gierakowski about 6 years ago

Hi Trond,

I sorry I haven't answered you question earlier, I just haven't noticed it since I've been very busy. I'll have to argue that it is not enough to just reject this issue.

The current default ramp granularity is set to 20ms if I remember correct.

Now lets say, we have a slider on one modul, which is mapped to another parameter (using mapperContinuos) with ramping enabled. Now if you move the slider with a mouse, the parameter will be updated (at least on my machine) on average every 15 ms. This means that the second parameter (to which we mapped our slider) is not going to correctly update while we are moving the slider.

This is the current "out of the box" behaviour, which would make any new user think that something is broken. Also for me it would be a paint to manually set the ramping granularity of all parameters which I want to map to using mapperContinuous (with ramping enabled)

I can suggest two solutions:
1.set default ramping granularity to 10ms

2.introduce internally something like a speedlim on the ramping messages set to the value equal to ramp granularity. This way for example if:

1.ramp granularity is set to 20ms
2.a ramp is triggered
3.within next 20 ms more ramp messages are received

then this would result in ignoring the incoming ramp messages until ramp returns its next value and then triggering another ramp according to the most recent received message. I can see that this could cause some problems with high ramp granularity settings (if we dont adjust the time of the delayed ramp message), so I am not sure about this solution.

I'd be happy to hear anu other opinions\ideas



#9 Updated by Trond Lossius about 6 years ago

Hi Adrian,

Can you please help me making sure that we get to discuss this at the next Jamoma BOD?

In your example above, I would ensure that I did not pass the messages from the slider to the module in a way that would trigger ramps, I'd rather update instantly, or do some kind of low-pass filtering on the slider values before passing them to the module.


Also available in: Atom PDF