error #X:no such object and workaround...


    Apr 30 2008 | 1:51 am
    Hi All,
    I'm in the process of moving a fairly large Max/MSP project from 4 to 5 and when I open it up, there are a large number of
    #X:no such object
    errors listed in the Max window. Worse, the "inspector" and "show object" buttons are geyed out, so there's no way to find out what object is giving the error. Mysteriously, the patch seems to function OK.
    Eventually, I traced the problem to a set of three objects:
    message open -> pcontrol -> message filename
    The work around is to replace the three objects by retyping them in Max 5. Then the errors go away. I don't know what this means, but I'm happy the errors are gone!
    --Bill Sethares

    • Apr 30 2008 | 2:34 am
      On Apr 29, 2008, at 6:51 PM, Bill Sethares wrote: > I'm in the process of moving a fairly large Max/MSP project from 4 > to 5...
      I've been wrestling with this sort of question for a few months now, and while I don't have any concrete answers, I can describe the sorts of approach I've been taking. Here's a list of guidelines that I'm using:
      1. I've found it best to not have any search paths in common between Max4 and Max5. This is not as much of an issue as it used to be, but I've kept it like this, anyway.
      2. Duplicate some project you'd like to convert from the Max4 world into the Max5 world. You might be better off starting small, and working up to larger projects.
      3. Just for fun, try opening the top level patcher. If that explodes, goto step #5
      4. Start tracking down any errors in the Max window. In the case of missing 3rd party externals, I recommend downloading new copies. Max5 is pickier about the presence of a PkgInfo file inside an external, and this might have been added to your favorite externals by now.
      5. Start opening Max4.pat abstractions, and saving them as Max5.maxpat files, keeping in mind that this is a one-way street. (optionally taking advantage of new features in the process. In particular, presentation mode has allowed me to make some messy abstractions used as bpatchers much cleaner)
      Test the converted abstractions as you go.
      6. After you convert & test all your abstractions, try opening the top level again. It probably won't explode now.
      7. On one giant patch I use, I'm still struggling with some very hard to nail down issues with initialization. Don't expect loadbangs to be issued in the same order as they were in Max4. On the large patch I'm speaking of, this was a black art in Max4, too. It took me a long time to get everything tuned there, so that it loaded reliably in a proper starting state.
      I'm sure that there's a lot that I'm forgetting, but this might help you anyway.
      -C
      Chris Muir cbm@well.com http://www.xfade.com
    • Apr 30 2008 | 7:38 am
      On 30 avr. 08, at 03:51, Bill Sethares wrote:
      > The work around is to replace the three objects by retyping them in > Max 5. Then the errors go away. I don't know what this means, but > I'm happy the errors are gone!
      Could you post a patch example (or just part of a patch which demonstrate the issue)? Thanks.
      ej
    • Apr 30 2008 | 2:01 pm
      > 7. On one giant patch I use, I'm still struggling with some very hard > to nail down issues with initialization. Don't expect loadbangs to be > issued in the same order as they were in Max4. On the large patch I'm > speaking of, this was a black art in Max4, too. It took me a long time > to get everything tuned there, so that it loaded reliably in a proper > starting state. Hi Chris, Still on Max 4, as I don't have time now to do the large number of GUI modifications on my big patches, but I have also been sometimes struggling with the loadbang issue, tuning delays to make it work. I also make use of send /receives with a global init message triggered by a loadbang followed by a delay. But sometimes it works on one machine and not on another... Even leading to Max crashes when loading the patch in some cases. What got me even more puzzled (but it may be a different issue) is that I had strangely sometimes load crashes if the sound driver was not set correctly (like none) and no crashes when the correct driver was chosen, even though the DSP is not turned on automatically upon loading the patch.
      When a patch is quite large, with a lot of subpatches and bpatchers, how is loadbang exactly supposed to work? I was also wondering if there was a hidden Max message that could be used to receive, say a bang, when all patches, subpatches and bpatchers have been loaded? Like a bang when coll has finished reading a data file.
      Best, Todor _________________________________________ Web: http://www.compositeurs.be/Todoroff.html
    • Apr 30 2008 | 4:24 pm
      Hi Emmanuel,
      I was not able to reproduce it just using Max 5, and I had never seen it before in Max 4, so I'm pretty sure it was some kind of odd interaction between old style .pat files and the new pcontrol command, or else between the new .maxpat files and the old pcontrol...
      Unfortunately, (or rather, fortunately for my patchers) the error has gone away now that I have updated all the called files to .maxpats and all of the pcontrols by retyping them... sorry I can't be more explicit.
      --Bill
    • Apr 30 2008 | 9:31 pm