Forums > MaxMSP

[bug] [mxj] and [pattrstorage @autorestore 1] at loadtime

September 27, 2006 | 7:56 am


September 27, 2006 | 1:43 pm

Sorry, I can’t reproduce this. PPC 10.4.7, Max 4.6.2. I added a
pattr, stored a preset, saved the XML file, and restarted Max, and
reopened the patch. Everything works as it should on my machine. If
you can still reproduce, I’ll need a more complete example patch.

Thanks -
jb

Am 27.09.2006 um 09:56 schrieb Patrick Delges:

> I saw on the forum more or less the same bug, but it wasn’t
> confirmed, so…
>
> #Summary:
>
> if the jvm has to be loaded while a patch that includes a
> [pattrstorage] with @autorestore set to 1 is opened, the
> autorestore step isn’t performed.
>
> #Steps:
>
> 1. close Max
> 2. open this patch:
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 52 181 32 196617 print;
> #P newex 52 147 226 196617 pattrstorage tagc @savemode 2
> @autorestore 1;
> #X client_rect 0 0 640 240;
> #X storage_rect 0 0 640 240;
> #P objectname tagc;
> #P newex 53 86 49 196617 mxj help;
> #P connect 1 0 2 0;
> #P window clipboard copycount 3;
>
> -> pattrstorage doesn’t load it’s .xml file.
>
> 3. Close the patch (but keep Max running) and reopen the patch ->
> now the autorestore is performed
>
> #Expected:
>
> "print: read tagc.xml 0" should be seen in the Max window
>
> Note that if the tagc.xml file does exist, there won’t be a "print:
> read tagc.xml 1".
>
> #Actual:
>
> only the [mxj] stuff are displayed in the Max window.
>
> # Regression:
>
> Max4.5.7 under OSX.3.9
> Max4.6.2 under OSX.4.7
>
> # Note:
>
> I gave a short example, without any data to restore, but as there
> isn’t even a message telling that the .xml file is loaded, I though
> this example should be enough. Adding values in the patch connected
> to the pattr system won’t change this behavior.
>
>
> _____________________________
> Patrick Delges
>
> Centre de Recherches et de Formation Musicales de Wallonie asbl
> http://users.skynet.be/crfmw/max
>


September 27, 2006 | 3:13 pm

On 27 sept. 06, at 15:43, Jeremy Bernstein wrote:

> Sorry, I can’t reproduce this. PPC 10.4.7, Max 4.6.2. I added a pattr,
> stored a preset, saved the XML file, and restarted Max, and reopened
> the patch. Everything works as it should on my machine. If you can
> still reproduce, I’ll need a more complete example patch.

I tried to do the smallest patch possible that reproduce this "bug".
And everytime I try, I get the same behavior.
It may be the same problem as the one discussed here:
http://www.cycling74.com/forums/index.php?
t=msg&rid=607&S=e62945f0f33a67b4e8de724ee958d572&th=17068&goto=58030#msg
_58030

At that time, Ben Neville couldn’t reproduce neither.

p

> Thanks -
> jb
>
> Am 27.09.2006 um 09:56 schrieb Patrick Delges:
>
>> I saw on the forum more or less the same bug, but it wasn’t
>> confirmed, so…
>>
>> #Summary:
>>
>> if the jvm has to be loaded while a patch that includes a
>> [pattrstorage] with @autorestore set to 1 is opened, the autorestore
>> step isn’t performed.
>>
>> #Steps:
>>
>> 1. close Max
>> 2. open this patch:
>>
>> #P window setfont "Sans Serif" 9.;
>> #P window linecount 1;
>> #P newex 52 181 32 196617 print;
>> #P newex 52 147 226 196617 pattrstorage tagc @savemode 2 @autorestore
>> 1;
>> #X client_rect 0 0 640 240;
>> #X storage_rect 0 0 640 240;
>> #P objectname tagc;
>> #P newex 53 86 49 196617 mxj help;
>> #P connect 1 0 2 0;
>> #P window clipboard copycount 3;
>>
>> -> pattrstorage doesn’t load it’s .xml file.
>>
>> 3. Close the patch (but keep Max running) and reopen the patch ->
>> now the autorestore is performed
>>
>> #Expected:
>>
>> "print: read tagc.xml 0" should be seen in the Max window
>>
>> Note that if the tagc.xml file does exist, there won’t be a "print:
>> read tagc.xml 1".
>>
>> #Actual:
>>
>> only the [mxj] stuff are displayed in the Max window.
>>
>> # Regression:
>>
>> Max4.5.7 under OSX.3.9
>> Max4.6.2 under OSX.4.7
>>
>> # Note:
>>
>> I gave a short example, without any data to restore, but as there
>> isn’t even a message telling that the .xml file is loaded, I though
>> this example should be enough. Adding values in the patch connected
>> to the pattr system won’t change this behavior.
>>
>>
>> _____________________________
>> Patrick Delges
>>
>> Centre de Recherches et de Formation Musicales de Wallonie asbl
>> http://users.skynet.be/crfmw/max
>>
>
>
>
_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://users.skynet.be/crfmw/max


September 27, 2006 | 5:09 pm

On Sep 27, 2006, at 8:13 AM, Patrick Delges wrote:

> I tried to do the smallest patch possible that reproduce this
> "bug". And everytime I try, I get the same behavior.
> It may be the same problem as the one discussed here:
> http://www.cycling74.com/forums/index.php?
> t=msg&rid=607&S=e62945f0f33a67b4e8de724ee958d572&th=17068&goto=58030#m
> sg_58030
>
> At that time, Ben Neville couldn’t reproduce neither.

Just speculating here, but it could be some sort of issue with
loadbang and/or internally deferred messages (such as those used by
patcherargs and pattr objects) while mxj is initializing java. Ben
and Jeremy most likely have Jitter installed which initializes Java
on program launch, and therefore cannot reproduce. It sounds like you
might not have Jitter installed (or are using "jitter java 0;" in
jitter-config.txt) and hence have to initialize java on first mxj
instance in a patcher which is what sounds like is leading to the issue.

I’d be curious to know if it is specifically an issue with print, or
if the values actually are *not* restored.

One way to avoid this might be to add a patcher containing something
like "mxj quickie" with a loadbang to close->thispatcher in your
start up folder to always initialize java before other patches are
loaded.

-Joshua


September 27, 2006 | 6:21 pm

On 27-sept.-06, at 19:09, Joshua Kit Clayton wrote:

> Just speculating here, but it could be some sort of issue with
> loadbang and/or internally deferred messages (such as those used by
> patcherargs and pattr objects) while mxj is initializing java. Ben and
> Jeremy most likely have Jitter installed which initializes Java on
> program launch, and therefore cannot reproduce. It sounds like you
> might not have Jitter installed (or are using "jitter java 0;" in
> jitter-config.txt) and hence have to initialize java on first mxj
> instance in a patcher which is what sounds like is leading to the
> issue.

With Max4.6.2/OSX.4.7, there is no jitter
With Max4.5.7/OSX.3.9, a pre 1.5 (1.2.4 I think) Jitter is installed.

> I’d be curious to know if it is specifically an issue with print, or
> if the values actually are *not* restored.

I noticed this "bug", because my values were not restored in the patch
I’m currently working on. When I tested the small patch I sent and
didn’t see the [print] results on the MAx window I didn’t check
further. I can do more tests tomorrow, but now I don’t have access to
these machines anymore.

> One way to avoid this might be to add a patcher containing something
> like "mxj quickie" with a loadbang to close->thispatcher in your start
> up folder to always initialize java before other patches are loaded.

I was thinking to do a [mxj jvmLoaded] that send a bang when loaded. It
needs to work with standalones too!

Thanks!

p


September 28, 2006 | 7:28 am

On 27 sept. 06, at 19:09, Joshua Kit Clayton wrote:

> On Sep 27, 2006, at 8:13 AM, Patrick Delges wrote:

< ...>

> I’d be curious to know if it is specifically an issue with print, or
> if the values actually are *not* restored.

In the patch I’m working on, the values are not restored, the
storagewindow doesn’t show any values.

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://users.skynet.be/crfmw/max


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