I think perhaps one of the problems expressed here (though I'm not sure which one!) has to do with the dual-precision internal processing vs. single-precision external save/retrieve limitation present in all versions of Pd, with the exception (I assume, haven't tried it yet) of the experimental dual-precision build that was produced some time ago.

I unexpectedly ran into the issue myself when trying to set up dynamic color programming of the GUI objects after making a whole panel of them using the preset colors from the preferences panel. I noticed immediately that most of the 0-29 preset color numbers that I sent with messages obviously didn't quite match the 30 presets available in the panel grid. So I tried grabbing the RGB values instead by plugging them into the "pd RGB" calculator that's part of the GUI color edit help patch. Those wouldn't save properly. I must assume at this point that it's because those panel colors are all linked internally in Pd to the 6 digit hex value you can see in the "compose color" RGB pop-up panel. Many of those hex values translate to dual-precision decimal numbers, (which can't be saved without the app rounding them off) and on the external user-programmable level Pd only works with decimals, not hex.

What it comes down to is that although you can enter or generate dual-precision decimal values in realtime (like with "pd RGB"). You can't save/retrieve them without the numbers getting rounded.

My workaround to match the panel presets was to just fudge the single-precision decimals till I got it "close enough". The only other workaround I can think of to get it exactly right is to save the three RGB numbers as a list and then feed them with [unpack] to the pd RGB calc and embed the whole blob into the patch every time I wanted to switch some colors.

The various Pd sites and lists have a number of write-ups about the dual/single precision issues. There's also some stuff on the list somewhere about the 2 different sets of preset colors (I think the remote-switchable preset values all translate to single precision dec values, not sure). Don't have any links on hand ATM but the info can be found in many bits and pieces (like most of the info on this platform) if anyone is more interested in this topic.

@phil123456 It would work but you can't do the calc in the message. If you just want to change the background you would send the message
[color value( but it needs to be calculated first. You could certainly simplify the patch I posted. If you stick a [print] on the output of [color $1 $2 $3( you will see that it "means" [color back front label( so in fact the color number ($1 being the one you are looking for) is one value (no longer rgb) and although I haven't checked I would guess that it is the decimal equivalent of the standard hex color value........
David.

@delphineTA I have very slightly advanced on your patch....... "colours.pd" is what we call an abstraction. You can place it as an object by putting the object [colours] and then connecting to its inlets (left inlet bold colour, right inlet brightness).
colours3.zip
open your "number_by_colours.pd" patch............ (we never put spaces in names, because they are special....... you will see why later).......

You still need to add some strong colours........ like cyan? [0 110 90( to the colours.pd abstraction so as to get to your 12 colours!

I have placed it twice in your patch. Because it contains $0 as a variable every instance is an "individual" copy and they do not interfere with each other.
So.......... if you edit colours.pd then you will edit every copy used in your patch. It's as though you typed [random].......... you can use it as often as you like (but keep it in the same folder so that Pd can find it.
I know....... I am hitting you with new stuff that is a bit hard to understand, but once you get your head around it the power of Pd will be yours!!
You will see as well that I am using the "Graph_on_Parent" red box (that you could not get rid of), so as to show the coloured canvas in colours.pd on your ("parent") patch......... enjoy!
David.

@delphineTA Hello again Delphine...
Sorry, I have no time to build you the patch straight away (someone else might) but here is a pointer..... Magic.zip
Open the file "no_magic" as the other one is just for fun, and rather confusing.......(that was a health warning!!).....

To get rid of your red rectangle "right click" on your canvas and de-select "Graph_on_Parent".

In my patch click the top bang, or press key 1 on your keyboard.
As you will see, you can fade out a colour because 255 255 255 is white, so you just need to reduce the 3 values progressively from your strong colour selection.
You need to make good strong colours from the rainbow for your left slider, and you can send messages (as in my patch above) to set those colours. Then for your right fader divide those colour numbers by the fader number to get the colour brightness (s)....
David.

number by colours.pd

Thanks so much for your input.

I am trying to colour a canvas with the sliders controlling the colour. Where I want the left slider to be just green (for 6 times tables lets say), I want the right slider to control shades of green (1 being very pale green, 12 being very dark green)

So for kids with difficulty learning multiplication the have a visual colour reference. For example they can remember that the 5 times tables are red. 5x1= very pale red, 5x2 is slightly darker etc etc and 5x12 is dark red. 6 times tables are green, 7 times tables are orange etc etc.

Where some people have perfect pitch some have perfect perception of colour.

Please excuse my messy little patch, the notes are my way of not forgetting what I want to do!! I've only been doing this for a few weeks so I'm still quite confused by alot of it.

Thanks again for taking the time,
Cheers.

[rfft~]/[rifft~] makes the assumption that you only intend to work with real signals (i.e. no imaginary part). [fft~]/[ifft~] will work with real and complex signals (real and imaginary part).

With real signals, if you do a spectral analysis from 0 Hz all the way up to the sampling rate, you'll find that the spectrum between Nyquist and the sampling rate is a mirror image of the spectrum between 0 Hz and Nyquist. (When you think about it, it makes sense; a frequency above Nyquist will alias below to another frequency, so to a digital signal both those frequencies are really the same thing.) Since they are just mirror images, it is computationally pointless to calculate the second half of the spectrum after calculating the first half, because we already know it. So [rfft~] doesn't compute the frequencies above Nyquist, and [rifft~] assumes the spectrum should be mirrored and so doesn't calculate an imaginary part for the synthesized signal. In other words, they're more efficient.

Complex signals, on the other hand, may not have a mirrored spectrum. In that case, you need to use [fft~]/[ifft~] to calculate the full spectrum. Music signals are typically real, though, so for most situations it is best to use [rfft~].

Also, just to be clear, the real or complex signals I'm talking about here are in the time domain. In the frequency domain they will always be complex.

Hi guys,

i'm trying to implement a system to track robots by a webcam. My problem is, it is difficult to track more than one robot with the PIX basic objects.

My system comport three robots identified by plates of different vivid colors, red, green and blue, and a platform with amoeba form that probably will be white or black in the final.

I've already tried to implement the track with pix_movement and it worked very well with just one robot. To work with two robots i thought it would be better to separate the RGBA matrix, to focus in each color, and have a functional track of each robot separately. BUUUT, it did not work very well, because the separated matrix did not present a good contrast of the predominant color, as a nice and big red mark over the red robot, for example, Instead of it, i had a very messy image caused by the interference of the background colors.

to filter and track the image i used:
pix_separator - to use 3 different images
pix_threshold - to keep just the wanted color, if it is high enough
pix_gain - to intensify the required color
pix_movement - to track the movement of the robot
pix_blob - to track the center of mass

One solution i thought its to use a filter that can recognize the image in another format, not RGBA, a format that differ colors, saturation and highness in different values and scales. Does it exists?

Thanks very much for reading it, i would be very glad if you could help me! =)

Hello djbigh:
I think that you will have to deal with colour spaces. The image that is shown in the link you posted is a non linear representation of the RGB colour space. It seems that in the picture the vertical axis is value or saturation and horizontal axis is hue in an HSV colour space. Please note that the scale of gray is shown on top of the picture. For a mathematical conversion this could be a drawback.
If you need colours and not grayscales such representation could be useful for you. I searched in the web for some algorithm that could give us the pixel colour in RGB as a result of X and Y coordinates. I found these following link useful:

http://en.wikipedia.org/wiki/HSL_and_HSV
http://www.easyrgb.com/index.php?X=MATH&H=21#text21

Good luck!

Sumidero

PD: I'm sorry it is quite late and my neurons do not respond at full capacity so as to give a proper answer or patch.

I would like to create an RGB color picker based on the the XY color spectrum. I have some LEDS and would like to select the color using the spectrum rather the three faders. this would require controlling the 3 faders using only 2.

I created a patch but could only get this far.

any help would be greatly appreciated. Thank you in advance.

here is a link of what i'm talking about.

http://www.google.com/imgres?imgurl=http://blommit.com/wp-content/uploads/2008/12/spectrum.jpg&imgrefurl=http://blommit.com/2008/12/27/the-ones-we-cant-see/&h=400&w=600&sz=21&tbnid=HguLqKMqh9ywVM:&tbnh=90&tbnw=135&prev=/images%3Fq%3Dcolor%2Bspectrum&zoom=1&q=color+spectrum&usg=__iomySBgMqPG4XqpLHr0-rpOReG8=&sa=X&ei=PP1ZTYqNNcTYgAe4zLCdDQ&ved=0CCYQ9QEwAA

http://www.pdpatchrepo.info/hurleur/X_Y_spectrum_picker.pd

@lead said:

maybe process the lists from cartesian to polar coordinates (or visa versa) then *-1 +1?

Not sure what you mean exactly. Admittedly, my suggestion was rather cryptic as well.

Anyway, I was thinking about the situation of a test signal: how long is that signal? Probably too long to fit in one fft frame of reasonable length. In that case, I don't think you can invert it's phase spectrum in frequency domain. But no problem: just do a time reversal in signal domain, and it's phase spectrum will be inverted automatically. To be explicit here: I mean you must time-reverse the samples of the original test sweep (not the test result signals). Time reversal does not change the magnitude spectrum, only the phase spectrum.

So remains inverting the magnitude spectrum of the time-reversed test sweep. A log sweep does not have a flat magnitude spectrum, so you need to compute the multiplicative inverse of the magnitude coefficients (in frequency domain, using polar coordinates indeed here). Beware of possible zero-magnitude points in the original, they can not be inverted of course. After magnitude inversion, go back to cartesian coordinates and from them to time domain. Now you have your deconvolution kernel in time domain.

The deconvolution kernel is the test sweep with phase and magnitude spectrum inverted. It can be considered a (very long) FIR filter. With this kernel you can do fast convolution of the test results, to deconvolve these. For this, you can use Ben Saylor's [partconv~] object. It does 'partitioned convolution' in frequency domain, with zero padding to avoid circular convolution.

Good luck. Please let us know if you have succes. It is an interesting technique to create impulse responses of acoustic conditions. Expensive reverb simulators probably rely on similar techniques. What is actually your purpose for it?

Katja