Sethares

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

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!

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 

error-xno-such-object-and-workaround

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 

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 

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 

3. Just for fun, try opening the top level patcher. If that explodes, 

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 

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 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)

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.

Chris Muir
cbm@well.com	
http://www.xfade.com

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 

Could you post a patch example (or just part of a patch which 

> 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

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

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

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.

_________________________________________

> 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


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.

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... 

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