toddak

I'm writing a patch for visuals for a performance piece, where I want specific pixels in a still image to show depending on the audio.

For the moment, I have a patch working using analyzer~ and feeding of three different sinusoidal components of frequency to determine the RGB values to search for, and they are scaled accordingly.

Currently, using a jit.op with [pass == == ==] as the argument seems to be providing good results.

However, from re tracing my patch, what I believe it to be doing is searching for one value in the Red plane. When it finds a value that equals the number generated by analyzer~, it sends it to the jitter matrix, then off to the window, and it displays.

At the same time, its doing the same thing for the Green and Blue planes.

Consequently, the image pixels never looks like the original image pixels. Its quite interesting none the less! And will be used at a later date, the joys of experimenting!

However, if I wanted to search though a jitter matrix for one location that had a specific colour, for example R=255 G=255 B=255, and display only that colour pixel in the next matrix, what would I use?

I seem to be giving it headaches with a very convoluted jit.iter patch... :(

Currently, using a jit.op with [pass == == ==] as the argument seems to be providing good results. 

However, from re tracing my patch, what I believe it to be doing is searching for one value in the Red plane. When it finds a value that equals the number generated by analyzer~, it sends it to the jitter matrix, then off to the window, and it displays. 

I seem to be giving it headaches with a very convoluted jit.iter patch... :(


looking-up-a-colour-value-in-a-still-imagejitter-matrix

From what you say, It sounds like each plane is getting compared independently of any other plane - which makes sense. If you persist with this method you will need some logical comparison to check that *all* 3 planes are outputting their respective matched value before any output is allowed. (Value R & Value G & Value B)

A couple of alternate strategies: either combine the three planes into a single 24 or 32 bit value and then search for the specific RGB value in that format, or alternately it could be done using jit.expr - Where the value for every plane is matched to your criteria before the output is true. - if you can determine the correct expression.

There may a simpler way but it hasn't occurred to me while replying.

A couple of alternate strategies: either combine the three planes into a single 24 or 32 bit value and then search for the specific RGB value in that format, or alternately it could be done using jit.expr  - Where the value for every plane is matched to your criteria before the output is true. -  if you can determine the correct expression. 

There may a simpler way but it hasn't occurred to me while replying.


I figured I was up to the stage on constructing logic, and was looking into various functions in zl to see if that would help. Perhaps its time I jump into the deep end and start understanding the logic required work jit.expr.

In regards to converting three planes into a 24 or 32 bit value, and then searching for that value, how does this process work? Recommendations of objects would be great, as I'm a little lost on this concept! I think I've seen this used in a type of coll storage situation, but it did baffle me a little as to how it worked.

And on the note of coll, am I right to assume that this is a little basic for my needs?

Sorry for all the question, I'm a little new to the idea of storing data as lists, and retrieving data from those lists :)

In regards to converting three planes into a 24 or 32 bit value, and then searching for that value, how does this process work? Recommendations of objects would be great, as I'm a little lost on this concept! I think I've seen this used in a type of coll storage situation, but it did baffle me a little as to how it worked. 

And on the note of coll, am I right to assume that this is a little basic for my needs? 

Sorry for all the question, I'm a little new to the idea of storing data as lists, and retrieving data from those lists :)


I ended up using a collection of jit.ops. - 3 to test for the specific R G and B values and another 3 to logically AND the results of each colour plane. The problem I see with this is that the result is very "binary" pixels are eeither active with the precise RGB value, or they aren't- you may be better placed looking for a range of values rather than just one specific value but this is more an aesthetic issue and it is what I understand you were looking to get.

There is a suckah object above the top window to select the colour - Interestingly this Suckah didn't work properly on my second monitor - giving different values to those expected - which had me looking for a logical problem for some time where there wasn't! - DOH! - I suspect this comes back to the colour profile set on the monitor. Traps for players (and people with dodgy color vision).

If this what you are after you won't need to convert to a 32 bit long) value - which means packing the ARGB values from each plane of a 4 plane matrix into a single 32 bit integer (search for "ARGB Java" to find out how) As far as using colls in this context - I can't see its any advantage over using jitter objects.

I ended up using a collection of jit.ops.  - 3 to test for the specific R G and B values and another 3 to logically AND the results of each colour plane. The problem I see with this is that the result is very "binary" pixels are eeither active with the precise RGB value, or they aren't- you may be better placed looking for a range of values rather than just one specific value but this is more an aesthetic issue and it is what I understand you were looking to get. 

There is a suckah object above  the top window to select the colour - Interestingly this Suckah didn't work properly on my second monitor  - giving different values to those expected -  which had me looking for a logical problem for some time where there wasn't! - DOH! - I suspect this comes back to the colour profile set on the monitor. Traps for players (and people with dodgy color vision).

If this what you are after you won't need to convert to a 32 bit long) value  - which means packing the ARGB values from each plane of a 4 plane matrix into a single 32 bit integer (search for "ARGB Java" to find out how)  As far as using colls in this context -  I can't see its any advantage over using jitter objects.


I see what you mean. I just wanted to see exactly what it would do I guess :)

How do I search for a range of values instead? As in within a particular threshhold?

My knowledge of language for jit.op is pretty limited, I guess with the 'logic' calculations. Also, would you be able to explain the difference between an argument and an '@' argument?

How do I search for a range of values instead? As in within a particular threshhold? 

My knowledge of language for jit.op is pretty limited, I guess with the 'logic' calculations. Also, would you be able to explain the difference between an argument and an '@' argument?


i guess you need to change the @op == for @op < or @op > and play with the paremeter..

btw theres another method to do similar task with jit.expr...

but be ready, jit.expr realms are somehow dark... still to me...

i did a small explantation in the patch...

isnt a perfect method because the color components, but you can develop the expression to be more precise using more operations and thersholds..

btw theres another method to do similar task with jit.expr...
but be ready, jit.expr realms are somehow dark... still to me...
i did a small explantation in the patch...

Wow... that may take me sometime to understand Carsol!

But thanks for posting! Shall have a tweak and a play and see what happens, many thanks!

Looking up a colour value in a still image/jitter matrix