cycling74/ease

ease's Issues

ease.permultiple example needs commentary for jit.gen patch

add smooth_polynomial function

Request from Trond:

I’d suggest adding one more easing function from Jamoma, even if it’s not one of Penner’s easing functions: smoothPolynomial. This function has growth rate = 0 and curvature = 0 at the end points, and hence has a completely smooth way of starting and stopping. It might look pretty similar to e.g. the cubic ease in / out, but when using it to ride audio values in order for layers to come and go as drifting waves, there is a difference, and smoothPolynomial sounds really nice.

ease.xfade~

Just ran into a case (portamento for a synth) where we need something like this because it is really challenging patch without it.

investigate rendering in jit.pwindow

Trond notes: With Jitter examples I’d prefer them to reside in jit.pwindow.. E.g. when I open the help file for “ease”, the Jitter window is immediately active, and I expect the front panel of the help file to relate to it, which it doesn’t.

I agree. I tried to do something like this once and the display looked bad and frame rates were terrible. If there is a secret trick to make this work I'd love to figure it out.

FR: add "amount" attr

I'm using ease on a project right now and the client wants to be able to adjust the curves, so I've been lerp-ing the output of ease objects with a linear value. Would be nice to add an "amount" attr to ease objects to do that internally like:
output = (eased*amount)+(linear*(1-amount));

crash when modulating i/o range attributes too quickly

Process 91324 stopped
* thread #73, name = 'MacBook Pro Speakers', stop reason = hit program assert
    frame #4: 0x0000000133d2be48 ease~`ease_base<ease>::apply_easing_function(this=0x0000000137259740, input=0.31759637188225304) at ease_base.h:100:3
   97  			const numbers& input_range  = this->input_range;
   98  			const numbers& output_range = this->output_range;
   99
-> 100 			assert(input_range.size() == 2);
   101 			assert(output_range.size() == 2);
   102
   103 			number diff  = (input_range[1] - input_range[0]);

ease~ help patcher improvements

More good feedback from Trond:

• The basic pane should re-trigg the ramp continuously, so that I do not have to click the toggle every time. Also, it would be clearer if this was done as a ramp from 0 to 1 every time rather than every second time to 1 and back to 0.
• Wouldn’t it be an idea to demo ease~ with a number of different fade-in/outs, so that one could audibly hear what’s going on?
• The scaling pane is not very clear in terms of what it does. The ease happens so fast that it’s impossible to hear the details of what’s going on and consider the effect of changing the ease function. IMHO it would be better to demo this by doing pitch glissandi.

Needs Launch Patcher

jit.ease fails to instantiate in javascript

jsjitterobject_Constructor: null class pointer jit_ease

easetest.zip

ease.xfade~ help patcher bug

Don’t you want the ease.chooser.maxpat abstraction to connect to both ease.xfade~ objects?

ease~ with any circular function yields nan signal values

Hey, trying the mc.ease~ from the helpfile and changing very few things ; if i select any circular easing function (in_circular, in_out_circular, out_circular) the output signal gives some nan values, which can't be downmixed and just sound very loud, whichever gain control operation i try to apply afterwards. From my understanding of easing function, this should not happen, right ? No reason why a circular easing function would give such an out-of-bounds result ? Especially since no other function does suche a thing. Well anyway here is the patch i used, which is nearly just the one from the helpfile, just tuning the phasor at an audio-rate frequency.

----------begin_max5_patcher----------
1014.3ocuWsrrahCDcs8WAEq83R7xFmUyTy17GLUpTBgLnbAIJIgu1IUte6i
dfvfsuDhsuYgQXgPce5SqS27ikK7yXGwBeuO48edKV7ikKVXlROwht+uvuFd
DUAElk4W.Iz27W08j1JIAUBoTb0AHm.oR8hB5dLsslPqvRwvII4l8gk8s+J1
sOMPNrFKw7uhovrJrdEfyaBqU51kvtYsSIO0fsN+HWQPJnvJ+Ud99deo2DRT
IgV7UNFIsuylzj0fUdg6rCg5qAwf0.uunemetbo9xpYFXpQqweOGh5CN+JzG
4eSDBlvgi.ZeLdqcHwc8t7WJ9UkW37AI9nzAiZxwb1qzaCjvqARvsARvuAUM
EMssieRLnNMzQVOSTWwf40XgvKYtrWLXZTWRxywzIiCSh5fPCbCSMCVF+tQs
FZvB7UvtDxqYTBxSs8f.u..X8bI8nc+lr9jn0dRzb3SMDj9QvwpL6lRnfwey
6u0YeBu3YC13O1T7N3uwNDt6CB9RsBcQE9MEemLWru8OAzCshY6heHjKPrF7
rksBimV.NmHZpfmzPQOc76igcc4sar5x.Pud0cACDqtFqpjdIC9ukLl.6Aod
XnP4Ad6aoHIgQcqrhPwHVqsHrCw6YTIUUc0rE+iJCnZRItr1rtBv2pjEX5Pl
1VBx2sudz5IJkEYk2hB5R46hb2YDKyXAL24cGH3WOPDjLREQdZT5598BbmOX
rowjt3GC8BNOmCKDHNqpZHzPUDzKxRNqsnb371FVJu9ErO3v0OHqnlkOpEmL
FOW47Ca5wQXJlFuFYHd9ZElU.ctUnRRelJzAiHrPaN9cmh+9ZTZ.O6Vnh6a8
.wpXbGstMNHX6FM2FkrIcSjgkUcMkrSkpMfu+HUzhAlgMAOjhlNxj0JkmOiq
LlMV4lP4PLkw0omCQgJQkliMgJirjK2aPfJvl+uMMMLJQemNDklNNF0yMg8p
L3BH5jd998ZxF9GsRM8DEuCDt5F2LztCUcBmy2In0d1CQ3K7mADbz6l3ux9y
DZcNPFD8RgIJNbGuAeGaU+iB6NY3tNhvMaqQf9hu1xrg54GmEHXsbjy+bo5d
mCO4XgjPgF0+yKZ7Z5UUBtYl2rs7LLbjcMOjclC.ieB1Y6brSvSvPZA3+LVZ
VIGgw2N6.7XlFLCSeQjXv2F8P1V+MH+5TymQNSzbNDr8JCYO0CaZNf4htEar
gRk+aVAwzUl+RnryM.3yw5tWrq2nZ4C4JYGoRyokaaL33Fa6q95lI3zVRW3T
gNkIExSUWpzz2SgD1XETU3XOTUbaL3G1vnBYeFJYdelTTp0FsXaUWriq5R0X
oAEjrUKc4UtPfohldSEMcRzlBeK+4x+2hBT0w
-----------end_max5_patcher-----------

FR: add @clip attr

Proposed: To add an attribute which will clip the max/min outputs of ease to the values set in the output_range attribute, rather than interpolating above/below those values

ease.xfade~.maxhelp requires MIDI

Maybe we can get a kslider or something in there for those without a MIDI keyboard

help patchers: slow down the transition times

Feedback from Trond:

Generally I find that in the help patchers transitions happens to fast. It’s difficult to see what really happens in 500 ms, and I’d recommend increasing to approx 3000 ms instead. When they are triggered over and over again, i’d leave a small pause in-between eases, so that one gets to see how the arrival at target value feels for different ease functions.

out_cubic function is wrong

see https://cycling74.com/forums/topic/about-the-new-ease-package

I've verified the report.