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


    Jun 02 2006 | 8:36 pm
    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.
    Thanks, Keith

    • Jun 03 2006 | 7:43 am
      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?
    • Jun 03 2006 | 12:33 pm
      Hi,
      Yes, I can confirm that problem, same here. grmpf.. Also wanted to use that with a controller....
      marlon
    • Jun 03 2006 | 12:51 pm
      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?
      jb
      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 > would be great.
    • Jun 03 2006 | 1:28 pm
      Hi,
      no, what I was aiming at was more sth. like this (with lists) and it seems to work smoothly.
      cheers. m
    • Jun 03 2006 | 1:50 pm
      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.
      jb
    • Jun 03 2006 | 2:09 pm
      Nothing, Jeremy...
      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. ;-)
      marlon
    • Jun 03 2006 | 5:15 pm
      > 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?
      Keith
    • Jun 03 2006 | 5:26 pm
      Jeremy-
      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.
      Thanks, Keith
    • Jun 03 2006 | 6:09 pm
      Keith.
      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...])
      Try connecting these in order.
      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...
      -lcc
    • Jun 03 2006 | 11:02 pm
      Yes. Does my patch do what you want?
      jb
    • Jun 04 2006 | 4:58 am
      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.
      Thanks, Keith