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
    max v2;

    • 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