error #X:no such object and workaround…
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!
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
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
I’m sure that there’s a lot that I’m forgetting, but this might help
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.
> 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.
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.
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.