Cycling 74 » Topic: metro problems.

metro problems.

Ameqc — Sun, 04 Apr 2010 19:41:50 +0000

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.

Re: metro problems.

Ameqc — Sun, 04 Apr 2010 20:06:00 +0000

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

Re: metro problems.

Luke Hall — Sun, 04 Apr 2010 21:12:30 +0000

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.

Re: metro problems.

Ameqc — Sun, 04 Apr 2010 22:47:12 +0000

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.

Re: metro problems.

Floating Point — Sun, 04 Apr 2010 23:01:05 +0000

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

Re: metro problems.

Ameqc — Sun, 04 Apr 2010 23:07:29 +0000

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?

Re: metro problems.

Chris Muir — Sun, 04 Apr 2010 23:49:30 +0000

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.

Re: metro problems.

Ameqc — Mon, 05 Apr 2010 00:09:34 +0000

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.

Re: metro problems.

nicolas danet — Mon, 05 Apr 2010 06:32:59 +0000

Hello maxer,

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

Re: metro problems.

Macciza — Mon, 05 Apr 2010 07:05:27 +0000

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

Re: metro problems.

Chris Muir — Mon, 05 Apr 2010 11:05:08 +0000

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.