I'm using the subtex_matrix message to get a portion of a texture.

attrui

counter

comment

button

jit.matrix

message

jit.gl.videoplane

flonum

jit.gl.slab

loadbang

loadmess

jit.noise

jit.pwindow

number

join

substitute

toggle

jit.world

jit.gl.texture

Hello,
I'm using the subtex_matrix message to get a portion of a texture.
But what the slab can't work ?


jit-gl-texture-"usescrdim"-is-not-a-valid-attribute-argument

my topic becomes why do you have to bang the jit.gl.slab to get it working ?

my topic becomes why do you have to bang the jit.gl.slab to get it working ?
Really ??


Without a bang, it simply doesn't render.

of course the chain receives a bang from the metro.

Unfortunately jit.gl.slab doesn't render : it needs its own bang.

@Herr Markant
Just look at the top of the patch 
of course the chain receives a bang from the metro.
Unfortunately jit.gl.slab doesn't render : it needs its own bang.
What do you think?

The thing is that the gl.texture is actually also not outputting any bangs (or its texture for that matter, as you will see if you connect a button or message to it). But because the texture is connected to the gl.videoplane the videoplane has received it's texture name and will therefore update the visuals when the texture changes, not via the patchcord, but via the "invisible" connection it has from the texture name. Long story short, just send your jit.world metro bang to the gl.texture and from there on everything will work per render of the frame.

The left context has a proper bang via the received metro, the right one only has a loadbang. And thats probably the problem. The loadbang gets initialized before the main renderer starts.

I think the omission of the metro bang for the gl.texture/gl.slab is intentional in this patch (to save performance or something). I do this very often in my own patches. But if I'm wrong, just let me know...

I think the omission of the metro bang for the gl.texture/gl.slab is intentional in this patch (to save  performance or something).  I do this very often in my own patches. But if I'm wrong, just let me know...

I think the problem is deeper, there is something non-logic in the way it works.

Each render chain has a proper and similar bang at the top of the chain.

The slab shouldn't have this need of a new bang.

I hope c74 ingeniors would eventually correct the way things on GPU work because in complexe scenes it becomes hard to debug.

I think the problem is deeper, there is something non-logic in the way it works.
Each render chain has a proper and similar bang at the top of the chain.
The slab shouldn't have this need of a new bang.
I hope c74 ingeniors would eventually correct  the way things on GPU work because in complexe scenes it becomes hard to debug.



jit.gl.slab (and pix and texture) need either an input (texture or matrix) at the left-most inlet, or a bang, in order to output. in your patch the slab is not receiving a texture or matrix, and therefore needs a bang in order to output. this is both logical (allowing for user-defined texture processing chains) and has functioned this way for close to two decades.

if your question is why is the texture connected to the slab not outputting, the answer is the same: it is receiving neither a bang or an input (matrix or texture). A debate could be that the 

 message should trigger output, but all I can say is that it doesn't, and therefore the texture needs a bang to trigger it's output after modifying the contents via 

debugging this would have simply been a matter of throwing some bang buttons after each output to determine what was not outputting as expected. fixing is simply a matter of adding a 

 as the left-most outlet of your trigger (to fire after the subtex_matrix message), and connecting to the jit.gl.texture

jit.gl.slab (and pix and texture) need either an input (texture or matrix) at the left-most inlet, or a bang, in order to output. in your patch the slab is not receiving a texture or matrix, and therefore needs a bang in order to output. this is both logical (allowing for user-defined texture processing chains) and has functioned this way for close to two decades. 

if your question is why is the texture connected to the slab not outputting, the answer is the same: it is receiving neither a bang or an input (matrix or texture). A debate could be that the subtex_matrix message should trigger output, but all I can say is that it doesn't, and therefore the texture needs a bang to trigger it's output after modifying the contents via subtex_matrix.

debugging this would have simply been a matter of throwing some bang buttons after each output to determine what was not outputting as expected. fixing is simply a matter of adding a b as the left-most outlet of your trigger (to fire after the subtex_matrix message), and connecting to the jit.gl.texture

Mmm .. subtex_matrix is not seen as a matrix nor a texture ...thanks for clarifying me. Fortunately the support is great :)

Mmm ..  subtex_matrix is not seen as a matrix nor a texture ...thanks for clarifying me. Fortunately the support is great :)




process a subtex in a gl chain