Max 5: Check if patcher is being freed?

Jan 10, 2009 at 2:41am

Max 5: Check if patcher is being freed?

From my object’s free function, I need to check if my parentpatcher is also being freed (ie if just my object is being deleted or if the entire patcher is).

In Max 4, I check the t_patcher’s p_freed member, which seems to work reliably.

In Max 5, the t_patcher structure is opaque, so it has been suggested that I use the patcher “getfreed” method:

if(p && jpatcher_is_patcher(p) && object_method(p, gensym(“getfreed”))) // do stuff

Unfortunately, while this patcher method does appear to exist, it is reliably crashing Max 5 when only my object is freed, when the entire patcher is freed, or at quit.

Can this work? I’m hoping so because it’s a nice direct replacement for the Max 4 version – any assistance appreciated. Relevant part of crash report follows:

Date/Time: 2009-01-10 13:46:50.673 +1300
OS Version: 10.4.10 (Build 8R218)
Report Version: 4
Command: MaxMSP
Path: /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP
Parent: WindowServer [136]
Version: 5.0.5 (36470) (5.0.5)
PID: 917
Thread: 0
Exception: EXC_BAD_ACCESS (0×0001)
Codes: KERN_INVALID_ADDRESS (0×0001) at 0xfefefeff

Thread 0 Crashed:
0 com.cycling74.MaxMSP 0x001696f0 jpatcher_getfreed + 8
1 com.cycling74.MaxMSP 0x000abca0 object_method + 1064
2 com.cycling74.MaxAPI 0x0195ea90 object_method + 244
3 com.opuslocus.oo.call 0x063de86c oo_call_Free + 208 (oo_call.c:201)
4 com.cycling74.MaxMSP 0x0002d824 freeobject + 252
5 com.cycling74.MaxMSP 0x00154b40 jnewobj_free + 36
6 com.cycling74.MaxMSP 0x0002d824 freeobject + 252
7 com.cycling74.MaxMSP 0x000a84ac object_free + 36
8 com.cycling74.MaxMSP 0×00166044 jpatcher_remove + 112
9 com.cycling74.MaxMSP 0x000a85c8 object_method_typedfun + 144
10 com.cycling74.MaxMSP 0x001752f0 jpatchercontroller_removeobjects_imp(_jpatchercontroller*, symbol*, long, atom*) + 212
11 com.cycling74.MaxMSP 0×00199824 PatcherComponent::deleteSelection() + 156
12 com.cycling74.MaxMSP 0x0019ee60 PatcherComponent::keyPressed(juce::KeyPress const&) + 756

#41619
Jan 10, 2009 at 3:15am

You should use the visibility callbacks to get notified when the
patcher your object is in appears or goes away.

// visibility callbacks
class_addmethod(c, (method) myobj_patcherview_vis, “patcherview_vis”,
A_CANT, 0);
class_addmethod(c, (method) myobj_patcherview_invis,
“patcherview_invis”, A_CANT, 0);

// rebuilding callbacks
class_addmethod(c, (method) myobj_recreate_vis, “recreate_vis”, A_CANT, 0);
class_addmethod(c, (method) myobj_recreate_invis, “recreate_invis”, A_CANT, 0);

all functions should have the signature:
void myobj_recreate_vis(t_max_jit_pwindow *x, t_object *patcherview)

wes

On Fri, Jan 9, 2009 at 6:41 PM, John Pitcairn
wrote:
>
> >From my object’s free function, I need to check if my parentpatcher is also being freed (ie if just my object is being deleted or if the entire patcher is).
>
> In Max 4, I check the t_patcher’s p_freed member, which seems to work reliably.
>
> In Max 5, the t_patcher structure is opaque, so it has been suggested that I use the patcher “getfreed” method:
>
> if(p && jpatcher_is_patcher(p) && object_method(p, gensym(“getfreed”))) // do stuff
>
> Unfortunately, while this patcher method does appear to exist, it is reliably crashing Max 5 when only my object is freed, when the entire patcher is freed, or at quit.
>
> Can this work? I’m hoping so because it’s a nice direct replacement for the Max 4 version – any assistance appreciated. Relevant part of crash report follows:
>
> Date/Time: 2009-01-10 13:46:50.673 +1300
> OS Version: 10.4.10 (Build 8R218)
> Report Version: 4
> Command: MaxMSP
> Path: /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP
> Parent: WindowServer [136]
> Version: 5.0.5 (36470) (5.0.5)
> PID: 917
> Thread: 0
> Exception: EXC_BAD_ACCESS (0×0001)
> Codes: KERN_INVALID_ADDRESS (0×0001) at 0xfefefeff
>
> Thread 0 Crashed:
> 0 com.cycling74.MaxMSP 0x001696f0 jpatcher_getfreed + 8
> 1 com.cycling74.MaxMSP 0x000abca0 object_method + 1064
> 2 com.cycling74.MaxAPI 0x0195ea90 object_method + 244
> 3 com.opuslocus.oo.call 0x063de86c oo_call_Free + 208 (oo_call.c:201)
> 4 com.cycling74.MaxMSP 0x0002d824 freeobject + 252
> 5 com.cycling74.MaxMSP 0x00154b40 jnewobj_free + 36
> 6 com.cycling74.MaxMSP 0x0002d824 freeobject + 252
> 7 com.cycling74.MaxMSP 0x000a84ac object_free + 36
> 8 com.cycling74.MaxMSP 0×00166044 jpatcher_remove + 112
> 9 com.cycling74.MaxMSP 0x000a85c8 object_method_typedfun + 144
> 10 com.cycling74.MaxMSP 0x001752f0 jpatchercontroller_removeobjects_imp(_jpatchercontroller*, symbol*, long, atom*) + 212
> 11 com.cycling74.MaxMSP 0×00199824 PatcherComponent::deleteSelection() + 156
> 12 com.cycling74.MaxMSP 0x0019ee60 PatcherComponent::keyPressed(juce::KeyPress const&) + 756
>

#148303
Jan 10, 2009 at 3:16am

whoops. forgot to change one thing

obviously this:
> void myobj_recreate_vis(t_max_jit_pwindow *x, t_object *patcherview)

should be this:
void myobj_recreate_vis(t_myobj *x, t_object *patcherview)

#148304
Jan 10, 2009 at 6:27am

Thanks … given these appear to be for the patcherview(?), do these callbacks also fire when the patcher is simply opened/closed/etc?

I need to know when the patcher itself is being freed or is queued to be freed, not when it is closed – the view state is not relevant for my purposes.

Is there a “patcher freed” callback I can register for? Something like:

class_addmethod(c, (method) myobj_patcher_free, “patcher_free”, A_CANT, 0);

Is this stuff documented yet?

#148305
Jan 19, 2009 at 12:11am

Quote: wesley.hoke@gmail.com wrote on Sat, 10 January 2009 16:15
—————————————————-
> You should use the visibility callbacks to get notified when the
> patcher your object is in appears or goes away.

OK, I’ve tried adding all 4 callbacks in main() where I register my other object methods.

My callback function is not being called at all on patcher open, close, new view, or delete.

I assume these are supposed to attach to my object’s immediate parentpatcher view, right?

Any further advice appreciated.

#148306
Feb 4, 2009 at 3:43pm

The jpatcher “getfreed” method prototype looks like this:

void jpatcher_getfreed(t_jpatcher *p, long *freed);

If you don’t pass in a valid pointer to a long as the second parameter then it will crash, as you saw.

Calling this from your object’s free method will tell you if you are inside the jpatcher’s free method or not as you are freed.

Rob

#148307
Feb 4, 2009 at 9:25pm

Thanks Rob! Hopefully we now have all the pieces in place, now I just need some free time to do the job (sigh).

#148308
Feb 6, 2009 at 3:18am

So for the record, here’s the code to check if a patcher p is being freed:

long freed = 0;
object_method(p, gensym(“getfreed”), &freed);
if(freed) { // patcher is being freed }

#148309

You must be logged in to reply to this topic.