Pattrstorage, recall and line to interpolate between presets is glitching, why?
I have been working on an interpolating preset patch for ages and think I have cracked it. The problem I have is that while I can interpolate manually, I cannot use a the line object to automate the process, as soon as I do, my cpu goes to 100% and crashes, I cannot for the life of me see why? Any one know why?
Not loaded it in M4L but in max it seems to work fine.
not looked at patch.
interpolating large parameter collections with pattrstorage does not work in m4l if there are many many m4l objects, because of problems with writing to undo queues etc (i think).
it works fine in max.
hopefully live9 / m4l whatever will fix it.
Thanks for your help, It's weird that in M4L If I turn the interpolation box from 0-1 with my mouse it interpolates perfectly. It's only when I try to automate it, that it fails. Hmmm.
Hi guys,
I read your topic after having the same problem has you. Once the pattrstorage is "parameter enabled" you can't use the pattr interpolation without crashing Live. Live 9 and Max6 hadn't solved this isn't it?
I was wondering how I could embed the pattrstorage xml/json file in the live preset device ?
Though you can get rid of the parameter enabled and still can update the presets in different version. Then you've got interpolations allowed
I'm getting similar problems on 9.5/7.1 W10
No crashing but serious audio glitching when trying to adjust interpolation from a Push 2 encoder.
Also mousing works fine midi for midi/audio but the gui stutters this does not happen when in edit mode.
Thanks for tip guygz disabling parameter mode does stop glitching.
I'm going to try sending to a dict and parameter enabling that...
Another thing that may help with glitching is to experiment with reducing the update rate (or increase the 'update limit' parameter) of the objects involved - assuming that's not too tedious an undertaking.
I was still getting smaller glitching with lots of parameters morphing after separating to a dict, but what totally stopped glitching was to defer automation of the morph control. Visual feedback to push is now delayed but that's no biggi.
SPECTRO I could probably reduce update rate on some stuff anything to reduce unnecessary load is good cheers!
I've had a lot of crashes lately that seem to be related to this issue. Is there any indication that this is on Ableton's radar as an issue to address?
Is interpolating pattrstorage presets still impossible in m4L for everyone? I tried implementing this but it doesn't work well. Though my patch is huge so I'm curious if anyone has made it work at all
@KAREL: did you try to
disable Parameter mode for your pattrstorage and sending its data to a parameter enabled dict instead
defer automation of the morph control
lowering the update rate of some parameters?
Also, it's not been mentioned in this thread, but setting @changemode 1 on your pattrstorage can hugely help in preset recalls and interpolation if a lot of parameters remain unchanged between two presets.
@TFL what do you mean with
"disable Parameter mode for your pattrstorage and sending its data to a parameter enabled dict instead"?
Interpolated recalling with pattrstorage doen´t trigger Live undo list. So whats the benefit of storing the preset data in a dict and how to you do it?
I do the interpolation always this way and I have Live crashes, but I am not shure they are because pattrstorage has parameter mode on.
@TFL what do you mean with
"disable Parameter mode for your pattrstorage and sending its data to a parameter enabled dict instead"?
Interpolated recalling with pattrstorage doen´t trigger Live undo list.
I thought it was triggering the undo list as it was mentionned above, but I didn't verified that claim (or maybe I understood it wrong).
So whats the benefit of storing the preset data in a dict and how to you do it?
The benefit is not having the pattrstorage tightened to Live (as it seemed to be the culprit), but have you presets still saved in your session using a dict. You can create a pattrstorage to/from dict mechanism using getclientlist to get the full address of all pattrstorage clients, getslotlist to get the list of all stored presets, getstoredvalue to get the value of each client for each preset, and some dict.pack and prepend set and other dict manipulation to throw all of that data into one dict. And you can use store and setstoredvalue to import the dict data back into pattrstorage.
@TFL
I haven't tried any of that thanks, I'll report back. Questions:
-If using dict in conjunction with pattrstorage, you would be recalling presets directly from dict?
How can that work if you want interpolation between the presets?
-"Deferring automation of the morph control" refers to the interpolation control (0.-1.) right?
I'm controlling this with line triggered ramps so this doesn't apply to me I presume?
-If using dict in conjunction with pattrstorage, you would be recalling presets directly from dict?
How can that work if you want interpolation between the presets?
Think of the dict as an external memory for all presets stored in pattrstorage. You can make this work in various ways but I think the most straightforward is to update the dict with a [savebang], or every time a new preset is created/deleted/moved/renamed/locked if you want more security, and data from the dict is restored in the pattrstorage when the patch is initialized. At the end, you still deal with pattrstorage to make preset recalls and interpolation.
I suggested this solution because I thought it was partly what was working for MR-BIT, but maybe I got it wrong, so these are just assumptions here. Given that a pattrstorage-to/from-dict is not super easy to do, maybe you should try other suggestions before!
-"Deferring automation of the morph control" refers to the interpolation control (0.-1.) right?
I'm controlling this with line triggered ramps so this doesn't apply to me I presume?
I assume what they mean is to throw a [defer] between your [pattrstorage] and your recall 1 2 0.5-like interpolation messages. This still apply even if you use a [line].