luc3

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: 

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

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

pattrstorage-responds-slower-with-each-recall-of-parameters

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.

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.

var api = new LiveAPI(this.patcher, "live_set", "tracks", a, "devices", 0, "parameters", b);

it just runs this couple of lines a lot of times whenever it recalls the parameters, as for each parameter it runs a list of 3 numbers into the js-object

========
'
function zetten(a, b, c)
{
   var api = new LiveAPI(this.patcher, "live_set", "tracks", a, "devices", 0, "parameters", b);
   api.set("value", c);
}
'
========

as you can see, it's totally simple
it just runs this couple of lines a lot of times whenever it recalls the parameters, as for each parameter it runs a list of 3 numbers into the js-object

pattrstorage responds slower with each recall of parameters