oivindi

This seems like a classic in the forums, but I have yet to find a definitive answer: Is there a way to make the metro object change its tempo (almost) immediately upon receiving a new tempo value?

As it is now, it waits until the next "tick" before changing tempo, which is kind of long if you have a tempo of, say, 1000. Some suggested the tempo object would react immediately upon a new tempo value, but as far as I can tell, it also waits until the next value.

change-tempo-of-metro-immediately

 right after you change its speed, then it will restart with the right tempo.

If you send a bang to tempo right after you change its speed, then it will restart with the right tempo.

I tried that, but that becomes very messy when you are changing the tempo with a slider. I'd rather avoid the re-trig, but it seems that might be difficult.

sorry not to be more help but I recall that someone (?) recently posted a patch in relation to a 'bang' timing/quantizing issue, which used the delay object in a novel/unique way; kind of like a sample-and-hold effect. Maybe you could trawl the forum for that? You could use the delay object to quantize bangs from your slider+trigger.

Hi
sorry not to be more help but I recall that someone (?) recently posted a patch in relation to a 'bang' timing/quantizing issue, which used the delay object in a novel/unique way; kind of like a sample-and-hold effect. Maybe you could trawl the forum for that? You could use the delay object to quantize bangs from your slider+trigger.

If you are willing to go into the signal domain, train~ has the behavior that you search for.

to change the speed immediately you simply need to stop and restart it.

Thanks for the suggestions, Roman and mzed, but Roman - your example still means there will be an extra trigger every time the slider slides from one tempo to another (resulting in lots "extra triggers"), and mzed, you are definitely the closest to getting this to work, but it seems there are some inconsistencies, resulting in the trigger not always immediately catching on to the tempo change.

With the metro object, you are going to have either one problem or the other. You need to "debounce" the slider input in some way, which will inevitably introduce some latency.

I wrote an elaborate solution called tempo~ that is in the cnmat downloads: 

 It uses phasor~ as the timing mechanism. As jvkr says, train~ will also work.

With the metro object, you are going to have either one problem or the other.  You need to "debounce" the slider input in some way, which will inevitably introduce some latency.

I wrote an elaborate solution called tempo~ that is in the cnmat downloads: http://cnmat.berkeley.edu/downloads  It uses phasor~ as the timing mechanism.  As jvkr says, train~ will also work.


Well, this thread is nearly a decade old, but I just had this same question and wanted to share a little code in case someone comes here in the future:

the question which remains is what one wants it to do when the speed is changed from 1000 to 400, but we´re at 666 already.


very good approach.

the question which remains is what one wants it to do when the speed is changed from 1000 to 400, but we´re at 666 already.



 to buy Pet Accessories and Pet Products for your pets. We have an extensive collection of Pet supplies, which include food, clothing, health & beauty, grooming and medicine and much more at affordable price.

Pet Shop in Noida is the Best Pet shop in Noida  to buy Pet Accessories and Pet Products for your pets. We have an extensive collection of Pet supplies, which include food, clothing, health & beauty, grooming and medicine and much more at affordable price.

Thanks. Here it triggers immediately, but you could instead send the 'reset' message to clocker before changing the interval.

for an "ideal" situation you would probably average the incoming numbers in time intervals of the most recent (current?) metro speed. because the 

the user moves the slider could change(!) before even the next half step has finished.

"with the next metro bang" is the most logical implementation in the context of musical rythm, but it of course has the highest "latency". 

"immediately" is the other extreme, which causes a bang for every pixel the mouse moves.

between these two extremes there are dozens of further possibilities. :)


 for an "ideal" situation you would probably average the incoming numbers in time intervals of the most recent (current?) metro speed.  because the direction and the speed the user moves the slider could change(!) before even the next half step has finished.

"with the next metro bang" is the most logical implementation in the context of musical rythm, but it of course has the highest "latency". 
"immediately" is the other extreme, which causes a bang for every pixel the mouse moves.

between these two extremes there are dozens of further possibilities. :)


I like the solution of scaling the clock value to the incoming interval. For example, if the clock were at 500ms with next 'bang' at 1000ms and the interval is suddenly changed to 100ms, the clock would be set to 50ms. Seems like a nice compromise.

same question here. train~ is a great tip, especially since it also outputs bangs. However, contradictory to its documentation, it does NOT change tempo in between intervals, no matter how the @resetmode is set (no varmetro behaviour).

same question here.  train~ is a great tip, especially since it also outputs bangs. However, contradictory to its documentation, it does NOT change tempo in between intervals, no matter how the @resetmode is set (no varmetro behaviour).

Change tempo of metro immediately?