jeffburger

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?

how-to-detect-if-jit-gl-slab-and-jit-gl-pix-are-receiving-active-input

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.

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!

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.

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.


(this uses matrices instead of textures, but should work the same):

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).

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

Hi Jeff this is really useful. Could you accomplished a more efficient solution?

I ran into a similar problem today of needing to determine whether a matrix/texture signal to a jit.gl.slab had stopped, and I came up with a simple timeout circuit based on [delay] and [onebang] that should work with any type of input. The left outlet of the [onebang] will output bangs as long as the input signal comes in, and once the input has stopped, the right outlet will output a bang after the timeout specified by the [delay]. Hope this helps anyone else who comes across this thread!

Hi,
I ran into a similar problem today of needing to determine whether a matrix/texture signal to a jit.gl.slab had stopped, and I came up with a simple timeout circuit based on [delay] and [onebang] that should work with any type of input. The left outlet of the [onebang] will output bangs as long as the input signal comes in, and once the input has stopped, the right outlet will output a bang after the timeout specified by the [delay]. Hope this helps anyone else who comes across this thread!

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