keithmanlove

I'm clearly not getting a concept here. I'm trying to turn a knob

back and forth to interpolate presets with pattr (the number box at

the top is emulating ctlin), and when it goes slow, things are fine.

When I move the numbers quickly, it completely doesn't work. The

division at the bottom (/ 501.) worked when the ramp was 10000ms. I

would like to be able to turn the knob at varying speeds, so maybe

this idea won't work. Any help, or a redirect to a relevant post

I'm clearly not getting a concept here.  I'm trying to turn a knob
back and forth to interpolate presets with pattr (the number box at
the top is emulating ctlin), and when it goes slow, things are fine.
When I move the numbers quickly, it completely doesn't work.  The
division at the bottom (/ 501.) worked when the ramp was 10000ms.  I
would like to be able to turn the knob at varying speeds, so maybe
this idea won't work.  Any help, or a redirect to a relevant post
would be great.

is-it-a-trigger-counter-step-rate-or-number-box-problem

works for me... at basically any speed. Am I correct in my understanding that the error you are encountering is that the update of the result after the [/501.] is slow or irregular?

Are there some preferences in Max which could affect this?

works for me... at basically any speed.  Am I correct in my understanding that the error you are encountering is that the update of the result after the [/501.] is slow or irregular?
Are there some preferences in Max which could affect this?


Yes, I can confirm that problem, same here. grmpf.. Also wanted to 

Yes, I can confirm that problem, same here. grmpf..  Also wanted to  
use that with a controller....

You may be assuming that fast changes made on the controller / number 

box still hit every value (0-127), which is certainly not true, and 

seems to be an assumption of your patch. Is this what you want to do?

Am 02.06.2006 um 22:36 schrieb keith manlove:

> I'm clearly not getting a concept here. I'm trying to turn a knob

> back and forth to interpolate presets with pattr (the number box at

> the top is emulating ctlin), and when it goes slow, things are fine.

> When I move the numbers quickly, it completely doesn't work. The

> division at the bottom (/ 501.) worked when the ramp was 10000ms. I

> would like to be able to turn the knob at varying speeds, so maybe

> this idea won't work. Any help, or a redirect to a relevant post

You may be assuming that fast changes made on the controller / number  
box still hit every value (0-127), which is certainly not true, and  
seems to be an assumption of your patch. Is this what you want to do?

> I'm clearly not getting a concept here.  I'm trying to turn a knob
> back and forth to interpolate presets with pattr (the number box at
> the top is emulating ctlin), and when it goes slow, things are fine.
> When I move the numbers quickly, it completely doesn't work.  The
> division at the bottom (/ 501.) worked when the ramp was 10000ms.  I
> would like to be able to turn the knob at varying speeds, so maybe
> this idea won't work.  Any help, or a redirect to a relevant post
> would be great.


no, what I was aiming at was more sth. like this (with lists) and it 

no, what I was aiming at was more sth. like this (with lists) and it  
seems to work smoothly.

Although this nicely demonstrates how to hook an external source to 

the recall values of pattrstorage, I'm afraid don't see what this 

patch and Keith Manlove's problem have to do with each other.

Although this nicely demonstrates how to hook an external source to  
the recall values of pattrstorage, I'm afraid don't see what this  
patch and Keith Manlove's problem have to do with each other.

It was just a misunderstanding, i replied too quickly, assuming u 

were meaning me when asking if its what i wanted to do... sorry for 

It was just a misunderstanding, i replied too quickly, assuming u  
were meaning me when asking if its what i wanted to do... sorry for  
that. ;-)

> works for me... at basically any speed. Am I correct in my understanding that the error you are encountering is that the update of the result after the [/501.] is slow or irregular?

> Are there some preferences in Max which could affect this?

It never worked for me, and yes, my patch assumed (or hoped) that it

would hit every number, which it obviously doesn't. Is there a way to

make it, or some better option? I tried different inputs, did you use

> works for me... at basically any speed.  Am I correct in my understanding that the error you are encountering is that the update of the result after the [/501.] is slow or irregular?
> Are there some preferences in Max which could affect this?

It never worked for me, and yes, my patch assumed (or hoped) that it
would hit every number, which it obviously doesn't.  Is there a way to
make it, or some better option?  I tried different inputs, did you use
some different input?

I'm sorry to post again, but will this be the case with the ctlin as

well? The main problem of this patch is to get it to move through the

presets. It took forever to figure out a way to not just go from 0 to

1 over and over (I used sprintf, etc), and I arrived at this. I was

really surprised when it didn't even work with the line object.

I'm sorry to post again, but will this be the case with the ctlin as
well?  The main problem of this patch is to get it to move through the
presets.  It took forever to figure out a way to not just go from 0 to
1 over and over (I used sprintf, etc), and I arrived at this.  I was
really surprised when it didn't even work with the line object.

This patch will be double overkill, but it almost guarantees that a fast cc

controller gesture will pass a stream of numbers that does not skip any

values. This is just applying some principles of sampling theorem. To

improve resolution, Increase the sampling rate(make grain size smaller) and

bit depth (scale values up before interpolation so there are more values

between which to interpolate [making line do floating point operations

should already do this, but why risk it...])

line 0. 1 // make line interp. floats with grain of 1ms (fast!)

+ 0.5 // round float up before converting to ints

Note, If your cc inputs are skipping values greater than 10 increase the

This patch will be double overkill, but it almost guarantees that a fast cc
controller gesture will pass a stream of numbers that does not skip any
values.  This is just applying some principles of sampling theorem. To
improve resolution, Increase the sampling rate(make grain size smaller) and
bit depth (scale values up before interpolation so there are more values
between which to interpolate [making line do floating point operations
should already do this, but why risk it...])

Inlet       // inlet to subpatch
* 32000.    // scale thing up.
Pack f 10   // make list value,slewtime
line 0. 1   // make line interp. floats with grain of 1ms (fast!)
/32000.     // scale things back down
+ 0.5       //  round float up before converting to ints
Number      //  convert to int
Outlet      // outlet to main patch

Note, If your cc inputs are skipping values greater than 10 increase the
slewtime...

Yes, it's accounting for all of the steps, no matter the speed. It

will suddenly jump up a whole number, but I'm pretty sure I can figure

Yes, it's accounting for all of the steps, no matter the speed.  It
will suddenly jump up a whole number, but I'm pretty sure I can figure
that out.

Is it a trigger, counter, step rate, or number box problem?