stacking multiple jit.gl.slabs
I’ve got a chain of slabs that I like, is there any advantage processor efficiency wise to taking those shaders and compiling them down to a single slab?
There can be. It really depends on how big the one shader gets versus how how much your graphics card can handle. There really isn’t an exact rule.
It’s a suck it and see situation? Cheers.
sounds like a good opportunity to try out jit.gl.pix
Indeed it was… have to say having forced myself to sit and play with jit.gl.pix that it is a truly awesome addition to jitter. Being able to fiddle with shaders in graphical land or use codeboxes as required rather than code in textedit and then reload your slab is well wicked, you can just reroute the output to whatever bit of the patch you’re trying to understand, so quick to muck about with.
How do you know when you’ve reached the limit your card can handle, right now I’ve got a shader that does scale bias, brightness, contrast and saturate. When I try to add more (I want a colour splitter and a ripple repos) I start by adding a [sample] but it won’t let me connect to it.
Also I start getting messages at the max window that lua isn’t happy.
Does this mean I’ve filled this shader?
Does this mean I’ve filled this shader?
no, it means you’re likely found a bug. Can you post the patch that causes problems?
It’s bigger than the sun, here is just the shader, it’s not posting any errors to the max window anymore but it still won’t let me resample the output of the first stage.
----------begin_max5_patcher---------- 727.3ocyW1rbaBCDG+L9oPCWZOj3ADeDHmZu1WgNc7HCqwJEjHRhX2lIu6UR .oNM3DbCAmwyfFsHo8+9yqVItegi6Z9dP5htF8cjiy8KbbrlLFb5563VQ1mU Rj1g4lwqp.lx8h12of8Jq8u0HUncDlBo3Hohl8SjZKfx3Lkd3RDeCRB5d4nZ 5dDkg1PE5YrtQgn5IxYeRgJAEpBPW+49UujxzyogYcQPmQVSEuQoGqUPdcV2 ncjj9avXyGur2bMQkskxJVIfLUabFii0uFgSrM9QdllvjkdnezMIZtMj3qu4 R+qbOvALRk0AteUPIkt+UPTVud7M1dXwByiKFISYvNsudFRugpVVTtzvKi5Q eo.XHQU8kBZccI3NHOvmLOB8RWFo4QZfkGwWYoi2A7nc4U+pFZmgQYqJJWYT ZiPKDjq6fvK5DgGd5fmN0R+CDD4Q.UvICJ+zPKgBRMMigSqIrBCc5aakyfnJ 3rmmI.VNHroZSUpUGwvd1Tq1DrwQrggD9rCo6n4.utjvft8jJAgI2vEU5vVp qegmJ1EDaSyBZy1vcEsd0skUDkft+3Hz+CX8LXyFc+Ky1RnrIFe3PrcOaZ5z UUy67hvcTVNe26w9zfXeSSR7abeZ5L.HEun3XmA5+pQZTa5viOOdfRMW9XfX Lw8QmHzQnBDq.FYcIb3kRduRCtU6PAGE8xg+oexlmcyRTxH++eHtDNCG4WAR Io.dFV30.apPRW8C+X60CCrG16m7RHYPbDb9tAjoVws5JtBx5otnZ644sn4s ejzanZgc8relv+7QLVwar+TtI4Mhrds0euKj+ixJGze5Binnb1gCROl+Fiao 44.6vs44ToYmuMj7F7OvSRN3WSN3YSOgOwSGQNAyKd793fG+wHGu4SNdiQOy W1bxHjS3rolQk67epl15Pj556.graIsBQWo9FtvzM9BaWJqsqcEcEvcz9wGs vrZOr3O.KgnIeC -----------end_max5_patcher-----------
In the gen world, the only thing you connect to the input of [sample] is an [in] operator. It won’t let you connect anything else by design. The [in] operators represent two different concepts simultaneously, which is probably what’s causing some confusion. They are:
1) The current pixel/cell being processed
2) a proxy for the entire input matrix/texture
When you connect [in] to any operator except [sample], you’re connecting the current pixel being processed to that operator (1). When you connect [in] to [sample], you’re connecting the entire input matrix to it (2). This is because [sample] can pull an arbitrary pixel from a given input. All other ops can only work with the current pixel flowing through the gen patcher.
In your genjit patches, I noticed you had [in 1] -> [sample] with a [norm] connected to the second [sample] inlet. You actually don’t need this. The following are equivalent:
----------begin_max5_patcher---------- 354.3ocwT1sTCCBDE9ZxSACWWcBIosp24ygSGGZBZoSxRFfTq1ou6FVRzTmZ +QGs2Pxd1kkCePxlHBatdszxn2QefRHahHDTxKP5hIrJw57RgEKiAxWzyWxF ER4jqcnrBn7dwmzfypdS5SvStNtSFZpTPozg8Yfntw0qx6TqEt7EJ34GMxbW vciiaaDkm4GSw2SZGoy5lgp.sQq0tZGe.hJzGr6MJQYelvR5dsVFZNiQm4yr MJxOL52wBPap9SYQZ73Av3lCAijKMLrhp5R44fijyEG7oSB33V+iv32wizKM OZ6948kBeu3H9n3HiiWLRmdHbjc.bLXOiSkUpfu9uBb4856BBqtwj2iutqgz OMPgz5TfvozvfZZOZn7OpYgpnPBC2pEJqXdoDMe7dOPNU2vOQ2D+u3lzSvMY +P2DN3D00qjFaWKQizdWco13CmLBCUPHD6HyHWo5qeZjuaaidGPupgFW -----------end_max5_patcher-----------
----------begin_max5_patcher---------- 291.3ocoR1sSDBCDE951mhldMZnq3hw674vrwTfQ2YCzRZKqna12coCPD7mM w3MMcNyzSO8CNwYxBaO3kh6EOJXrSbFijhBroZlrQ2WVq8zXRC7ps3fLYrU. 5CjLZDpYwmslfGeGhMTatNcR1z0flZHP9rPz1ElUUSps5P4dz7xSNnLLltaS GLRnxhq2P62LrJ1McBrhhwPztZUNL5FJGxGbntdty3UFdqEFMWJE6hcNy4wk j+GKFb+uAC0OBizeGFp7sQBjotivQ9kvQ1Evwh2LcTYMZ95uCz0G0WCBusyU NiuIrK9L.UfOfFc.slEyjsZl8XUEXV9TqPutnFnvm9svoaaOBN+jkTPF9dbv 5hkaSnRzLVRNJcvQbd9bdzsy7O.+o0ZP -----------end_max5_patcher-----------
If you run the two gen patchers above, you’ll see that using [sample] in this way and simply passing through [in] are the same.
If you want to chain effects like a brcosa and then a repos type displacement, you’ll have to chain separate gl.pix objects together. You can’t sample from anything except the input, so you can’t sample from the end of a processing chain like you were trying to do. The entire processed image simply isn’t available at that time.
Hope this all makes sense. If anything is confusing, please ask.
That makes sense (as much as anything shader related does).