very strange metro behavior

    Sep 08 2010 | 10:26 pm
    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.

    • Sep 09 2010 | 12:26 am
      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.
    • Sep 09 2010 | 12:12 pm
      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.
    • Sep 09 2010 | 4:06 pm
      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!
    • Sep 09 2010 | 11:31 pm
      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.
    • Sep 10 2010 | 12:32 am
      "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!
    • Sep 10 2010 | 7:06 am
      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?
    • Sep 10 2010 | 2:29 pm
      Maybe you could use the global transport.
    • Sep 11 2010 | 10:42 am
      Why d you think that could be a solution?
    • Sep 11 2010 | 3:58 pm
      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!*
    • Sep 12 2010 | 11:11 am
      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?
    • Sep 12 2010 | 12:30 pm
      You may also look at the [tempo] object. It allows direct tempo (bpm) control and seems perfectly suited for your needs.
    • Sep 12 2010 | 4:03 pm
      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.
    • Sep 12 2010 | 4:44 pm
      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!
    • Sep 14 2010 | 10:00 am
      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.
    • Sep 14 2010 | 5:32 pm
      (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!*
    • Sep 14 2010 | 11:07 pm
      I stayed at 2,4 Ghz Duo Core
    • Sep 15 2010 | 4:17 pm
      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!*
    • Sep 22 2010 | 8:17 am
      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.