metro problems.

Apr 4, 2010 at 7:41pm

metro problems.

im using the metro object to run a sequencer, but its not outputting correctly, i change it from say, 20-40 and at 23 itll double in speed, then at 50 or somewhere itll double again or something in that speed range. whats wrong with this. i could swear it was never doing this before.

#49536
Apr 4, 2010 at 8:06pm

what i mean is that it doesnt speed up untill a certain number each time, like it will be the same speed between 30-50

#178011
Apr 4, 2010 at 9:12pm

The second [metro] inlet sets the new time interval but it does not perform an update. You need to send a bang to the first inlet to do this.

lh

#178012
Apr 4, 2010 at 10:47pm

yeah, but then it outputs a bang out the output along with it, which makes my sequencer jump forward every time i change a number. and also, it still isnt updating.

#178013
Apr 4, 2010 at 11:01pm

Try this;

have a ‘background control’ metro which bangs at a higher rate, say ten times the rate of what you want to output, so your time resolution is increased by a factor of ten. Connect a counter to this control metro, which counts up from 0 to 9, and a sel 0 to bang on the start of every count., so it only outputs every tenth bang. This should increase the smoothness and responsiveness of the output. You could extend this approach to using msp signal objects to increase the resolution by a thousand or so.
T

#178014
Apr 4, 2010 at 11:07pm

thats not a bad idea, ive been thinking of ways to do that every once in a while. but also, this didnt do it before, im 95% sure. and i would have to increase it hugely because its like every 20-40 numbers it will do something like double the metro time output. so its really inconvenient, especially when im running a sequencer patch at 16th – 64th note resolution, the metro is between 40 and 10. so how would i use the msp objects in a metro style fashion?

#178015
Apr 4, 2010 at 11:49pm

The pre-scale metro+counter trick is a good one. I’ve successfully used it for some projects.

Also, are you driving the metro with a floating point number as the rate input? It can make a pretty big difference in smoothness when going really fast.

#178016
Apr 5, 2010 at 12:09am

im saying that the metro object isnt working correctly for some reason. itll be something like 10 ms for anything between 10-23, then itll suddenly switch to alot faster at 24 miliseconds, then stay the same all the way through to 40 miliseconds, then abruptly change way faster again.

#178017
Apr 5, 2010 at 6:32am

Hello maxer,

maybe you should post a patch to test if there is a problem on my computer too ; is overdrive on ?

#178018
Apr 5, 2010 at 7:05am

Hi
So does it work properly in metro help patch?
from metro reference – In right inlet: The number is the time interval, in milliseconds, at which metro sends out a bang. A new number in the right inlet does not take effect until the next output is sent.
Note that the update is not immediate but on the next bang – see tempo for realtime update i think

Also have at look at cpuclock help / sched_test to check and see what diff overdrive makes to timing.

Have you gone through the sequencing tutorials?

Cheers
Macciza

#178019
Apr 5, 2010 at 11:05am

The pre-scale metro+counter trick is a good one. I’ve successfully used it for some projects.

Also, are you driving the metro with a floating point number as the rate input? It can make a pretty big difference in smoothness when going really fast.

#178020

You must be logged in to reply to this topic.