cycle~ size limit

Jun 20, 2007 at 7:44pm

cycle~ size limit

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.

#32553
Jun 20, 2007 at 7:50pm

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.

#107383
Jun 20, 2007 at 7:51pm

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

#107384
Jun 20, 2007 at 7:58pm

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

#107385
Jun 20, 2007 at 8:29pm

>
> 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.

#107386
Jun 20, 2007 at 8:32pm

> 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.

#107387
Jun 20, 2007 at 8:53pm

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

#107388
Jun 21, 2007 at 8:18am

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:

#P window setfont “Sans Serif” 9.;
#P flonum 122 238 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 91 265 41 196617 *~ 0.1;
#P newex 103 105 68 196617 buffer~ x 12;
#P message 103 73 30 196617 read;
#P message 161 147 33 196617 set x;
#P user led 68 300 17 17 0 150;
#P newex 85 300 30 196617 dac~;
#P flonum 91 151 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 91 187 70 196617 cycle~ 250 x;
#P connect 4 0 0 0;
#P connect 1 0 0 0;
#P connect 0 0 7 0;
#P connect 5 0 6 0;
#P connect 6 1 4 0;
#P connect 7 0 2 0;
#P connect 7 0 2 1;
#P connect 8 0 7 1;
#P hidden connect 3 0 2 0;
#P window clipboard copycount 9;

#107389

You must be logged in to reply to this topic.