Aside from sheer brute-force checking the patch visually, I think you can either approach solving this from a top-down, or bottom-up approach.

Top-down: make a copy of your patch and gradually delete the elements of it one by one, testing for the problem each time. Eventually (hopefully) you'll find that when you delete one particular collection of objects, the problem disappears. Then, knowing what's causing it, the solution is easier to find. I've successfully debugged irritating little problems in very complex patchers this way.

Bottom-up: Start from scratch and build the malfunctioning section of your patch seperately, manually feeding it the correct inputs. If it works fine then clearly the inputs it's getting in the main patch aren't correct.

Whichever method is best to use depends on the patch in question and it's complexity.

thanks for your suggestions. i did a sheer brute-force visual check on the patch, i didn't have time for the other approaches.

the strange thing is that the subpatch were the metro is in is very simple and there is not much influencing it from outside. i added a screenshot of the subpatch. the only thing that happens is an ineger 0 or >0 is coming from the inlet and the metro should do it's work. i'm very certain the data going into metro's and f's right inlet does not change, even not when dsp is turned on and off.

i'd have to add that the problem is more present when i use my internal sound card instead of my m-audio fasttrack pro. the cpu usage also raises also a couple of percents when using my internal sound card. this cpu usage is in both cases quite high, about 22% when the patch isn't doing anything up to 70-90 % when the patch is played.

i must admit, i'm confused by your question, but in case it helps, normally when i change timing of metro on the fly, i have trigger also send a bang right after timing is changed to restart the metro upon timing change like so, otherwise metro will wait 'til the next clock tick according to its previous timing to change its rate:

________________________________ *Never fear, Noob4Life was never here!

basically the problem is that there is a delay between putting the metro (shown in the screenshot) on and the metro actually starting.

the weird thing is that this delay gets bigger over time and when you turn DSP off and on again it returns to almost an unnoticeable amount of time but gets bigger over time again.

thanks for your suggestion but in my case it's impossible to do that.

"thanks for your suggestion but in my case it's impossible to do that."

impossible? you couldn't just change your [t f f] to [t b f f]? just curious... since it looks interesting and i'm wondering how it works also with what's outside the abstraction you've shown...

________________________________ *Never fear, Noob4Life was never here!

of course i could do that but what i mean is that it would mess up my system. it should wait until the next clock tick according to it's previous timing before changing to it's new timing. i can't imagine that could be a problem, could it?

Maybe you could use the global transport.

-A

Why d you think that could be a solution?

he's a developer, he's probably trying to lead you away from finding a flaw with metro-sans-transport that they don't want to fix. (don't argue with him or he'll tell you, 'shut this thread down, thanks for your cooperation' and maybe gregory will come in here and condescend, hehehehehe)

________________________________ *Never fear, Noob4Life was never here!*

well if that would solve the problem, i'm happy. but i don't understand how i should use the global transport for it? any suggestions?

You may also look at the [tempo] object. It allows direct tempo (bpm) control and seems perfectly suited for your needs.

I didn't look too hard at your patch, but on first glance it looked like you were trying to find a "uniform" way to accel or decelerate a metro. One way you can do this is by slaving the metro to Max's global transport and changing the tempo of the transport. Have a look at the transport help file.

If you think you have found a bug, we are always ready to look at it, despite anything raja might have to say about that.

-A

well, it's always fun to bring humor to a humorless place and people(no 'terms and conditions' upon signup and Andrew's the main reason for the deletions and new attitude, love that guy) ;) the metro behavior doesn't really happen on my comp(it waits 'til next tick to do its thang). maybe it's the CPU usage confounding it.

________________________________ *Never fear, Noob4Life was never here!

I bought a new Macbook Pro yesterday and the problems seems to be solved without any changes in the patch.

I went from a 15" 2,4Ghz 2Gb OSX 10.5.8 MBP to a 13" 2,4Ghz 4Gb OSX 10.6.4 MBP.

I don't know what part of the new computer solved the problem but I guess it is the increased memory size. Would that be a possibility?

If it would be that I had to little memory on my previous MBP the metro object shouldn't react the way it did, should it? I'm curious if I discovered an exotic, hard to reproduce bug I might walk into again when my patch needs more memory.

(thanks, dhadha, for standing up for me... amar khoob kushi, khoob bhalo)

@yns might be your OS update, too? otherwise, if you're using so many of these metros, RAM issue is possible... i think the scheduler clock function calls might deal with RAM? can i ask, what kind of processor is your new computer? i5? IntelCore2Duo?

________________________________ *Never fear, Noob4Life was never here!*

I stayed at 2,4 Ghz Duo Core

must be RAM, then. let us know if you find it again on your new comp(and how many metros you ended up using at once). interesting.

________________________________ *Never fear, Noob4Life was never here!*

I tried to use my Saffire Pro 10 I/0 a couple of days ago which is a firewire sound-card and the problem occurred again.

Most of the time I use a Fasttrack Pro (USB) and in combination with my new laptop there's no problem but when I use my firewire sound-card the problem occurs again. Which is strange since I use the same samplerate and vectorsizes.