Forums > MaxMSP

4.6 working but 4.5 stopped working now

September 20, 2006 | 12:10 am

Hi

I’ve been using the max/msp 4.6 beta and max/msp 4.5 at the same time
on my Intel mac with no trouble. Where I have to use my old
externals, I’ve been able to run them with max/msp 4.5.
I’ve now installed the release version of max/msp 4.6 and the updated
jitter and I notice that I can’t run some of the old patches in 4.5
any more- the application just crashes when I open the patch. Could
the install of 4.6 have made a change to my 4.5 installation somehow?

Thanks for any ideas.

Alastair

___________________________________________
Alastair Weakley
Creativity & Cognition Studios
Faculty of IT
University of Technology, Sydney
Australia


September 20, 2006 | 12:44 am

On Sep 19, 2006, at 5:10 PM, Alastair Weakley wrote:

> I’ve been using the max/msp 4.6 beta and max/msp 4.5 at the same
> time on my Intel mac with no trouble. Where I have to use my old
> externals, I’ve been able to run them with max/msp 4.5.
> I’ve now installed the release version of max/msp 4.6 and the
> updated jitter and I notice that I can’t run some of the old
> patches in 4.5 any more- the application just crashes when I open
> the patch. Could the install of 4.6 have made a change to my 4.5
> installation somehow?

If you’re crashing at launch, it is often an mxj issue, with
mismatched max.jar and mxj object instances, as Jitter loads Jitter
Java support at launch by default.

First steps:

1. Try trashing your preferences

2. Make sure that you don’t have the Max 4.6 folders in your file
preferecnes for 4.5

3. Make sure you don’t have any standalones in your search path which
contain old versions of max.jar

4. Manually disable Jitter java loading by putting a file named
jitter-config.txt in your search path containing the text "jitter
java 0;"

5. If you had to do number 4 and it worked, then I would suggest
making sure that steps 1-3 are not the case (fresh install of 4.5).
If number 4 didn’t work, jump to step 7.

6. If number 4 worked but number 5 didn’t, it sounds like it is your
Java installation (there have been some user report of this, but then
both 4.5 and 4.6 would be crashing)

7. Something else must be the problem. Please send a crash log and
more information about your machine, or follow up with
support@cycling74.com.

If you’re not really *crashing*, but seemingly *freezing*. It’s
probably the known problem with Apple taking 30 seconds or more to
resolve network aliases that are not present.

-Joshua


September 20, 2006 | 3:38 am

Thanks for that. I tried all these things, but then managed to fix
the problem – it was to do with SubEthaEdit which took over my .mxo
externals, and not to do with Max itself.
Removing SubEthaEdit has worked.
Thanks again.

Alastair

On 20 Sep 2006, at 10:44, Joshua Kit Clayton wrote:

>
> On Sep 19, 2006, at 5:10 PM, Alastair Weakley wrote:
>
>> I’ve been using the max/msp 4.6 beta and max/msp 4.5 at the same
>> time on my Intel mac with no trouble. Where I have to use my old
>> externals, I’ve been able to run them with max/msp 4.5.
>> I’ve now installed the release version of max/msp 4.6 and the
>> updated jitter and I notice that I can’t run some of the old
>> patches in 4.5 any more- the application just crashes when I open
>> the patch. Could the install of 4.6 have made a change to my 4.5
>> installation somehow?
>
> If you’re crashing at launch, it is often an mxj issue, with
> mismatched max.jar and mxj object instances, as Jitter loads Jitter
> Java support at launch by default.
>
> First steps:
>
> 1. Try trashing your preferences
>
> 2. Make sure that you don’t have the Max 4.6 folders in your file
> preferecnes for 4.5
>
> 3. Make sure you don’t have any standalones in your search path
> which contain old versions of max.jar
>
> 4. Manually disable Jitter java loading by putting a file named
> jitter-config.txt in your search path containing the text "jitter
> java 0;"
>
> 5. If you had to do number 4 and it worked, then I would suggest
> making sure that steps 1-3 are not the case (fresh install of 4.5).
> If number 4 didn’t work, jump to step 7.
>
> 6. If number 4 worked but number 5 didn’t, it sounds like it is
> your Java installation (there have been some user report of this,
> but then both 4.5 and 4.6 would be crashing)
>
> 7. Something else must be the problem. Please send a crash log and
> more information about your machine, or follow up with
> support@cycling74.com.
>
> If you’re not really *crashing*, but seemingly *freezing*. It’s
> probably the known problem with Apple taking 30 seconds or more to
> resolve network aliases that are not present.
>
> -Joshua


September 20, 2006 | 5:58 am

Joshua Kit Clayton wrote:
> If you’re not really *crashing*, but seemingly *freezing*. It’s
> probably the known problem with Apple taking 30 seconds or more to
> resolve network aliases that are not present.

30 seconds wouldn’t be too bad, its sometimes around 5 minutes. Is Apple
going to change that to 500 ms or less (which should be suffucient to
realise its not there). This bug is buggin’ me for years now, but end
user reports seem to be ignored, developers are hopefully more
influencial…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


September 20, 2006 | 8:15 am

On 20-Sep-2006, at 7:58, Stefan Tiedje wrote:

> Is Apple going to change that to 500 ms or less (which should be
> suffucient to realise its not there).

I would have to research this to be sure, but I seem to recall that
at the hardware protocol level connections are allowed to break for
something like 5 to 15 seconds. It can take that long to unplug and
replug an Ethernet cable, for instance (think about adding a node in
a linear topology). Or if you’re accessing a file server over a dial-
up line, 500ms is not a particularly reasonable assumption to make.
Robust general-purpose file sharing protocols need more time than that.

It might be possible for Max to build the search path using
asynchronous calls to the file system, which could alleviate the
cumulative effect of trying to resolve multiple network aliases
(which seems to be Stefan’s problem). An asynchronous approach would
be a lot more complex. Who knows if this will ever percolate up the
priority list, or if it’s a feasible alternative?

In the meantime, your best bet is to avoid network aliases in the
search path.

In general it is safe to assume that the people designing network
protocols know what they are doing. They’ve been doing it a lot
longer than you and me put together.

– P.

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de


September 21, 2006 | 8:03 am

Peter Castine wrote:
> In general it is safe to assume that the people designing network
> protocols know what they are doing. They’ve been doing it a lot longer
> than you and me put together.

Hard to believe that its not bugging them as much as me. The only
conclusion I got so far: the developers don’t use laptops, or never
connect them with a cable…

But you’re right, the 5 minutes might be a Max issue, because a simple
not available but mounted volume will bug out after 30 seconds. (But I
have no idea why this needs to be in the highest priority and needs to
lock the whole machine. I would rather assume that the people don’t know
what they are doing until its explained… ;-)

A non resolving alias would immediately give me an alert if I try to
acces it from the finder. I am sure Max should be able to grab that alert…

On the other hand I’d probably not realise any fixing, because I avoid
aliases in the search path "wie der Teufel das Weihwasser". It didn’t
happen to me for a long time…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


Viewing 6 posts - 1 through 6 (of 6 total)