PV bin shuffle - trigger

    Mar 22 2009 | 12:07 am
    I am writing a phase vocoder bin shuffle plugin but I am struggling to get things to talk properly. The issue is a trigger module: I am running the output of count~ into the input of trigger so that every time it changer bin no, the trig will send a bang to a urn patch. However... the trigger is not responding to the signal from count~.
    Is this normal? Is the fact that the input is a signal the issue? If so does anyone have any suggestions of another way of doing the same thing?
    Many thanks for your help.

    • Mar 22 2009 | 2:37 am
      the way you are attempting won't work because [count~] is outputting a signal and [trigger] works only in the control domain. The best way to go about this, in my opinion, is to generate your random values beforehand, store them in a [buffer~] and read them with [count~] or [fftin~] and [index~] in your [pfft~] patch. Here's an example.
    • Mar 23 2009 | 1:31 pm
      Many thanks - that's just what I was looking for. And it does make a lot more sense to read the values from a buffer too.
      On another note; is there any way that you can get hold on the index for individual bins in msp? I need a way to re-assign the index to bins, or tell them to move from their original position. I presume you cant do this by messing with the 'real' input to the iFFT as it will just create new amplitude values for a bin rather than simply offsetting them from their original position?
      Again - many thanks for your help Chris
    • Apr 01 2009 | 9:51 pm
      Sorry to bump an old thread.
      I have managed to construct my PV bin shuffler but despite getting it to 'work', I do have an issue still.
      I am getting quite a few metallic artifacts when turning the shuffle on. These are present even when the sample is not playing. Could it be a windowing problem or is it to do with the way I am shuffling the values? The issue is most noticable with quiet or delicate textural sounds.
      See below for the patch.
      Many thanks for you help Chris
    • Apr 02 2009 | 12:02 am
      could you attach your subpatches? the patch doesn't happen without them! (pvocbinshuff and win_hanning) cheers
    • Apr 02 2009 | 10:14 pm
      Sorry about that. I have build a collective and zipped it - any advice you can give will be greatly appreciated.
      Cheers Chris
    • Apr 03 2009 | 3:50 am
      Your patch uses a lot of "Max" processing to get the random process, that makes the UI very unresponsive on my PowerBook G4. There must be more efficient ways to deal with this in audio domain, playing with noise~ and the like. Congrats on making that in MSP land. I would definitely be more lazy and go the Jitter way to implement such an idea. For the moment, I just have my laptop speakers, and I must say I don't hear much of shuffling. Will try tomorrow with better hearing conditions... Jean-François.
    • Apr 03 2009 | 9:38 am
      I couldn't get your patch to work, but also could not help noticing that the algorithm you propose appears to be identical to what the FFTease object disarray~ does. A single disarray~ object runs on my 2GHz MacBook at about 10% CPU compared to 46% with the collective you posted. FFTease is at:
      Good luck, Eric
    • Apr 03 2009 | 12:07 pm
      Brilliant - many thanks for your help. I'm away now until Monday but will have a look at those plugins when I get back
    • Apr 03 2009 | 7:18 pm
      On another note - why is it easier to do this process in jitter? i don't have jitter sadly but its always interesting to know.
    • Apr 04 2009 | 1:30 am
      A sonogram is 2-dimensional data (time / frequency), 3-dimensional if you count the 2 planes you need to represent the whole data (amplitude and phase difference). A buffer is mono-dimensional (2-dimensional if you count the possibility of multi-channel). Manipulating a sonogram stored in a buffer is not intuitive because you navigate a 2-dimensional data stored as a flat line. With Jitter, you can directly address a data point by its (frame #, frequency bin). You can also leverage the Jitter functions to apply spectral processing more easily. For instance, applying a filter is no more than a multiplication of the "sonogram" matrix by a "filter" mask matrix. The good old forbidden-planet patch is fun, but what if you want to apply a filter that changes over time? You may download on my share page pedagogical patches for a Max/MSP/Jitter-based phase vocoder and more spectral processing. Even when you don't want to process a whole sonogram, Jitter may come handy (see spectral freeze examples). Your bin shuffler projects makes me think of the object [jit.repos]. You could have a look at Jitter tutorial 39. Jean-François Charles.
    • Apr 09 2009 | 10:28 pm
      Finally got around to trying the FFTease patches out - disarray is pretty much exactly what I wanted. Did you write this Eric? I'm intruiged as to how you got hold of the index of the bins on the MSP side? I could only find out how to maniplulate the phase values (hence my overly exuberant MAX construction).
      Thanks for pointing me towards those externals - there are some really useful programs there.