willyc

Hi, apologies if this is repeating old ground, but trying to search 'preset' and 'pattrstorage' tends to brings up results about a preset within an xml, and not the object called preset....

When working with pattrstorage I am fully aware the preset object can be 'attacehed' to it and used as a lovely single-click interface for recalling/storing presets (which automatically 'knows' how many presets exist in a loaded xml...)

However, it appears in doing this I am losing the ability to interpolate between presets stored presets.

Specifically, I have a synth where all the UI elements have scripting names and hence synth presets can be managed via pattrstorage.

I would like to implement 'morphing' between presets over a specified time. In the past I have used [bucket] and [line] to produce a series of messages along the lines of:

(this would morph between preset 1 and 4)

Does anyone know if such a feature can be directly incorporated into the UI interaction the preset object provides?

I would like to implement 'morphing' between presets over a specified time. In the past I have used [bucket] and [line] to produce a series of messages along the lines of:
recall 1 4 0.0
recall 1 4 0.1
recall 1 4 0.2
.....
(this would morph between preset 1 and 4)

preset-object-as-ui-for-pattrstorage-and-interpolating-presets

The X.FM~ synth in example uses a pattrstorage based on preset, but I'm not sure about interpolation.

You should also search for a JS-gui called "pattr_ui" by Charlie DeTar. It allows to use pattr system with a preset gui-style.

The X.FM~ synth in example uses a pattrstorage based on preset, but I'm not sure about interpolation.
You should also search for a JS-gui called "pattr_ui" by Charlie DeTar. It allows to use pattr system with a preset gui-style.


I think you have to use the float, so if you want clickable preset recall, have it go through a float to the pattrstorage. Then if they want interpolation, they need to use the float... the preset will only deal with exact integer slots.

i tend to use something like this: [attached]...

(some superfluous stuff here as culled from an old patch)

Pid; looks like you are essentially doing the same thing I have resorted to, i.e. using the second output of preset to drive a line object and repeatedly send 'recall x y z' to pattrstorage.

This unfortunately introduces an unwanted effect. Using your patch and a glide time of 20ms, I expect to see 3 discrete recall actions (as line is using a grain of 10ms) occur on the pattrstorage object. Observing the output of the pattrstorage object (which reports every time it 'recalls') gives the following:

What we are seeing are three calls initiated via the line object (in your [p fadepresets] subpatch) and one (slot) call from the preset object itself (direct to the pattrstorage to which it is 'bound')

In the case of longer transition times, this will manifest in the preset 'jumping' momentarily to the target value, then returning to the smooth interpolated ramp.

I've attached my method for doing this, which interpolates from the current state to the selected preset (by using 'slot 0' in the pattrstorage object)

The patch controls a single dial, with preset 1 setting it to 0, and preset 2 setting it full.

With the (default) 1 second interpolation time you can clearly see the dial 'jump' to the target value then return to interpolating ramp.

I guess the only way around this is to request a feature that allows the automatic slot loading from the preset object to be disabled, such that the user can implement it themselves if required...

print: recall 1 4 0.
print: recall 1 4 0.5
print: recall 4
print: recall 1 4 1.

I guess the only way around this is to request a feature that allows the automatic slot loading from the preset object to be disabled, such that the user can implement it themselves if required...


2. thanks for explaining why my old bit of patching never worked well! these days i ignore preset and just go with a set of buttons and umenu filling around the pattrstorage.

3. but i think your clever "store 0" solution is brilliant. i might go with it from now on

4. i attach a quirky workaround by john gibson, using jit.cellblock

I think the trick is to unlink preset and pattrstorage and re-create that functionality in the patch. That way you can bypass the instant slot recall thing and put in your interpolation scheme instead.

also it's good change the tempo of transition dynamically, could you use my abstr for make it.

another question, i have a main patch contains four subpatch (bpatcher), the each bpatcher have a pattrstorage unit, also main have a pattrstorage unit. the bpatcher pattrstorage work properly, but the main pattrstorage watch all sub patcher instance, the questio is: it's possible isolate the four bpatcher from main pattrstorage?

would like to pattrstorage can't see subpatch

another question, i have a main patch contains four subpatch (bpatcher), the each bpatcher have a pattrstorage unit, also main have a pattrstorage unit. the bpatcher pattrstorage work properly, but the main pattrstorage watch all sub patcher instance, the questio is: it's possible isolate the four bpatcher from main pattrstorage?
thanks in advance, regards

'mudang' gave me a very efficient pattr interpolater a few months back; see the last contribution to this thread:

https://cycling74.com/forums/ask-those-in-the-know-essential-granular-synthesis-parameters

'mudang' gave me a very efficient pattr interpolater a few months back; see the last contribution to this thread:
https://cycling74.com/forums/ask-those-in-the-know-essential-granular-synthesis-parameters


could set @greedy to 0 I believe. Also you can open your clientwindow and find the listings for the bpatchers---they will be named and their objects will be indented in the list. Uncheck the top bpatcher "include" checkbox and all the objects in the bpatch will uncheck too.

Note that each bpatcher will also have its own pattrstorage client window, with check boxes you'll want to be active (and they're not indented as it's the "top-level" patch in this case).

many thanks, I was obstinate myself with "greedy 1". instead it was "greedy 2" :-) it's better but still does't work because i need see some bpatcher and some other no.

even if i exclude manually childs, when loading a project the params update it's slow.

there is a way to exclude singularly a cild (bpatcher)?

many thanks, I was obstinate myself with "greedy 1". instead  it was "greedy 2" :-) it's better but still does't work because i need see some bpatcher and some other no.
even if i exclude manually childs, when loading a project the params update it's slow.

that's a good question, I'm not sure. since the bpatcher has the pattrstorage, and I'm assuming an autopattr, wonder what the autopattr would hook up to in order to exclude the whole bpatch? :)

It would make some kind of sense to hook to a thispatcher object to exclude the whole patch, but I don't think that works. not at max computer to check though.

Probably there is some kind of message to pattrstorage to tell it to unsubscribe certain bpatchers? Using the scripting names of the bpatchers in question.

that's a good question, I'm not sure. since the bpatcher has the pattrstorage, and I'm assuming an autopattr, wonder what the autopattr would hook up to in order to exclude the whole bpatch?  :)

Probably there is some kind of message to pattrstorage to tell it to unsubscribe certain bpatchers? Using the scripting names of the bpatchers in question.


thanks, in fact sending unsubscribe message, it's possible but pattrstorage remain very slow (as if it saw all) when loading prj. My escamotage is make a main patch containing separately bpatchers, so it's more fast and flexible. regards.

'preset object' as ui for pattrstorage and interpolating presets