pattr based track presets

I’m working on a m4l device to recall settings for every parameter on a track with the launch of a clip. It’s getting really close to doing that, but I’m having weird behavior.

the device is an audio effect. to use it, launch a clip, pick your device settings, and hit the big ‘store preset’ button in the device. presets are recalled by launching a clip slot index.

THE BUG:

after storing a few presets, AND THEN launching a clip with an already stored preset, the device usually overwrites the parameter states on the newly recalled preset with the previously active preset. I know that all of the presets are there inside of pattrstorage because the correct values flicker on the dials before they revert to the last active state.

I’ve updated the device to 1.1. ran into some awkward situations, so I’ve added the ability to store a preset on any focused clip and a delete preset button. Now you can duplicate/overwrite presets on multiple clips without weird jockeying back and forth on clips.

I’m working on interpolation, partly as a way around the blip that happens before the parameter states are updated. The attached patchers are a poly~ based approach, and there are some things to sort out.

–how to get the patch to ignore device activator toggles, and maybe radio button groups (like filter type)

–how many voices is sufficient and if dynamic polyphony changing will be ok

Attachments:

the patch picks polyphony in a dependable way now. I’m pretty sure that this method will be efficient enough to run in upwards of 10 tracks simultaneously.

it’s like really close now, but the parameters are still acting up. I’ve checked that the list is formatted correctly and that it isn’t being output more than once per recall. playing with the line object inside the poly, doesn’t do anything unusual.

I hope that the issue is just some quirk that poly~ has and someone will recognize it.

you’re right about the change for multiple tracks being simple. I actually got a head-start on this patch from a thread on the ableton forums. The other dudes there made a patch which gets all params in all tracks.
the thread:

Attachments:

I haven’t been able to implement this yet, but it occurred to me that this patch needs to have preset slot 1 reserved for the current state of the parameters. The savable preset indices start at 2, and when a preset is recalled, the patch should immediately capture the parameter values (store 1) and then interpolate from there to whatever preset.

This version hasn’t been tested extensively, but it seems to work. I’d like to test it out for a little while before posting it on maxforlive.com

also, I’m thinking about changing the name, as I don’t care to call it ‘ClipStates2.0′ and if the patch name didn’t have the version number, people would loose their sets……
So let’s have a naming contest!

I know that the color coding is excessive. I use it to debug and learn patches. . . . and this one took for ever for me to get right. Please let me know any and all bugs and suggest some names!!!!

Attachments:

The interpolation was weird in the last version, especially in the high range of ramp times, , , I have no clue why, but in this version, i’ve reduced the interpolation time range to 1 second maximum.
(having all my knobs commandeered for 10 seconds was to obtrusive for me anyway -_- )

I’m not seeing the ‘interp_time’ in the client window for the patter storage.. I had an unnecessary loop of gui objects in the last version, and i cleaned that up here. But. . . . when I add an actual [pattr interp_time] to the patch, It shows up in the clientwindow as "interp_time[1]"

@pid, the "store 0" tip you gave me doesn’t work in max for live. . . . it definitely does in max, but when you send ‘store 0′ to the pattrstorage here, the slot is added as all blank fields!!?!?!?!
I’ve submitted a bug report for this and the other things.

this version1.2alpha6.2 works better, uses the same poly~ patch ‘statesetter6.maxpat’.

So nobody has any name ideas? Do you think a naming contest is a stupid idea or something? :P

Attachments:

This works a little better still. Nobody suggested a name, so i’ll just be calling it TrackStates. The poly~ patch has changed to state_setter.maxpat
changes:
Interpolation time is TO THE triggered preset instead of from the previous preset,
the max time is 5 seconds now.
I’ve increased the time grain on the [line] object that drives recall.
and The [p TrackStates] is more clearly laid out diagrammatically.

Thankfully for the most part, the aberrant behavior happens only if the device order is swapped and presets overwritten for the new device configuration, or if the device is opened for editing. my advice is to finalize your selection of effects for the track before adding the TrackStates to your chain.

It will most likely boomerang if you change devices once it’s all first set. The jittery recall still happens a small percentage of the time even if you leave everything in place, and I can’t figure out what the issue is with the faulty interpolation. I have a feeling that it’s an error on my end, but the pattrstorage is not outputting recall messages that are out of order or going backwards, and the initial (go from) preset is not being stored once the recall gets going. . . so . . . ?

Sexy huhuh. I hope it’s there when you open your live set every day. XP

Yesterday I found that the stuttery recall happens consistently when I adjust my macbook’s volume as a preset is interpolating.

I moved the deferlow object from before to after the line object, and the boomeranging seems to be solved. Recall still hangs when the computer’s volume changing interferes, but It gets to point B reliably.

this is the version that I think will be final… I’ve added support for return and master tracks and for panning and send levels, not mixer levels. . . Recall for TrackStates in the return and master tracks is triggered by launching a scene.

the two .maxpat files are poly~ patches as with the other versions.

One issue i was running into was that in the return tracks, the send levels were set very low, but not to zero by default. I consistently got a value in scientific notation from the live.object when it got sends value (1.02946984271e-07), so I made a workaround. If presets are storing but not recalling, It’s probably because ableton on your computer has a different default level for sends. Let me know if this happens!

Attachments:

I cannot get this great device to work. I load TrackStates in a track and do what it tells, but nothing is stored or recalled. Maybe I should do something with the maxpat-files first? Can someone please give me some info for the right procedure?