very strange metro behavior

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!*