Checking for mute state of object inside poly~ instance

May 27, 2012 at 12:11pm

Checking for mute state of object inside poly~ instance

Hello devs,

Can anyone tell me how to determine whether or not an object, which is instantiated inside an instance of a poly~, is muted (using poly~’s mute message)? Checking l_obj.z.disabled inside the perform routine doesn’t work for this (as in below)…

if (x->l_obj.z_disabled) {


May 31, 2012 at 5:27am

I can’t believe that no one here knows something about this? I need help here, can not for the life of me find a way to detect mute status while inside a poly~. The z_disabled flag does not seem to be linked to this (although it does work using the mute~ object with a subpatch/abstraction. Help please?


May 31, 2012 at 6:46am


maybe try to get the “mutemap” attribute ?

May 31, 2012 at 7:09am


but it seems it’s not an attribute :(
but in that case what kind of method is it ?

May 31, 2012 at 7:19am

When an object is in a muted poly~ it’s perform method is just no longer called. until you unmute it. Is there a specific reason why you want to know that?

May 31, 2012 at 8:09am

I’m interested by your answer @Emmanuel.
By saying its perform method, you mean everything inside the poly~ (metro, other objects) ?

May 31, 2012 at 9:14am

Hi Emmanuel,

Without going into to too much detail here, my object accesses a CLASS_NOBOX object, shared amongst all objects with the same name attribute. I need to do something in each object’s perform routine, regardless of it’s mute state. Using the z_disabled flag I am still able to do these necessary tasks at every pass of the signal chain, when dsp is muted using mute~. I need to do the same thing when the dsp is muted inside a poly~. Wouldn’t it make sense to have the z_disabled flag update based on dsp muting status inside a poly~ as well?


May 31, 2012 at 10:17am


@julien bayle ; AFAIK emmanuel only speak about the callback method added to the DSP chain usually called “toto_perform”.

@zachary ; after few investigations it seems “mutemap” private function is not a good idea as it needs an outlet as argument :(

Jun 1, 2012 at 5:38pm


Do you or any other Cycling folks have pointers, examples, etc. showing how to make an object know it is inside a muted poly~? This is basically the last issue to be resolved in an object I’m working on, and I’ve been unable to come up with a way by myself. Would probably be worthwhile to post here for reference, in case others need to do something similar.


Jun 7, 2012 at 10:10am

No ideas from Cycling on this??? Is there just simply no way to know that you object is a muted instance of a poly~? Nicolas’s idea about mutemap would have been my guess as well, if it’s didn’t require an outlet.


Jun 7, 2012 at 10:14am

check thispoly~ object.


  1. thispoly.PNG
Jun 7, 2012 at 10:40am

I think that requires that a thispoly~ object always accompany an instantiation of my external, which I don’t want to require. I’m looking for a C API solution.

Jun 11, 2012 at 9:51am

Sorry but you’ll have to find a way to either have a thispoly~ object somewhere in your patch. There’s no way to figure this out from C. thispoly~ uses some private function to communicate with the poly~ object in the upper level.

Jun 11, 2012 at 10:51am


i tried to create a CLASS_BOX instance of thispoly~ inside an external to get “mute” info with something like :
bang_result = object_method (thisPolyObject, gensym("bang")); but i failed ;-)

is it a stupid way ?
is it possible to get an atomarray as result ?

Jun 12, 2012 at 7:16am

It’s not going to work. Thispoly~ needs to be instantiated in a patcher (to be able to find it’s parent poly~) not in your object.

Jun 12, 2012 at 10:47am


Thanks, i suspected something like that ; mais qui ne tente rien n’a rien. Sorry, Zachary no more idea ;-)

Jun 12, 2012 at 5:06pm

Thanks Emmanuel and Nicolas,

I guess for now, unless I can think of a redesign that avoids my current need for mute state knowledge inside a poly~, I’ll just need to accept this is a limitation of the object.



You must be logged in to reply to this topic.