jit.gl.pix bypass best practice ?

I always use your second suggestion (so [gate 2] combined with (enable $1) message to the jit.gl.pix). I found that easiest to abstract away and combine it with all gl.pix/slab objects. Don't know if performance-wise it makes a lot of difference.

Hi @julien bayle , I'm looking also after the perfect way to bypass certain gl.pix effects on my master chain.
I was very inspired by your forum post in which you showed your master chain with the different gl pix ( brcosa, flasher 2 .. ) and 4 meshes being affected.
I'm replicating more or less your general structure, but let's say you have 3 or 4 gl.pix effects and want to enable them or disable them individually with a toggle.
For example that was your patch:

How would you add a toggle on every individual gl.pix, so it's easy to enable one, two, both while having a good flow.

Thanks!
great work by the way, I follow you on different socials and I really like what you do.

I would use a [matrixctrl] or a [radiogroup] in checkbox mode. With radiogroup you can unjoin to toggle individual gates. With matrixctrl you can use [route].

Hi Timo! Thanks! I like your approach, and would use it.
But still have the need to organize how the individual toggles are connected to gl pix with the switches and the overall flow.
Could you build your solution on top of the patch I sent to enable/disable the gl pix? That's where I have the problem
Thanks!

Let me be a bit more clear, I want to have different jit gl pix processors and enable them individually in the most elegant way possible.
This doesn't 'work' as it's chosing or the "clean" path or the all "effected" path.
I would like to have one toggle for the wake fx , another one for the flasher, and so on..

Thanks!

hi there, I ended up, one year ago, with a bypass inside the jit.gl.pix by using ternary operator.

But this one ones works fine too and I like to directly disable the gl object like that. But for a process chain, it is easiest to use the first way, I think.

The first solution is so clean, I like it, and for my use case is perfect.
Thanks!!

Hi Julien, tried the solution but i think only works with custom made jit.gl.pix processors ( like your flasher ) . Do you think it's posible with max processors such as wake.genjit? When i do try the gen environment is blocked.

I ended up with something like this, doesn't seem very elegant though...

using @gen <something> arguments recall a previously stored gen patcher as an abstraction.
this is the "problem" here.