How to detect if jit.gl.slab and jit.gl.pix are receiving active input?

Mar 6, 2012 at 7:56pm

How to detect if jit.gl.slab and jit.gl.pix are receiving active input?

I have a lot of jit.gl.slab and jit.gl.pix objects being connected randomly or arbitrarily into fx chains. I need to trigger/toggle various non-Jitter objects based on whether a given gl.slab/gl.pix is an active part of the chain. Does anybody know how can I easily/inexpensively sense whether an input signal is currently present/active on each individual gl.slab/gl.pix object?

Thanks!

#62193
Mar 7, 2012 at 1:30am

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.

#224624
Mar 7, 2012 at 3:48pm

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

#224625
Mar 7, 2012 at 5:12pm

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.

#224626
Mar 7, 2012 at 7:46pm

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

– Pasted Max Patch, click to expand. –
#224627
Mar 26, 2012 at 5:05pm

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:

– Pasted Max Patch, click to expand. –

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

Thanks again,

Jeff

#224628

You must be logged in to reply to this topic.