Doing complex operations at MSP's rate?


    Sep 10 2007 | 2:10 pm
    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:
    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.
    Thanks for any help you can offer.

    • Sep 10 2007 | 3:28 pm
      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
    • Sep 10 2007 | 3:59 pm
    • Sep 11 2007 | 12:06 pm
      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.
    • Sep 11 2007 | 4:47 pm
      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.
    • Sep 11 2007 | 5:00 pm
      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
    • Sep 13 2007 | 7:55 pm
      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