hi all,
a few comments after reading the log of yesterday irc meeting (did not know that log would be available at artengine, so I connected to make my own):
some of you wondered, how Max organizes externals, object list, and help. This is what I remember, and what is written in the docs...
The Max way of looking for any relative file name, be it of an external, a patch, a sound file, etc., but not a help file, is first doing a shallow search in the patch's directory, then doing a deep search of the entire subtree of all directories listed in the global search path.
Help patches are looked for in the entire subtree of the special "help" directory.
There is a shallow "startup" directory, containing externals to load when Max starts.
There is a shallow "init" directory, containing text files with messages to send when Max starts.
The mechanism for creating the object list is simple, efficient, and more Pd-like than 'meta'-comments. It has two parts:
1. There is a message to 'max' ("; max oblist category name") which registers a name into a category. Any file in the "init" directory may provide this message for any class or abstraction.
2. A class may register itself into a category through a call in its setup routine:
/* add class name to finder list */ void finder_addclass(char *category, char *classString);
IOhanness: I could not reproduce that speedlim bug... do you have a demo patch, perhaps? There is one ambiguity, might this be related? -- if the time interval changes after clock has been set, it is not clear if the clock should be rescheduled or not. Cyclone's speedlim does no rescheduling, just as c74's (at least it did not last time I checked, which was over 2 years ago).
Krzysztof
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
- There is a message to 'max' ("; max oblist category name")
which registers a name into a category. Any file in the "init" directory may provide this message for any class or abstraction.
I like that more than (ab)using comments for this purpose.
Ciao
IOhanness: I could not reproduce that speedlim bug... do you have a demo patch, perhaps? There is one ambiguity, might this be related? -- if the time interval changes after clock has been set, it is not clear if the clock should be rescheduled or not. Cyclone's speedlim does no rescheduling, just as c74's (at least it did not last time I checked, which was over 2 years ago).
i asked thomas whether he could try it again: and lo and behold, he wasn't able to reproduce the bug either.
so i think you can file that one under "fixed" ;-)
sorry for the inconvenience
mfg,asd,r+ IOhannes