very strange metro behavior

Sep 8, 2010 at 10:26pm

very strange metro behavior

i have a sub-patch where an integer comes in which is either >0 or 0 that starts a metro object.
now the problem is that there is a delay between starting this object with a >0 integer and the metro to actually start.

i hooked up number boxes and bangs to everything between the metro and the source of the integers and i can clearly see that the integer is going into the metro object at the right time but it takes a variable amount of time for the metro to start (somewhere between 10 to 2000 ms). the delay gets bigger over time.

the strange thing about all this is that when i stop and start DSP the delay time goes back to almost nothing and grows over time again.

i know it’s hard to say anything without seeing a patch but the problem is part of a quite very large patch and it would take a lot of time to make this patch working without my HI and midi controllers.
i was hoping this sounds familiar to anyone or to get some tips were to search for the problem.

#52195
Sep 9, 2010 at 12:26am

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.

#187551
Sep 9, 2010 at 12:12pm

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.

[attachment=141220,1113]

Attachments:
  1. Picture_1.png
#187552
Sep 9, 2010 at 4:06pm

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:

– Pasted Max Patch, click to expand. –

________________________________
*Never fear, Noob4Life was never here!

#187553
Sep 9, 2010 at 11:31pm

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.

#187554
Sep 10, 2010 at 12:32am

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

#187555
Sep 10, 2010 at 7:06am

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?

#187556
Sep 10, 2010 at 2:29pm

Maybe you could use the global transport.

-A

#187557
Sep 11, 2010 at 10:42am

Why d you think that could be a solution?

#187558
Sep 11, 2010 at 3:58pm

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

#187559
Sep 12, 2010 at 11:11am

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?

#187560
Sep 12, 2010 at 12:30pm

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

#187561
Sep 12, 2010 at 4:03pm

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

#187562
Sep 12, 2010 at 4:44pm

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!

#187563
Sep 13, 2010 at 8:43pm

@Andrew
hmmmm… well if you must know, noob is my cousin from India staying with me for the next year or so(attending UCBerkeley on exchange program). i don’t mind your lumping us into one, Andrew(you seem prone to quick judgments characteristic of a racist ass). but just letting you know: IP addresses and Google Analytics don’t always give you the best info. upon which to judge people in real life.

feel free to ban us both, if you don’t like how we react(we might as well be the same person as far as your myopic view is concerned).

#187564
Sep 14, 2010 at 10:00am

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.

#187565
Sep 14, 2010 at 5:32pm

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

#187566
Sep 14, 2010 at 11:07pm

I stayed at 2,4 Ghz Duo Core

#187567
Sep 15, 2010 at 4:17pm

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

#187568
Sep 22, 2010 at 8:17am

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.

#187569

You must be logged in to reply to this topic.