mjhaanstra

below is a simple patch to cross-fade or cut between two stereo

playback subpatches (left out to reduce email size).

if i type a value in the metro object speed box, say 64, then the

rhythm becomes very uneven. is this a fault inherent of my patch

design, or is metro unstable, or could it be to much for my computer?

i'm playing back two 10 minute stereo soundfiles using sfplay objects,

on a 1ghz g4 powerbook with 512 mb of ram.

could someone offer a suggestion why my "chopping" patch can't keep a

below is a simple patch to cross-fade or cut between two stereo
playback subpatches (left out to reduce email size).

if i type a value in the metro object speed box, say 64, then the
rhythm becomes very uneven. is this a fault inherent of my patch
design, or is metro unstable, or could it be to much for my computer?
i'm playing back two 10 minute stereo soundfiles using sfplay objects,
on a 1ghz g4 powerbook with 512 mb of ram.

could someone offer a suggestion why my "chopping" patch can't keep a
tight rhythm?

metro-having-trouble-keeping-up-with-the-beat

yes, overdrive is and was on, but my metro's are still terribly out of

tempo. i'll try using square wave audio instead as control signals,

yes, overdrive is and was on, but my metro's are still terribly out of
tempo. i'll try using square wave audio instead as control signals,
thank you for the hint!

particularly powerful when used alongside

I think you might be better served to
look at using the phasor~ object for
tighter timing - not least because it's
particularly powerful when used alongside
the rate~ object to produce multiple 
subdivisions of a single clock.

The examples folder has some resources
for audio-rate sequencing you may find
of use.


You could check out tl.metro to see if that helps from the tl.objects:

It is driven by phasor~ whenever audio is running.

metro having trouble keeping up with the beat