pattr based track presets

Aug 31, 2010 at 3:56am

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.

there is a tread going on at the ableton forums, too

http://forum.ableton.com/viewtopic.php?f=35&t=145211

Attachments:
  1. ClipStates.amxd
#52065
Aug 31, 2010 at 7:54am

I found the problem.

a set message was going to the wrong place.

you can get the working device here:

http://www.maxforlive.com/library/device.php?id=384

woooot!

#187004
Sep 1, 2010 at 11:47pm

Morgan that is a remarkably sweet little idea! Looking forward to trying this!

#187005
Sep 3, 2010 at 9:56pm

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

–if poly~ and live.object play nice together

#187006
Sep 4, 2010 at 3:25am

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.

#187007
Sep 5, 2010 at 5:28am

OK so I love this device. However as usual I want to hack it and make it do something a wee bit different.

Basically I want the presetting to span across 8 tracks not just the one the ClipStates is loaded into. I am thinking I could implement something simple where the “this conical parent” is located.

Any ideas?

#187008
Sep 5, 2010 at 11:19am

morgan, it really is awesome. the aplha too. especially in fact. i am thinking about it, hacking it, will post back if i have any useful thoughts. in the meantime congrats and keep going.

#187009
Sep 5, 2010 at 8:17pm

Ok.. I’ve tried a slightly different formula wherein the big list of paths and indexes for poly is separate from the parameter values. but it’s all jacked up.

@juanSOLO

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:

http://forum.ableton.com/viewtopic.php?f=35&t=145211

@pid

thanks again!

#187010
Oct 7, 2010 at 2:23pm

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.

#187011
Oct 7, 2010 at 3:36pm

hey morgan, i think this is what “slot 0″ is for – you can ‘store 0′ whenever a new request comes in, then interpolate from that ‘current state’ to wherever.

i think. i seem to be doing that in some device i seem to remember. from a discussion on these forums in fact.

HTH.

#187012
Oct 25, 2010 at 11:48pm

I think it’s on!!!

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!!!!

#187013
Oct 27, 2010 at 9:35pm

a few weird things

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

#187014
Nov 2, 2010 at 4:49pm

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 . . . ?

#187015
Nov 2, 2010 at 7:49pm

hey morgan, nice work of course from you.

“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’m gonna go check this now, it is bugging me (yes i was in max, not m4l before)

more thoughts after i study the latest properly.

i think you could call it “MorganState”, specially for english/deutsch speakers to get the bad joke

#187016
Nov 3, 2010 at 6:29pm

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.

Attachments:
  1. MorganState.amxd
#187017
Nov 9, 2010 at 12:10am

So after a while of playing around with the device, I haven’t had any issues. A thing that I hadn’t designed but is there anyway is that you can change the track order and the presets still work.

Please let me know if you’re testing this and having problems!

A feature that I’ve found missing is inclusion of the mixer device parameters. I should be able to get those to work too by using ID numbers instead of paths. . .

#187018
Nov 10, 2010 at 3:39am

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!

#187019
Nov 18, 2010 at 9:40pm

Hello,

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?

Thanks! greetz, M

#187020
Nov 19, 2010 at 12:32am

I’ve released the TrackStates device on maxforlive.com here:

http://www.maxforlive.com/library/device.php?id=447

The version there is only one file.

Mixnar, did you download the .maxpat files? There isn’t anything to be done to them except to put them in the same file directory as the TrackStates.amxd

#187021
Nov 19, 2010 at 8:01am

Hey Morgan,

I’ve downloaded the device from maxforlive.com and it works great now, thanks!

Grtz, M

#187022

You must be logged in to reply to this topic.