mickster

For some reason all my patches that use the [delay] object have stopped working. I'm getting this error in the max window.

This has come as a bit of a shock. Does anyone else have this problem?

max-5-delay-object

ok - delay.mxo is present - so I launched the help patch manually. Now the object is loading.

On Apr 24, 2008, at 3:37 AM, mick grierson wrote:

> For some reason all my patches that use the [delay] object have 

> stopped working. I'm getting this error in the max window.

> This has come as a bit of a shock. Does anyone else have this problem?

Sounds to me like you have something else called delay in one of your 

file paths, and Max is trying to load that. Search your file paths, 

and I bet you find something else called delay.

On Apr 24, 2008, at 3:37 AM, mick grierson wrote:
> For some reason all my patches that use the [delay] object have  
> stopped working. I'm getting this error in the max window.
>
> newobj: delay: No such object
>
> This has come as a bit of a shock. Does anyone else have this problem?

Sounds to me like you have something else called delay in one of your  
file paths, and Max is trying to load that. Search your file paths,  
and I bet you find something else called delay.

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

That's the first thing I checked for and no dice.

It was a fresh max 5 installation and no externals or patche in the search path.

That's the first thing I checked for and no dice. 

> That's the first thing I checked for and no dice. 

> It was a fresh max 5 installation and no externals or patche in the search path.

Funny, yesterday I came across exactly the same. But it was a patch 

called Delay, which was residing in my Max 4 search path without ever 

noticing it (Max 4 just found the correct delay first)

It seems the implemented warning about double entries of the same patch 

didn't catch it, as it was Delay (no extensions) versus delay.mxo...

Even if David isn't convinced, I'd like to insist on correcting the 

search order. First search the main folders, then any added paths. It 

might be not perfect for developing Max itself, but for the release 

versions I don't see any advantage of the existing order... (It could be 

Also I'd always prefer and load first objects in the native format. (mxo 

over maxpat over pat/mxb over mxf) As we have a database now, this 

should be possible somehow without too much of overhead...

mick grierson schrieb:
> That's the first thing I checked for and no dice. 
>
> It was a fresh max 5 installation and no externals or patche in the search path.
>
> I'm putting it down to bit rot.

Funny, yesterday I came across exactly the same. But it was a patch 
called Delay, which was residing in my Max 4 search path without ever 
noticing it (Max 4 just found the correct delay first)

It seems the implemented warning about double entries of the same patch 
didn't catch it, as it was Delay (no extensions) versus delay.mxo...

Even if David isn't convinced, I'd like to insist on correcting the 
search order. First search the main folders, then any added paths. It 
might be not perfect for developing Max itself, but for the release 
versions I don't see any advantage of the existing order... (It could be 
customisable...)

Also I'd always prefer and load first objects in the native format. (mxo 
over maxpat over pat/mxb over mxf) As we have a database now, this 
should be possible somehow without too much of overhead...

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

On Apr 25, 2008, at 2:09 AM, Stefan Tiedje wrote:

> Even if David isn't convinced, I'd like to insist on correcting the 

> search order. First search the main folders, then any added paths. 

> It might be not perfect for developing Max itself, but for the 

> release versions I don't see any advantage of the existing order... 

The first couple of paths in my File Preferences are paths to Cycling 

'74/max-externals and Cycling '74/msp-externals

This means I'm insulated from my own stupidity to some extent.

> Also I'd always prefer and load first objects in the native format. 

> (mxo over maxpat over pat/mxb over mxf) As we have a database now, 

> this should be possible somehow without too much of overhead...

At least the .maxpat over .pat rule is in place.

On Apr 25, 2008, at 2:09 AM, Stefan Tiedje wrote:
> Even if David isn't convinced, I'd like to insist on correcting the  
> search order. First search the main folders, then any added paths.  
> It might be not perfect for developing Max itself, but for the  
> release versions I don't see any advantage of the existing order...  
> (It could be customisable...)

The first couple of paths in my File Preferences are paths to Cycling  
'74/max-externals and Cycling '74/msp-externals

> Also I'd always prefer and load first objects in the native format.  
> (mxo over maxpat over pat/mxb over mxf) As we have a database now,  
> this should be possible somehow without too much of overhead...

OK so delay didn't initialise when I first installed and ran Max 5, and I got "no such object". All I did was open the help patch by double clicking on it and it started working - nothing in the search path called delay apart from delay.mxo. Seemed like a glitch.

Now I've just installed Max 5.0.1 and the first time I tried to open one of my old patches with the delay object in, delay didn't instantiate and I got 'no such object'. Tried a few more times (without restarting) and then it popped up like nothing had happened. Same as before.

I guess It's not so important. Looks like a few other people may have had this problem too.

On 28 avr. 08, at 21:27, mick grierson wrote:

> OK so delay didn't initialise when I first installed and ran Max 5, 

> and I got "no such object". All I did was open the help patch by 

> double clicking on it and it started working - nothing in the search 

> path called delay apart from delay.mxo. Seemed like a glitch.

> Now I've just installed Max 5.0.1 and the first time I tried to open 

> one of my old patches with the delay object in, delay didn't 

> instantiate and I got 'no such object'. Tried a few more times 

> (without restarting) and then it popped up like nothing had 

> I guess It's not so important. Looks like a few other people may 

Make sure that you don't have any file called delay in your search path.

>
> OK so delay didn't initialise when I first installed and ran Max 5,  
> and I got "no such object". All I did was open the help patch by  
> double clicking on it and it started working - nothing in the search  
> path called delay apart from delay.mxo. Seemed like a glitch.
>
> Now I've just installed Max 5.0.1 and the first time I tried to open  
> one of my old patches with the delay object in, delay didn't  
> instantiate and I got 'no such object'. Tried a few more times  
> (without restarting) and then it popped up like nothing had  
> happened. Same as before.
>
> I guess It's not so important. Looks like a few other people may  
> have had this problem too.

Yes, thanks for responding. I appreciate that it -sounds- like the common problem of having an abstraction in the search path with the same name, and I've been careful to check this before posting on each occasion.

These are fresh installs with nothing in the search path - when installing Max 5.0 and then again when I installed Max 5.0.1 over the top.

both typing del and delay resulted in the error until after a few attempts. No relaunch of Max 5 required. After this, delay works normally.

The fact that this happens to several people, and not consistently,

suggests to me that this isn't as simple as having a file called delay

> On 28 avr. 08, at 21:27, mick grierson wrote:

> > OK so delay didn't initialise when I first installed and ran Max 5, and I

> Make sure that you don't have any file called delay in your search path.

The fact that this happens to several people, and not consistently,
suggests to me that this isn't as simple as having a file called delay
in the search path.

2008/4/28 Emmanuel Jourdan :
> On 28 avr. 08, at 21:27, mick grierson wrote:

> > OK so delay didn't initialise when I first installed and ran Max 5, and I
> got "no such object".
>
>  Make sure that you don't have any file called delay in your search path.
>
>  ej
>


Quote: mickster wrote on Mon, 28 April 2008 23:47

----------------------------------------------------

> Ok. Found delay.jpg in my patch folder.

what's wrong with a jpg? it has an extension even, why would it stop max from finding delay.mxo?

Quote: mickster wrote on Mon, 28 April 2008 23:47
----------------------------------------------------
> Ok. Found delay.jpg in my patch folder.
----------------------------------------------------

what's wrong with a jpg? it has an extension even, why would it stop max from finding delay.mxo?


On Apr 28, 2008, at 2:58 PM, Arne Eigenfeldt wrote:

> The fact that this happens to several people, and not consistently,

> suggests to me that this isn't as simple as having a file called delay

Even though that's been the cause every time?

The advice I gave earlier in this thread about having the first user 

paths set to the max-externals and msp-externals folder is also still 

On Apr 28, 2008, at 2:58 PM, Arne Eigenfeldt wrote:
> The fact that this happens to several people, and not consistently,
> suggests to me that this isn't as simple as having a file called delay
> in the search path.

The advice I gave earlier in this thread about having the first user  
paths set to the max-externals and msp-externals folder is also still  
valid.

On Apr 28, 2008, at 3:21 PM, Klaas-Jan Govaart wrote:

> what's wrong with a jpg? it has an extension even, why would it stop 

Max doesn't look for delay.mxo. Max looks for delay. This way you can 

override a built in object with an abstraction.

On Apr 28, 2008, at 3:21 PM, Klaas-Jan Govaart wrote:
> what's wrong with a jpg? it has an extension even, why would it stop  
> max from finding delay.mxo?

Max doesn't look for delay.mxo. Max looks for delay. This way you can  
override a built in object with an abstraction.

Nope, it's fine now. The patch is a total monster, and I'm not the sole author. I'm pretty sure it's our fault, although not sure how or why.

Quote: Chris Muir wrote on Tue, 29 April 2008 00:46

> On Apr 28, 2008, at 3:21 PM, Klaas-Jan Govaart wrote:

> > what's wrong with a jpg? it has an extension even, why would it stop 

> Max doesn't look for delay.mxo. Max looks for delay. This way you can 

> override a built in object with an abstraction.

So no matter what extension it has, a file can't be named the same as an external? Can it be named the same a a patch?

Quote: Chris Muir wrote on Tue, 29 April 2008 00:46
----------------------------------------------------
>
> On Apr 28, 2008, at 3:21 PM, Klaas-Jan Govaart wrote:
> > what's wrong with a jpg? it has an extension even, why would it stop  
> > max from finding delay.mxo?
>
>
> Max doesn't look for delay.mxo. Max looks for delay. This way you can  
> override a built in object with an abstraction.

On Apr 28, 2008, at 3:50 PM, Klaas-Jan Govaart wrote:

> So no matter what extension it has, a file can't be named the same 

> as an external? Can it be named the same a a patch?

Not if the patch is used as an abstraction, I don't think. If Max has 

This may seem a little capricious, but there are pretty good reasons 

for wanting to override existing Max behavior. Here's an example of 

On Apr 28, 2008, at 3:50 PM, Klaas-Jan Govaart wrote:
> So no matter what extension it has, a file can't be named the same  
> as an external? Can it be named the same a a patch?

Not if the patch is used as an abstraction, I don't think. If Max has  
to find it, it's going to use its rules.

This may seem a little capricious, but there are pretty good reasons  
for wanting to override existing Max behavior. Here's an example of  
wanting to change the way delay works:

Quote: Chris Muir wrote on Tue, 29 April 2008 01:14

> On Apr 28, 2008, at 3:50 PM, Klaas-Jan Govaart wrote:

> > So no matter what extension it has, a file can't be named the same 

> > as an external? Can it be named the same a a patch?

> Not if the patch is used as an abstraction, I don't think. If Max has 

> to find it, it's going to use its rules.

I could imagine making a patch that uses a jpg and saving both with the same name - patch.maxpat and patch.jpg. Better not, I guess.

Quote: Chris Muir wrote on Tue, 29 April 2008 01:14
----------------------------------------------------
>
> On Apr 28, 2008, at 3:50 PM, Klaas-Jan Govaart wrote:
> > So no matter what extension it has, a file can't be named the same  
> > as an external? Can it be named the same a a patch?
>
>
> Not if the patch is used as an abstraction, I don't think. If Max has  
> to find it, it's going to use its rules.

OK, tracked it down. The behaviour in Max 5 is different to Max 4, at least on my system - os x 10.4.11. Using Max 4 and Max 5, both with default file preferences.

The attached archive contains a patch written on Max 4.6.3, and a text file written by Max called delay. The patch contains a coll named delay which loads the text file delay via a loadbang. There's also a delay object to the left of the coll.

The delay object to the left of the coll doesn't load on Max 5, but loads on Max 4.6.3. In fact, you can't create a working version of this patch in Max 5, but it's fine in Max 4.

If this is something everyone else knows about, sorry, I've been busy playing portal.

On 29 avr. 08, at 02:07, mick grierson wrote:

> OK, tracked it down. The behaviour in Max 5 is different to Max 4, 

> at least on my system - os x 10.4.11. Using Max 4 and Max 5, both 

> The attached archive contains a patch written on Max 4.6.3, and a 

> text file written by Max called delay. The patch contains a coll 

> named delay which loads the text file delay via a loadbang. There's 

> also a delay object to the left of the coll.

> The delay object to the left of the coll doesn't load on Max 5, but 

> loads on Max 4.6.3. In fact, you can't create a working version of 

> this patch in Max 5, but it's fine in Max 4.

The reason it worked in the past is that [delay] was an internal 

object (embed inside the Max application). In Max 5, it's a normal 

external, therefore the search path logic applies.

> OK, tracked it down. The behaviour in Max 5 is different to Max 4,  
> at least on my system - os x 10.4.11. Using Max 4 and Max 5, both  
> with default file preferences.
>
> The attached archive contains a patch written on Max 4.6.3, and a  
> text file written by Max called delay. The patch contains a coll  
> named delay which loads the text file delay via a loadbang. There's  
> also a delay object to the left of the coll.
>
> The delay object to the left of the coll doesn't load on Max 5, but  
> loads on Max 4.6.3. In fact, you can't create a working version of  
> this patch in Max 5, but it's fine in Max 4.

The reason it worked in the past is that [delay] was an internal  
object (embed inside the Max application). In Max 5, it's a normal  
external, therefore the search path logic applies.

> The advice I gave earlier in this thread about having the first user 

> paths set to the max-externals and msp-externals folder is also still 

And the strong and often repeated demand that this should not be 

Only for those at cycling, while creating new versions of existing 

objects, the current behaviour is useful, for the end user it will never 

This is crying for a preference to determine the order of search...

I promised that the amount of support this is triggering is way higher 

than the amount of work to get the order of searching corrected...

That seems now to be verified and obvious...

Chris Muir schrieb:
> The advice I gave earlier in this thread about having the first user 
> paths set to the max-externals and msp-externals folder is also still 
> valid.

And the strong and often repeated demand that this should not be 
necessary as well...
Only for those at cycling, while creating new versions of existing 
objects, the current behaviour is useful, for the end user it will never 
be...
This is crying for a preference to determine the order of search...

I promised that the amount of support this is triggering is way higher 
than the amount of work to get the order of searching corrected...
That seems now to be verified and obvious...

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


> This may seem a little capricious, but there are pretty good reasons for 

> wanting to override existing Max behavior. Here's an example of wanting 

But its a very bad advice to give it the same name as an existing 

object. Its far far far better to name it differently. Else wise you get 

lost as soon you port a patch to a different machine with the standard 

behaviour. If you give it the name "delayall" for example and forgot to 

transfer it, you will get an error message. If you have the same name 

your patch doesn't work and you don't know why... (as there is no error 

But I don't know why Max isn't smart enough to recognize that delay.jpg 

isn't a patch or external and keeps on searching. That is a bug and 

should be changed at least... (same for .js, .mxj etc...)

Chris Muir schrieb:
> This may seem a little capricious, but there are pretty good reasons for 
> wanting to override existing Max behavior. Here's an example of wanting 
> to change the way delay works:

But its a very bad advice to give it the same name as an existing 
object. Its far far far better to name it differently. Else wise you get 
lost as soon you port a patch to a different machine with the standard 
behaviour. If you give it the name "delayall" for example and forgot to 
transfer it, you will get an error message. If you have the same name 
your patch doesn't work and you don't know why... (as there is no error 
message...)

But I don't know why Max isn't smart enough to recognize that delay.jpg 
isn't a patch or external and keeps on searching. That is a bug and 
should be changed at least... (same for .js, .mxj etc...)

If you name your abstraction with a litlle pre or suffix, like 

"prefix.absname", you divide the chances of name conflicts by a fair 

amount. Using different prefixes for different versions of a same 

(evolving) abstraction is even a very convenient way to have those 

abstractions cohabitating together within the search path. If you set 

the prefix name to something you can remember later, like the (nick) 

name of the current project you're just working on, for instance, you 

have many more chances to remember when such or such feature was 

added or removed, the context of the project, etc.

If you name your abstraction with a litlle pre or suffix, like  
"prefix.absname", you divide the chances of name conflicts by a fair  
amount. Using different prefixes for different versions of a same  
(evolving) abstraction is even a very convenient way to have those  
abstractions cohabitating together within the search path. If you set  
the prefix name to something you can remember later, like the (nick) 
name of the current project you're just working on, for instance, you  
have many more chances to remember when such or such feature was  
added or removed, the context of the project, etc.

Quote: Stefan Tiedje wrote on Tue, 29 April 2008 16:07

> But I don't know why Max isn't smart enough to recognize that delay.jpg 

> isn't a patch or external and keeps on searching. That is a bug and 

> should be changed at least... (same for .js, .mxj etc...)

exactly. it really seems strange to me that max could get in trouble loading an object or external this way. surely the jpg, doc, zip or mpg isn't the external/object it is looking for...

Quote: Stefan Tiedje wrote on Tue, 29 April 2008 16:07
----------------------------------------------------

>
> But I don't know why Max isn't smart enough to recognize that delay.jpg 
> isn't a patch or external and keeps on searching. That is a bug and 
> should be changed at least... (same for .js, .mxj etc...)
>

exactly. it really seems strange to me that max could get in trouble loading an object or external this way. surely the jpg, doc, zip or mpg isn't the external/object it is looking for...


On Apr 29, 2008, at 7:00 AM, Stefan Tiedje wrote:

>> The advice I gave earlier in this thread about having the first 

>> user paths set to the max-externals and msp-externals folder is 

> And the strong and often repeated demand that this should not be 

If the first couple of user-changeable paths pointed to the max- 

externals and msp-externals by default, would that be enough for you? 

It seems like that would be the best of both worlds, it would keep 

users from shooting themselves in the foot, and would allow Cycling 

On Apr 29, 2008, at 7:00 AM, Stefan Tiedje wrote:
> Chris Muir schrieb:
>> The advice I gave earlier in this thread about having the first  
>> user paths set to the max-externals and msp-externals folder is  
>> also still valid.
>
> And the strong and often repeated demand that this should not be  
> necessary as well...

Max 5 delay object ?