Modulating Metro time interval with Cycle
Hi,
I am trying to modulate the rate of a metro with a cycle (sine wave) and it doesn't change the tempo like it does with number msg as the input. Ideally, I'd like to multiply a cycle~ with a number message and feed that into the metro rate to speed up and slow down the tempo. How do i convert a cycle signal to something metro can understand. Attached is my attempt. Thank you.
cycle~ output is signal that cycles between -1. and 1.
metro accepts only positive interval in ms.
you need something that ramps only positive,
and has non signal output, but metro is anyway
a bad choice for what you want.
rather use edge detecting on signal ramp
to make bangs, instead of using metro.
take a look at phasor~ help file.
I agree with Source Audio, but if you still want to use the cycle~ object to control metro, you can use scale~ to convert the -1 to 1 cycle output to positive values that represent the tempo range in ms:
scale~ -1. 1. 250 2000
Then use snapshot~ to convert the signal to number for input to metro.
You need to keep the cycle~ freq very low in decimals.
I would also welcome any input on my solution.
Thanks that direction - That helped a lot. I'm now detecting the edge of the phasor to trigger bangs - However, to oscillate the phasor tempo, I'm using a feedback loop two line msgs triggering each other via their end-of-ramp outlets. Is there a more elegant way to do this than the feedback rig I've routed? Attached is the updated patch.
Here is one way:
try this to replace that 2 line objects:
cycle~ can use buffer for waveform, see buffer help file under functions.
you can try different shapes, but keep it 0. 1.
edge~ and snapshot~ based solutions do have the same issue, both dont give you very accurate timing.
phasor to egde, however, is probably the most straight forward way how to instantly archive what you want.
for even less accuracy try a data LFO based on line and cos.
"for even less accuracy"
Can we make this a thing? Is it possible to get the inaccuracy to such a degree where it becomes musically (who am i kidding? sonically!) interesting? I think that's worth the experiment!
It somewhat reminds me of the quote by Picasso on how it took him two years to paint like Degas(?) but a lifetime to draw like a 4-year old...
everything can be a feature if you want it to, even my various wrong answers in this forum.
but i am afraid that jitter is the last form of inaccuracy you want to have in music related signals.
the idea was more... that it might be that it still does not matter much for some application, so the OP could go and try it out and compare it against other methods.
signal vectors and even samples are not ideal, too; they also offer you a limited time resolution and sometimes latency. so why not use max objects?
and the general advice "dont mix signal rate and data rate when it can be avoided" is still valid.
this patch still lacks proper scaling of the LFO, if you do it to BPM instead of ms - or convert it to rate - it should be right.
nope, rate you´d need. bpm is also linear.
I voted against metro because it does not change speed on the fly.
same thing with line.
yeah that is a common problem you always run into with this kind of stuff. :/
but even with signals you can only change speed every sample or every vector, isnt it? it is all only pseudo-continious anyway.
to be honest i assumed that not audio input but rather the mouse or a midi controller will be the source here for modulating the LFO speed - and for that using a line with 10 ms grain should be fine.
of course you would have to build something around the line object above to make it possible to change its speed without restarting.
and a grain size of 1 ms would be about as exact as snapshot at vs 32 / 44khz. (huh, what a lame argument for my version. no, do not do this. :) )
when you do not want to modulate the speed and the amount at all, you could precacluate the times of the triggers you want to produce. there is an old custom metro patch of mine based on del somewhere here in the forum)
if the waveform of the LFO is a tri and not a sine, you almost only need + and % for that.