Forums > Dev

Max 5: Check if patcher is being freed?

January 10, 2009 | 2:41 am

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


January 10, 2009 | 3:15 am

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
>


January 10, 2009 | 3:16 am

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)


January 10, 2009 | 6:27 am

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?


January 19, 2009 | 12:11 am

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.


February 4, 2009 | 3:43 pm

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


February 4, 2009 | 9:25 pm

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


February 6, 2009 | 3:18 am

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 }


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