## Doing complex operations at MSP's rate?

Sep 10, 2007 at 2:10pm

# Doing complex operations at MSP's rate?

Hi, I’ve just started writing patches dealing with the MSP signal network. If Im understanding things correctly, Max gets permission to compute something every millisecond while MSP object act at a much faster rate. How do I make decisions and do complext operations at a faster rate (like every time a vector is computed)?

I’ve tried using large sequences of and, not & or obects but that won’t work for my latest patch.

Basically I have a pfft~ subpatch which takes in two signals computes the similarity between each cartesian point associated with each bin.
The next part Im unsure how to do.

For each FFT frame I want to store the similarity of each bin in a data structure (perhaps a list of some sort) and sort the list by similarity.
Perhaps I could use a buffer (or some variant) to store the values, the values stored would then be sorted before the patch moves on to the next frame. Then the process starts again.

Here is a rough outline:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 297 67 100 196617 incomming signal 2;
#N in 3;
#P newobj 505 90 25 196617 in 3;
#P newex 261 243 34 196617 !/~ 1;
#P newex 261 218 35 196617 sqrt~;
#P newex 261 194 27 196617 +~;
#P newex 302 157 27 196617 -~;
#P newex 228 157 27 196617 -~;
#P newex 315 90 45 196617 fftin~ 2;
#P newex 202 90 45 196617 fftin~ 1;
#P comment 183 159 41 196617 x1 – x2;
#P comment 332 159 41 196617 y1 – y2;
#P window linecount 2;
#P comment 300 239 100 196617 similarity (inverse distance);
#P comment 247 286 100 196617 STORE IN A DATASTRUCTURE.;
#P window linecount 5;
#P comment 250 344 100 196617 At the end of the cycle sort the values choose a value at position i for the next frame;
#P window linecount 2;
#P comment 478 60 100 196617 value chosen in previous frame;
#P window linecount 1;
#P comment 167 67 100 196617 incomming signal 1;
#P fasten 7 0 9 0 207 141 233 141;
#P fasten 8 0 9 1 320 142 250 142;
#P fasten 9 0 11 0 233 185 266 185;
#P connect 11 0 12 0;
#P connect 12 0 13 0;
#P fasten 10 0 11 1 307 185 283 185;
#P fasten 7 1 10 0 224 125 307 125;
#P fasten 8 1 10 1 337 152 324 152;
#P window clipboard copycount 16;

The basic idea is to swap cartesian points of the two signals based on similarity and a threshold of minimum similarity computed from the previous frame (so I can control what fraction of points get swapped).

You probably dont need to understand the whole reasoning behind the patch. I just need to know how to store the similarity values, sort them and pass a chosen value from the sorted list to be used in the next fft frame.

#33620
Sep 10, 2007 at 3:28pm

sounds like you want to record those values into a buffer via poke~, then read it out via index~ to do the comparison. main difficulty will be in synchronising these processes accurately…

j

#112207
Sep 10, 2007 at 3:59pm

#112208
Sep 11, 2007 at 12:06pm

I was hoping that I could feed in audio to be processed in real time, the values would have to be sorted before the patch moves on to the next fft frame. Sorting 512 or 1024 values should be relatively fast for a modern machine I would imagine.
Is this wishful thinking?

Another option would be to sort the values as they are inserted into the buffer, this would involve moving some values around with each insertion which might get tricky.

#112209
Sep 11, 2007 at 4:47pm

Quote: digiology wrote on Tue, 11 September 2007 06:06
—————————————————-
> I was hoping that I could feed in audio to be processed in real time, the values would have to be sorted before the patch moves on to the next fft frame. Sorting 512 or 1024 values should be relatively fast for a modern machine I would imagine.
> Is this wishful thinking?
>

i think in order to be able to “sort” samples
without transforming them into messages you
would need to write them all into individual buffers.

when it comes to fft bins you might find the one or
other third party external specificaly for fft jobs.

>
> Another option would be to sort the values as they are inserted into the buffer, this would involve moving some values around with each insertion which might get tricky.
—————————————————-

very basic sorting jobs could include objects
such as [>~] and [delay~] but for more
complicated stuff you will probabyl had
to make too many signal connections.

and when you start using buffer/index mechanisms inside
an fft it can get hard to care for all the delay times.

#112210
Sep 11, 2007 at 5:00pm

I think Im going to go about this problem a little differently. As I explained briefly before the basic idea of the finished patch is to measure the similarity inverse distance) between the cartesian points of two frequency domain signals.

The user specifies the fraction of points to be swapped and the most similar points are chosen based on inverse distance. The minimum similarity required for a swap is estimated based on anaylsis of the last frame (thats where the sorting comes in).

Instead I can simply use a more crude method for estimating this threshold by using the average similarity in the last frame (using average~) plus an offset which will be increased or decreased frame by frame so that the threshold estimate gets closer to the desired value after a few frames.

I have the basics of this implemented but I want to tidy it up before posting it. If you have any better solutions or if you want me to clarify anything please let me know.

Ross

#112211
Sep 13, 2007 at 7:55pm

Ross schrieb:
> I was hoping that I could feed in audio to be processed in real time,
> the values would have to be sorted before the patch moves on to the
> next fft frame. Sorting 512 or 1024 values should be relatively fast
> for a modern machine I would imagine. Is this wishful thinking?

No you can do this easily in Java and mxj~…

Stefan

Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#112212

You must be logged in to reply to this topic.