cycle~ size limit


    Jun 20 2007 | 7:44 pm
    what is the best approach to have a [cycle~] which allows the use of more than 512 samples? (i need 1000)
    i am looking for a way to loop inside a wavetable while allowing to set the speed using a signal.
    with [counter~] and [index~] it is a bit complicated to set the speed for oscillator tuning, and as we know groove does not accept signals.
    cycle~ would be almost perfect, it is just too short.
    this is max 4.1 and without third party objects if possible.

    • Jun 20 2007 | 7:50 pm
      i may add a second question: how do you load new files into a buffer while a cycle is playing from it?
      until now i was putting the cycle into a poly~ and turn it off and on again after i update the buffer content. there must be an easier was.
    • Jun 20 2007 | 7:51 pm
      On 20 juin 07, at 21:44, Roman Thilenius wrote:
      > what is the best approach to have a [cycle~] which allows the use
      > of more than 512 samples? (i need 1000)
      >
      > i am looking for a way to loop inside a wavetable while allowing to
      > set the speed using a signal.
      >
      > with [counter~] and [index~] it is a bit complicated to set the
      > speed for oscillator tuning, and as we know groove does not accept
      > signals.
      >
      > cycle~ would be almost perfect, it is just too short.
      What about [wave~]?
      ej
    • Jun 20 2007 | 7:58 pm
      On 20 juin 07, at 21:50, Roman Thilenius wrote:
      > i may add a second question: how do you load new files into a
      > buffer while a cycle is playing from it?
      >
      > until now i was putting the cycle into a poly~ and turn it off and
      > on again after i update the buffer content. there must be an easier
      > was.
      How about sending the set message? ;-)
      ej
    • Jun 20 2007 | 8:29 pm
      >
      > How about sending the set message? ;-)
      yeah, no, it works in all situaiton but not when a running cycle reads from a buffer.
      the new buffer is written from load, but cycle still reads from the old (physically) buffer.
      if you have luck they even play both, the old and the new version.
      :/
      wave~ .. yes true, though i am not really happy with the way it takes start and end points, especially because its ms and not samples.
    • Jun 20 2007 | 8:32 pm
      > wave~ .. yes true, though i am not really happy with the way it takes start and end points, especially because its ms and not samples.
      ----------------------------------------------------
      oh it also takes signals too! see, thats why i didnt use it bf.
    • Jun 20 2007 | 8:53 pm
      On 20 juin 07, at 22:29, Roman Thilenius wrote:
      > yeah, no, it works in all situaiton but not when a running cycle
      > reads from a buffer.
      > the new buffer is written from load, but cycle still reads from the
      > old (physically) buffer.
      > if you have luck they even play both, the old and the new version.
      > :/
      I'd suggest your using 2 buffers and switch from one to the other
      when file reading operation is done.
      ej
    • Jun 21 2007 | 8:18 am
      On 20 Jun 2007, at 22:29, Roman Thilenius wrote:
      >>
      >> How about sending the set message? ;-)
      >
      >
      > yeah, no, it works in all situaiton but not when a running cycle
      > reads from a buffer.
      > the new buffer is written from load, but cycle still reads from the
      > old (physically) buffer.
      > if you have luck they even play both, the old and the new version.
      maybe i get you wrong, but this works just fine: