Urgent request for the programmers of MAX/MSP


    Oct 01 2006 | 8:10 am
    Tonight in the middle of a very important show at Miami Art Central Museums exhibition for "Centre Pompidou" collection my metro simply stopped and would not restart. As closing the patch at this moment would not be acceptable I was forced to drone and tried to jog it back into working by turning off the overdrive. This caused max to crash. I covered up and held together very well by restarting max while playing synths, but this tempo/metronome problem has to be fixed. I cant understand after 5 versions that this has not been addressed. Why is it that max metro and tempo will just stop after a long time, and drift out of sync or humanistically bang out of beat now and then. Im using a G5 dual 2ghz with OSX 10.3.9 and I have this problem every once and a while, and until now it was ok to have it in the studio but not in a prestigious gig. I use max/msp as a good portion of my live setup, and I would love to continue my passionate use of this awesome software, can you please fix this one very important problem with the fundimental metro+tempo objects.
    Thank you so much.

    • Oct 01 2006 | 10:03 am
      You could try to see if the tl.metro abstraction, driven by audio signal
      whenever audio is on, would work more reliable. I have received a few
      suggestions that has not made it into it so far due to my own time
      issues, but it's a fairly simple abstraction, so you can tweek whatever
      way you want to. It's part of tl.objects:
      Best,
      Trond
      Nicholas C. Raftis III wrote:
      > Tonight in the middle of a very important show at Miami Art Central Museums exhibition for "Centre Pompidou" collection my metro simply stopped and would not restart. As closing the patch at this moment would not be acceptable I was forced to drone and tried to jog it back into working by turning off the overdrive. This caused max to crash. I covered up and held together very well by restarting max while playing synths, but this tempo/metronome problem has to be fixed. I cant understand after 5 versions that this has not been addressed. Why is it that max metro and tempo will just stop after a long time, and drift out of sync or humanistically bang out of beat now and then. Im using a G5 dual 2ghz with OSX 10.3.9 and I have this problem every once and a while, and until now it was ok to have it in the studio but not in a prestigious gig. I use max/msp as a good portion of my live setup, and I would love to continue my passionate use of this awesome software, can you p!
      > lease fix this one very important problem with the fundimental metro+tempo objects.
      >
      > Thank you so much.
      >
    • Oct 01 2006 | 10:18 am
      you could also save the following abstraction (which I call
      kt_metro~, but it's up to you) and use it as an audio metro
      as metro if you provide an argument, it will be tthe metro speed,
      default is 1000
      i use it since only a short time, but it seems to work ok
      best
      kasper
      >You could try to see if the tl.metro abstraction, driven by audio
      >signal whenever audio is on, would work more reliable. I have
      >received a few suggestions that has not made it into it so far due
      >to my own time issues, but it's a fairly simple abstraction, so you
      >can tweek whatever way you want to. It's part of tl.objects:
      >
      >http://www.bek.no/~lossius/download
      >
      >Best,
      >Trond
      >
      >
      >Nicholas C. Raftis III wrote:
      >>Tonight in the middle of a very important show at Miami Art Central
      >>Museums exhibition for "Centre Pompidou" collection my metro simply
      >>stopped and would not restart. As closing the patch at this moment
      >>would not be acceptable I was forced to drone and tried to jog it
      >>back into working by turning off the overdrive. This caused max to
      >>crash. I covered up and held together very well by restarting max
      >>while playing synths, but this tempo/metronome problem has to be
      >>fixed. I cant understand after 5 versions that this has not been
      >>addressed. Why is it that max metro and tempo will just stop after
      >>a long time, and drift out of sync or humanistically bang out of
      >>beat now and then. Im using a G5 dual 2ghz with OSX 10.3.9 and I
      >>have this problem every once and a while, and until now it was ok
      >>to have it in the studio but not in a prestigious gig. I use
      >>max/msp as a good portion of my live setup, and I would love to
      >>continue my passionate use of this awesome software, can you!
      > p!
      >> lease fix this one very important problem with the fundimental
      >>metro+tempo objects.
      >>
      >>Thank you so much.
      >>
      >
      >
    • Oct 01 2006 | 12:39 pm
      hi,
      maybe its because im doing something different, or perhaps that i have xp. anywayz, the following patch works solid for me. its a clock from my sequencer. inputs/outputs are labeled, hopefully you will understand. let me know otherwise, i ll explain. you need to hava some kind of data array with note lengths, which will respond to bangs by outputting notelength in ticks (notelength=25000*note type (ie 1/1 for a note that is 1 bar long). changing the tempo will change the note durations on the fly for you. changing the direction, ie pressing reverse, will cause the clock to run backwards, while keeping in mind, how far did it get after triggering the last step (x.ticks), and taking this time (x) before triggering this step again. if yourdata array will respondf correctly to reverse mode, you will get an effect of as if you were reversing a tape. i have it all, i can send you, but not sure if will understand it...
      the timing protect patch makes sure that if current note is calculated to be 25000.2323 ticks long, the next note will 0.2323ticks longer then calculated. remember tempo changes are calculated in realtime:))
      -------------------------------------------------------------------
      max v2;
    • Oct 01 2006 | 4:17 pm
      Thank you Trond and Kasper, those phasor metronome abstractions should work. I can't believe I never thought of it. Ichyhead, your patch I don't see how it will help my situation, though it seems useful. Im missing about half the externals or abstractions.
      To re-explain in short Metro and Tempo just stop working after a while, they just stop outputting bangs. and even if I restart it sometimes it still wont work.
      I don't understand why such an essential object is fatally flawed in its inherent programming, I mean no other softwares I own just randomly stop in the middle of performance, and Max/msp is by far the coolest, is it like the amazing brains who coded this cared about making a million other objects and not fixing the most important one of all???
    • Oct 01 2006 | 5:13 pm
      On 01 Oct 2006, at 18:17, Nicholas C. Raftis III wrote:
      > I don't understand why such an essential object is fatally flawed
      > in its inherent programming, I mean no other softwares I own just
      > randomly stop in the middle of performance,
      hey, you must be a lucky man...
      > and Max/msp is by far the coolest, is it like the amazing brains
      > who coded this cared about making a million other objects and not
      > fixing the most important one of all???
      well, noone knows what you are doing to your metro, or the rest of
      the patch resp.
      so this general rant won't be of any help, just showing your
      frustration.
      e.g. a broken metro sounds like a dead scheduler.
    • Oct 01 2006 | 5:31 pm
      >> and Max/msp is by far the coolest, is it like the amazing brains
      >> who coded this cared about making a million other objects and not
      >> fixing the most important one of all???
      >well, noone knows what you are doing to your metro, or the rest of
      >the patch resp.
      >so this general rant won't be of any help, just showing your
      >frustration.
      The frustration is understandable (even if his
      assumption about amazing brains is a bit flawed),
      and - to his credit - he DID mention what kind of
      machine he's running on. He forgot to mention what
      version of Max/MSP/Jitter he's running, though.
      But you're right - without more information of a
      specific nature, it's unlikely that this will
      receive the attention the original poster evidently
      feels it deserves.
      For a listing of things that WILL help achieve the
      original poster's goals, see
    • Oct 01 2006 | 5:36 pm
      >
      >>and Max/msp is by far the coolest, is it like the amazing brains
      >>who coded this cared about making a million other objects and not
      >>fixing the most important one of all???
      >
      >well, noone knows what you are doing to your metro, or the rest of
      >the patch resp.
      >so this general rant won't be of any help, just showing your frustration.
      >
      that's true, however everybody knows than metro and in general timing
      IS a problem in max - there was a lot of discussions about it, a lot
      of explainations (it is because of the OS etc etc) however it is true
      than most (or all ?) other software i know CAN display time ok, and
      keep a steady pulse....
      and still i use max
      go figure
      all the best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Oct 01 2006 | 6:04 pm
      yeas , sorry i realize it now, i have the metro setup same as you do. however when i tested this patch it did run smooth for around 24hours without getting out of sync (the purpose of the tesdt) or stopping. i wouldnt introduce any signals into this, since conversion objects from signals to max messages (wndows) isnt solid. have you tried reseting the metronomes speed every hour or so? maybe that could help metro to stay awake.
      missing timecount? not to worry..not part of the patch. missing lobjects? how can you work in max without them??
      i
    • Oct 01 2006 | 6:40 pm
      I had these timing problems as well until I found out that Max is not the black box, 'click 'n drag 'n everything will be fine' toy I thought it was.
      Max is no more and no less than a 5th (or 4th if you want) level programming language with a huge standard library, which means
      a) you have to be aware of the way max works underneath the objects. Especially the way max uses different event-handling mechanisms to accomplish different tasks.
      b) if you are not, a lot of inexplainable things happen that have the same effect as a bug (eg "why doesn't this work, all I did was combining two working helpfiles?")
      c) you have to be a technician (as in 'geek' or 'nerd') to use max effectively
      d) Cycling '74 will never be able to promote Max like this..
      [Quote]
      Building a Better Future
      REAKTOR is also an extraordinary sonic laboratory, its modular design releasing you from the constraints of more conventional setups. The extensive library of macros and modules combined with REAKTOR's clear, uncomplicated interface turns the construction of sonic tools into an intuitive process.
      [/Quote]
      ..and luckily Cycling 74 doesn't.
      To be complete, I must add that NI has even less right to promote its product this way. Reaktor doesn't even come close to a programming environment. To make a setup that goes beyond 'the constraints of more conventional setups' is ultimately impossible in Reaktor. If anyone cares I will be happy to substantiate these claims. I used Reaktor extensively. My advise: go with the standard instruments. They are neatly worked around the shady parts of the reaktor core, a process that is impossible to complete without daily contact with a Reaktor developer.
      Mattijs
    • Oct 01 2006 | 6:52 pm
      > that's true, however everybody knows than metro and in general
      > timing IS a problem in max - there was a lot of discussions about it,
      i think there is a difference between the (known) sluggish timing of
      scheduler-based tasks and a "metro stopped working in the middle of a
      performance" report.
      > a lot of explainations (it is because of the OS etc etc)
      ??
      > however it is true than most (or all ?) other software i know CAN
      > display time ok, and keep a steady pulse....
      there are ways in max (or to be precise, in msp) to accomplish sample
      accurate timing. and these have been extensively discussed on the
      list before.
    • Oct 01 2006 | 7:12 pm
      >> that's true, however everybody knows than metro and in general timing
      >> IS a problem in max - there was a lot of discussions about it,
      > i think there is a difference between the (known) sluggish timing of
      > scheduler-based tasks and a "metro stopped working in the middle of a
      > performance" report.
      I suppose several of us have seen the problem of metro dying from time
      to time, some more often than others. I know Tim had some serious
      problems on one computer while another computer worked fine awhile back.
      To the best of my knowledge I don't think anyone have been able to nail
      it and present the kind of reproducible situation required in order to
      track down and solve the problems once and for all. Personally I have
      seldom been struggling with this problem, but it has happened a few
      times over the past 3 years.
      Best,
      Trond
    • Oct 01 2006 | 7:42 pm
      [[ it slices. it dices. but it can't tell time. ]]
      I've definitely finished complicated drum patches, hit play and
      wondered why I wrote it. Because even normal metro events don't
      "feel" very stable. when I say "feel" I mean the minute timing that
      makes a drummer good. I've gone in with protools and used beat
      detective. I mean we are making MUSIC right?
      Is there a way to sync the scheduler with metro or vice versa? that
      might do the trick.
      I know the following is not pragmatic, but I always felt like max
      signals should just be adjustable rate. I think Gregory Taylor said
      something about PD doing this? Audio would just be a list of floats
      for each vector. And jitter would just be symbols that say
      jit_matrix u142000077. in a perfect world we could just option
      click out patch cables and set the resolution. that way we could use
      all the Max objects we wish we had in MSP and Jitter. Even something
      like compressed MP3-ish variable bit rate signals would help for
      simple audio signals.
      because why should I use a 44.1kHz 24bit signal for my program's
      metronome?
      pipe dreams. this is what I wonder about.. I need a life.
    • Oct 01 2006 | 7:42 pm
      > Personally I have seldom been struggling with this problem, but it
      > has happened a few times over the past 3 years.
      aha, ok. (fortunately) never happend to me either.
      volker.
    • Oct 01 2006 | 9:26 pm
      Hi Mattijs,
      could you elaborate on this (I don't follow your "combine two working
      helpfiles" example):
      > a) you have to be aware of the way max works underneath
      > the objects. Especially the way max uses different event-
      > handling mechanisms to accomplish different tasks.
      > b) if you are not, a lot of inexplainable things happen
      > that have the same effect as a bug (eg "why doesn't this
      > work, all I did was combining two working helpfiles?")
      Thanks,
      Brian
    • Oct 01 2006 | 9:47 pm
      sory if i am missing out on some major and well known max insides, but isnt the cpuclock object precise enough for testing timing, max patches for cpu efficiency, etc.? since it ouputs numbers generated by the processor, max's scheduler should have no influence on the output of timecount. am i horibly wrong?
      timecunt:
      -----------
      max v2;
      ----
    • Oct 02 2006 | 5:10 pm
      If anyone would care to try a sample-accurate metronome in UB format, you can find it at this URL:
      I'll also attach it here.
      Eric
    • Oct 02 2006 | 5:25 pm
      >If anyone would care to try a sample-accurate metronome in UB format,
      means it won't work on mac PPC, max 457 ???
      thanks
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Oct 02 2006 | 6:01 pm
      > means it won't work on mac PPC, max 457 ???
      Dunno. It should be fine on both PPC or Intel, but I only tested it on Mintel hardware. If it doesn't work on your machine, let me know and I could try going native :)
    • Oct 02 2006 | 6:01 pm
      XP max has a horrible bug where holding down the mouse button inside an object box which is in text entry mode will cause the cpu to spike to 100%, making timing even crummier :/
      You know Chuck? I love it's title, I almost feel like it's an antithesis of an unspoken issue with Max and timing.
      "Strongly-timed, Concurrent, and On-the-fly "
      Strongly timed! I really think that should be the core of Max. It does so much stuff, yet it's so easy to wrack hell onto the scheduler with just basic patching or user input. Oh well!! I'll still use it =)
    • Oct 02 2006 | 6:16 pm
      > > means it won't work on mac PPC, max 457 ???
      >
      >Dunno. It should be fine on both PPC or Intel, but I only tested it
      >on Mintel hardware. If it doesn't work on your machine, let me know
      >and I could try going native :)
      i belive it does not work
      when I launch the help patcher, the el.samm~ object appears made
      with dotted lines (as when an object is not found) - however no error
      messages in max window (as it should be)
      and of course el.samm~ is where all other 3rd party externals are, so
      this is not the problem
      turning audio, and trying does not produce anything (any effect)
      I tried changing the name to el.samm~ (without .mxo) - does not change anything
      I use aG4 pbook 1.5, osX 4 7, max 4 5 7
      thanks
      best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Oct 02 2006 | 6:18 pm
      Hi!
      I have had a couple of strange crashes lately, the latest one five
      minutes ago when hitting command + z buttons.
      Have attached an crash repport.
      MacOsX.4.7 ,Max/msp 4.6.1 ,jitter 1.6.1, MacBook Pro 2.0ghz 1gig ram.
      /mattias
    • Oct 02 2006 | 7:40 pm
      >
      > i belive it does not work
      >
      > when I launch the help patcher, the el.samm~ object appears made
      > with dotted lines (as when an object is not found) - however no error
      > messages in max window (as it should be)
      >
      > and of course el.samm~ is where all other 3rd party externals are, so
      > this is not the problem
      >
      I don't know enough about architecture compatibility then. I was under the impression that an external compiled for "Deployment" should work for both intel and PPC architectures. Maybe a more savvy developer can clue me in on what I might be doing wrong. I notice that I am getting the following compile warning messages, though not sure if they are dangerous:
      /usr/bin/ld: warning multiple definitions of symbol _MachOFunctionPointerForCFMFunctionPointer
      /usr/bin/ld: warning multiple definitions of symbol _CFMFunctionPointerForMachOFunctionPointer
      /usr/bin/ld: warning multiple definitions of symbol _aTemplate
      I'm going to attach a PPC binary from the caveperson days of CodeWarrior. This may not be as up to date as the UB I posted but hopefully still has core functionality.
      Eric
    • Oct 02 2006 | 7:51 pm
      You should double-check that, in the target inspector, under
      "Deployment" build style, it's set for PPC and i386. Clicking on the
      "Edit" button for that setting will allow you to check off both. I've
      occassionally noticed some weirdness with settings not "sticking" in
      XCode, so it's worth a 2nd look.
      jb
      Am 02.10.2006 um 21:40 schrieb Eric Lyon:
      > I was under the impression that an external compiled for
      > "Deployment" should work for both intel and PPC architectures
    • Oct 02 2006 | 8:09 pm
      On Oct 1, 2006, at 9:17 AM, Nicholas C. Raftis III wrote:
      >
      > I don't understand why such an essential object is fatally flawed
      > in its inherent programming, I mean no other softwares I own just
      > randomly stop in the middle of performance, and Max/msp is by far
      > the coolest, is it like the amazing brains who coded this cared
      > about making a million other objects and not fixing the most
      > important one of all???
      Please note that a long time problem with the scheduler and
      multiprocessor machines was solved in 4.6.2. This might be related to
      your and other user's issues with scheduler death. Only recently were
      we provided with clear user examples of this problem which were
      sufficient to track down the problem.
      However, please also note that you essentially provided us no
      information in your report to investigate or assist with. Please see
      the bug reporting guidelines oft posted to the list at bottom. You
      might also take a look at Simon Tatham's article, How To Report Bugs
      -Joshua
      BUG REPORTING GUIDELINES
      Please report any problems you experience with clear and complete
      information, including steps to reproduce, software and system
      information, and where possible, an isolated example patch and crash
      log. Something like the following would be ideal. This makes it
      easier for us to find and fix the problems you experience. Without
      such clear and complete information, it is less likely we will be
      able to.
      Summary:
      Provide a descriptive summary of the issue.
      Steps to Reproduce:
      In numbered format, detail the exact steps taken to produce the bug.
      Expected Results:
      Describe what you expected to happen when you executed the steps above.
      Actual Results:
      Please explain what actually occurred when steps above are executed.
      Regression:
      Describe circumstances where the problem occurs or does not occur,
      such as software versions and/or hardware configurations.
      Notes:
      Provide additional information, such as references to related
      problems, workarounds and relevant attachments.
    • Oct 02 2006 | 8:13 pm
      > You should double-check that, in the target inspector, under
      > "Deployment" build style, it's set for PPC and i386. Clicking on the
      > "Edit" button for that setting will allow you to check off both. I've
      > occassionally noticed some weirdness with settings not "sticking" in
      > XCode, so it's worth a 2nd look.
      >
      Thanks, Jeremy.
      I checked, and both ppc and i386 architectures are specified. I'm going to attach the most recent build on the off chance that the other one somehow was compiled intel-only. Kaspar, perhaps you could check this binary too? Thanks.
      Eric
    • Oct 02 2006 | 8:46 pm
      vade$ lipo -info el.samm~
      Architectures in the fat file: el.samm~ are: ppc i386
      looks like both here, with that last archive you sent.
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Oct 2, 2006, at 4:13 PM, Eric Lyon wrote:
      >> You should double-check that, in the target inspector, under
      >> "Deployment" build style, it's set for PPC and i386. Clicking on the
      >> "Edit" button for that setting will allow you to check off both. I've
      >> occassionally noticed some weirdness with settings not "sticking" in
      >> XCode, so it's worth a 2nd look.
      >>
      >
      > Thanks, Jeremy.
      >
      > I checked, and both ppc and i386 architectures are specified. I'm
      > going to attach the most recent build on the off chance that the
      > other one somehow was compiled intel-only. Kaspar, perhaps you
      > could check this binary too? Thanks.
      >
      > Eric
      >
      >
    • Oct 02 2006 | 9:02 pm
      Am 02.10.2006 um 22:13 schrieb Eric Lyon:
      > I checked, and both ppc and i386 architectures are specified. I'm
      > going to attach the most recent build on the off chance that the other
      > one somehow was compiled intel-only. Kaspar, perhaps you could check
      > this binary too? Thanks.
      Hello Eric,
      I just tried on my ibook running 10.3.9 and it doesn't work with 4.5.7
      (no error, dotted lines), but it works fine with 4.6.2! And it looks
      very useful.
      cheers, g.
    • Oct 02 2006 | 9:16 pm
      I thought it had to be a CFM external to work in 4.5.7. Is this not
      the problem?
      wes
      On 10/2/06, Georg Bosch wrote:
      >
      > Am 02.10.2006 um 22:13 schrieb Eric Lyon:
      > > I checked, and both ppc and i386 architectures are specified. I'm
      > > going to attach the most recent build on the off chance that the other
      > > one somehow was compiled intel-only. Kaspar, perhaps you could check
      > > this binary too? Thanks.
      >
      > Hello Eric,
      >
      > I just tried on my ibook running 10.3.9 and it doesn't work with 4.5.7
      > (no error, dotted lines), but it works fine with 4.6.2! And it looks
      > very useful.
      >
      > cheers, g.
      >
      >
    • Oct 02 2006 | 9:16 pm
      >
      > I just tried on my ibook running 10.3.9 and it doesn't work with 4.5.7
      > (no error, dotted lines), but it works fine with 4.6.2! And it looks
      > very useful.
      >
      Thanks for the feedback, and also to vade for the nifty utility.
      Eric
    • Oct 02 2006 | 10:21 pm
      >Kaspar, perhaps you could check this binary too?
      when installing it in my externals, still nothing happens (when i
      launch the help file) - the object is still "not found" (but wthout
      such a message in the max window)
      however if i re-type the name (not changing any of the attributes
      ->same text) , the object becomes "real" but with NO in-out/lets
      best
      kasper
      --
      Kasper T. Toeplitz
      noise, composition, bass, computer
    • Oct 03 2006 | 5:41 am
      Nicholas C. Raftis III wrote:
      > I don't understand why such an essential object is fatally flawed in
      > its inherent programming, I mean no other softwares I own just
      > randomly stop in the middle of performance, and Max/msp is by far the
      > coolest, is it like the amazing brains who coded this cared about
      > making a million other objects and not fixing the most important one
      > of all??? -- ~* www.Axiom-Crux.net *~
      As far as I know such a problem was discussed some time ago and cycling
      was very concerned about it. As you did not deliver too much information
      about your setup, beside OS 10.3.9 and a dual G5, its hard to track it
      down. To find something like that you need to be able to reproduce it...
      If you send the whole patch to the support, they might even setup a
      machine to let it run. But there won't be any garanty that the problem
      will show up there.
      The replacement with an audio based metro seems the most robust solution
      for this hard to show up bug. And with any bug you don't know if its
      inside the external, inside the Max application or just inside your
      patch... You'l only be able to tell if you found the source for the
      problem, till then you need to assume it could be any of the three...
      I can't tell you how often I wanted to blame externals or Max and
      finally I created it myself... ;-)
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Oct 03 2006 | 1:29 pm
      Apparently you need to upgrade to version 4.6.1 or later in order use my (and other 3rd party?) UB externals. I'm afraid I can't pursue this further since the problem, whatever it is, appears to be solved in more recent versions of MaxMSP. Hopefully you can safely upgrade.
      Best,
      Eric
    • Oct 03 2006 | 2:33 pm
      if you want to have a PPC CFM version, I can compile it for you. Let me know.
      wes
      On 10/3/06, Eric Lyon wrote:
      >
      > Apparently you need to upgrade to version 4.6.1 or later in order use my (and other 3rd party?) UB externals. I'm afraid I can't pursue this further since the problem, whatever it is, appears to be solved in more recent versions of MaxMSP. Hopefully you can safely upgrade.
      >
      > Best,
      >
      > Eric
      >
      >
    • Oct 03 2006 | 2:50 pm
      Quote: wesley.hoke@gmail.com wrote on Tue, 03 October 2006 15:33
      ----------------------------------------------------
      > if you want to have a PPC CFM version, I can compile it for you. Let me know.
      >
      >
      Thanks for the offer. I did post one above. Anyway, this is just a prerelease. I hope to have a better solution to these kinds of problems when I officially release samm~ and all of its related objects, most likely some time after the ICMC in November.
      Eric
    • Oct 03 2006 | 8:06 pm
      Quote: Brian E Willkie wrote on Sun, 01 October 2006 23:26
      ----------------------------------------------------
      > Hi Mattijs,
      >
      > could you elaborate on this (I don't follow your "combine two working
      > helpfiles" example):
      Sure. Let's say you want to make a video mixer that displays the last frame of the movie you select. Let's say you want to output all video data in sync with the main metro (could be any reason, eg to combine the last frame and the current frame in an extrusion-like 3D effect) so you construct the patch below.
      Look at the [t l 1] below the ubumenu. I could easily imagine a new user to believe: "First the gate opens, immediately after that the file gets loaded and the framecount retrieved, then the metro comes and bangs out the frame. That should work fine." Still when you put this patch in overdrive, it won't display the correct frame.
      Cheers,
      Mattijs