How to sync two Metros gradually
Hey Everyone,
I hope you are all doing well?
I'm a bit stuck with a pretty basic task. (I tried to work it out with euclidian rhythms but didn't reach a smooth result, so far). Since I've tackled around that topic for a couple of hours with no satisfying result I thought you guys might have a smart solution / concept for the following problem:
For an upcoming interactive installation I have to sync one BPM pulse to a constant target pulse gradually. For example I have a static metro clock of 120BPM and I need to sync a second metro with a random initial value (of let's say 50BPM) as it slides up to 120BPM or, if the initial second value was > 120BPM, as it slides down towards the desired target 120BPM. As soon as I reach exactly 120BPM both metros should pulse be completely in sync (with no offset).
I know that something like this might achieved somehow with [transport] but since it has to work indepently from my global Ableton transport BPM I think this solution needs another work around.
Maybe I'm just "max-patch-cable-spaghetti-blind" and someone of you has a smart idea how to achieve that. Thanks in advance and have a great weekend.
Greetings from Berlin,
Christian
EDIT:
as always, while writing the previous post and re-conceptionalizing the problem I found a msp based solution that should do the trick so far.
I got the idea from a different blog reply by John Cassidy.
Thanks a lot John.
Best
Christian
Perhaps something like this would work
Hey Kyle,
thanks so much for your response.. in theory your solution works perfect. The only problem is, as soon as I re-adjust the tempo again, after your line slide, both metros are again out of sync.
I think the only way to stay in sync is to have something like a global ramp, that keeps track of the timing:
You're welcome :) ah I see, how about something like this where the second metro's time works as a multiple of the master's
Hey Kyle,
Nice, that is an elegant solution, indeed!
Thanks so much.
EDIT: I played around with your patch. Unfortunately the two metros still get out of sync when play around with the Multiple input. (I think especially when I'm below 1 and go back to 1.). Anyway, thanks again for your support. For now I'm going to go with phasor~. It just seams the most solid way.
resyncing after a ramp usually requires to precacluate the ramp time based on the moment when it starts and the two metros.
to make it easier i would delay the ramp start to the next metro bang.
Hey Roman,
thanks for your feedback. Nice to talk to you again in the forum. :-)
Sure it makes sense to dealt the ramp start in that case.
But don't you think phase~ -> rate~ might be the easier way?
I played around with my proposed rate– solution this morning and I am quite happy with the result:
The only downside is, that the "fluid Bpm" input value sometimes takes a while (eg. a tick) until it phases correctly according to its bpm length.
best c.
within the signal domain things like that are for sure much easier to build .
but when data rate is your final aim, imho it is not ideal.
(how does your patch work? where is the ramp?)
(oh, i am on 8.1 and your comment boxes are empty.)