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: