An input is being sent to one of these objects if a message like jit_matrix xxxxxx or jit_gl_texture xxxxxx is going into one of their inlets. In the simple case where you have no other messages going into these objects, you could simply put a [t l x x x] where x is something you want to do and l is the incoming list. Basically, the idea is to use the trigger object to perform multiple tasks.

If you're detecting of the left inlet and have multiple messages coming in such as parameters, you'll need to generate events off of that jit_matrix of jit_gl_texture messages. You can do this with route or routepass.

Thanks, Wes! While your reply clarified some things and gave me ideas to try, I'm still stuck. Specifically, I need to toggle mute~ on for a related subpatcher if there is no incoming signal to a jit.gl.slab or jit.gl.pix object. Conversely, I need to toggle mute~ back off when a slab/pix input is present. For extra fun (and clarity), mute~ needs to be on with the slab/pix input is conceptually "off" and vice versa. I have a lot of slabs like this, so I need to do this inexpensively to avoid bogging the system with analysis. I don't need to parse out param messages, thx. Seems like your [t l x x x] suggestion might be applicable, but I'm just not seeming to connect all the dots. Any further insights appreciated!

Thanks again!

Jeff

Hi Jeff, I think it would be really helpful if you could post a simple example of what you're trying to do since it's really specific to your situation. I imagine your patch is big, but I bet the small task you're describing could be made into a bite-sized patch.

i would do something like the following (this uses matrices instead of textures, but should work the same):

Thanks all. I was successful with a different direction and I thought I'd share in case it helps someone else... or if somebody can point to a simpler solution. ;) (Wesley, trying to excerpt a small troubleshoot example that actually functioned turned out to be more difficult than it sounds. Robert, your solution didn't hit the nail on the head.)

The first thing I did was take some advice from other threads and move away from the mute~ object (depricated I believe) as applied to a bpatcher, implementing with a mute message to a poly~ instead.

My goal was to sense whether a slab is receiving an active (clocked) signal (due to whether the slab is actively switched into a chain of fx slabs), for the purpose of unmuting a poly~ if active/clocked texture and muting the poly~ if inactive/unclocked texture. The big hurdle wasn't in sensing if texture was active/clocked, but whether it had stopped. I needed something akin to a gate or weighted switch that automatically closed when nothing was forcing it open... and I couldn't find a single existing object that does that and is compatible with textures. My solution was to use the parent patcher's metro to clock a getstate message into jit.fpsgui. This then allows a change object to determine if fps has fallen to zero (inactive/unclocked).

Here's a partial patch to illustrate:

Hope this helps somebody else. And, again, if anybody sees a simpler way to do this, I'm all ears!

Thanks again,

Jeff