i made a parameter recovery thingy with pattrstorage in M4L
i have used a js-script to communicate to the Live-API to set the parameters instead of the live.object. because, for some reason this prevents the live.parameters from being logged into the undo-history as opposed to using the live.object
the Live set has 24 M4l devices with this pattr-preset system and a master M4L device to recall all the 24 devices parameters.
this master can listen to Clip Names on it’s channel to recall preset entries so i can incorporate it in a Clip structure
actually, it’s kinda like the Kapture device from Liine: http://liine.net/en/products/kapture/
but, for the project im working on i had to customize some things so i picked it up myself (with some help of the liine guys!! :)
this whole system is quite slow, as there are about 24 x 68 parameters to recover with each preset recall
which is fine, i understand that it’s a lot of data…
but, i just did some test on the consistency of recall timing and here i found out that after loading the liveset the time it takes for a preset to be restored is about 4 seconds. the next recall adds +/- 200ms, and the next again adds +/-200ms, and the next also, and the next also
after a while it took about 19seconds to recall that long string of parameters, while when i’ve just loaded the liveset this is 4seconds!!??!
Let’s have a look at the js? If you are redeclaring API objects each time, for instance, it’s bound to be decreasing your efficiency. Personally, I’ve not recognized this problem and I have some patches that use this pattr/API functionality a great deal.