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:))
      -------------------------------------------------------------------
    • 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 http://www.sleazeArt.com
    • 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: -----------
      ----
    • 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 http://www.sleazeArt.com
    • 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 http://www.sleazeArt.com
    • 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 Effectively, http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.
      -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 http://www.sleazeArt.com
    • 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