I have an issue with the time it takes to store a pattr preset before you can then trigger a new one.

Each time I trigger a new preset, it saves the current state at storage slot 0 (temporary) and then triggers a line object to interpolate from the current position to the new position over time. Ideally I want to be able to trigger new presets pseudo-rhythmically, and so if the system is still transitioning/interpolating it needs to save the current position on each trigger in order to fade properly to the next one without jumping around. I am saving/recalling about 56 values into pattrstorage each time.

So it works, but doing it this way seems to drag down performance compared to not saving the state on each trigger. I'm using a launchpad to trigger presets and the latency when hitting each pad gets a bit out of hand especially as I play faster.

Using a MBP from 2009, C2D 2.53GHz. Maybe I'm just asking to much of the computer to respond that quickly? Maybe someone has a better solution than doing it this way?

Each time I trigger a new preset, it saves the current state at storage slot 0 (temporary) and then triggers a line object to interpolate from the current position to the new position over time. Ideally I want to be able to trigger new presets pseudo-rhythmically, and so if the system is still transitioning/interpolating it needs to save the current position on each trigger in order to fade properly to the next one without jumping around. I am saving/recalling about 56 values into pattrstorage each time.  

So it works, but doing it this way seems to drag down performance compared to not saving the state on each trigger. I'm using a launchpad to trigger presets and the latency when hitting each pad gets a bit out of hand especially as I play faster. 

Hi everyone, 
I have an issue with the time it takes to store a pattr preset before you can then trigger a new one.
Here is the patch:
 
Eac

pattrstorage-timing

Nicely done: it's indeed cool to interpolate from any current state to a recorded preset. A couple of things came to mind:

use a second argument to [line], for instance 50 or more, then you might get rid of the [speedlim]. Depending on your specific application, use an even greater grain size for [line]: maybe for your specific system, using 100 or 200 ms would still sound great. That might make quite a difference in performance depending on your system.

this one won't change your performance, but since I saw your patch, here you go: use [pack] with the elements in the correct order, and use a [t b f] to trigger it, then you don't need [zl rev]

in case you find that storing the pattr state takes some time, you might try inserting a [deferlow] before triggering the new interpolation. I haven't tested it, but something along these lines:

Hi Jean-Francois, thanks for your suggestions! As it turns out, part of the larger project I'm using this presets patcher in makes use of your freeze patch (the first one in the spectral freeze folder on your website...) and I also have a question about that for you if you don't mind having a look!

You can see here that I have modified your freeze patch to hold each fft frame in a [jit.matrixset] object with 64 matrix slots - each one corresponding to a button on my launchpad. So here I can save and recall freeze moments with the controller, very fun!

Now I would like to adapt this method to work with the next one in that folder - stocha-freeze - since the freezes using a single frame are a bit... harsh sounding (which can be great!). It has been suggested to me that a far easier method would be to go the granular synthesis route and just loop a fraction of audio, but I suppose I'm more interested in the potential of manipulating that spectral data live. I'm pretty new to jitter but have used the [jit.matrix] object a bit to work with array data. I'm struggling to understand how I can get the 8 fft frames into a [jit.matrixset] object and recall them. Do you have any suggestions?

Hi Jean-Francois, thanks for your suggestions! As it turns out, part of the larger project I'm using this presets patcher in makes use of your freeze patch (the first one in the spectral freeze folder on your website...) and I also have a question about that for you if you don't mind having a look! 

Now I would like to adapt this method to work with the next one in that folder - stocha-freeze - since the freezes using a single frame are a bit... harsh sounding (which can be great!). It has been suggested to me that a far easier method would be to go the granular synthesis route and just loop a fraction of audio, but I suppose I'm more interested in the potential of manipulating that spectral data live. I'm pretty new to jitter but have used the [jit.matrix] object a bit to work with array data. I'm struggling to understand how I can get the 8 fft frames into a [jit.matrixset] object and recall them. Do you have any suggestions? 

Well, you could proceed very similarly to what you've done with the "1 fft frame" matrices. With matrices holding 8 fft frames, you have your jit.matrixset would just be a set of 64 matrices as well. The only difference is that the matrix is now [jit.matrix freeze8-record 2 float32 8 2048], so the matrix set would look like [jit.matrixset 64 2 float32 8 2048] for instance.

You could keep all the names of the matrices as they are. I shared several patches, so I assume you're working from the one called freeze8.pfft. The technique in this patch is slightly different than the single-frame case: here, I'm constantly recording in a matrix called freeze8-record. Upon a "freeze" request, I just push the current matrix into the matrix called freeze8-play. What you would do would be to push instead into the jit.matrixset, at the index you want.

Hope that helps. Don't hesitate to reply here in case you have further questions.

Thanks so much Jean-Francois that works perfectly! I have a couple more questions for you -

What is [noise~] doing running into [jit.peek~] ? I can see it is randomly selecting something (frames?) from the matrix to output as audio but I don't quite get what is going on.

Also, in your transit-freeze patch the transition between freezes appears to act like a volume crossfader. I'm wondering if instead it is possible to create a transition that interpolates the matrix contents between each freeze? So it would sound like a kind of non-linear frequency shifter acting on the spectrum to morph between freeze moments rather than volume crossfading. I'll have to do a lot more reading on FFTs but it should be achievable using some jitter object right?

Thanks again I really appreciate your help!

Thanks so much Jean-Francois that works perfectly! I have a couple more questions for you - 

What is [noise~] doing running into [jit.peek~] ? I can see it is randomly selecting something (frames?) from the matrix to output as audio but I don't quite get what is going on. 

- in my spectral freeze patches, I use a [noise~] object to select the frame number differently for each bin while re-synthesizing. I explain the process in this 

- transit-freeze makes a transition from a frozen sound to a new one working frequency bin per frequency bin. It is a kind of spectral cross-fade, indeed. What it doesn't do is moving energy across frequency bins. Another kind of spectral interpolation would track the prominent peaks in the spectrum and maybe make glissandi from old peaks to new peaks. No such thing here, if it's what you are talking about...

- in my spectral freeze patches, I use a [noise~] object to select the frame number differently for each bin while re-synthesizing. I explain the process in this tutorial on spectral processing.
- transit-freeze makes a transition from a frozen sound to a new one working frequency bin per frequency bin. It is a kind of spectral cross-fade, indeed. What it doesn't do is moving energy across frequency bins. Another kind of spectral interpolation would track the prominent peaks in the spectrum and maybe make glissandi from old peaks to new peaks. No such thing here, if it's what you are talking about...
Best, JF.

Ok cool, thanks for the link and I'll let you know when I work out how to build such a thing...

pattrstorage timing