Morgan

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.

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

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.

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


pattr-based-track-presets

a set message was going to the wrong place.

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

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

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

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)

--if poly~ and live.object play nice together


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.

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.


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.

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

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.

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.

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.

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.

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:

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.

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.


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.

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

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

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


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

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.

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


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

Interpolation time is TO THE triggered preset instead of from the previous preset,

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

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


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

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.

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.


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

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


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!

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.

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!


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?

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

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

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

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


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

pattr based track presets