A question about preset recall efficiency

[toscanini]

Hello,
this is a rather general question. I have a big patch that stores and recalls presets. The preset content includes, among others, 64 values for the parameters of a live device. At this moment I have live.objects pointed at each of these parameters and I am not happy with the results. Persistent preset changes (and newly stored presets) slow down the system. I know of the undo history issue so that can be the reason although 64 values do not sound like "a lot" to me. An alternative would be the use of a single live.remote~ and shoot through all the parameters with an [uzi] but I wonder if that solution can be quick enough and error-free regarding the parameter changes.
All opinions welcome,
toscanini

[chapelier fou]

the uzi method is 100% reliable to me.

[toscanini]

Ok, that must be done then.
Still, I wonder: some data must be changed with live.object's. I will not be able to go under a half dozen live.object actions at each preset recall. Typically, how could I recall playing clips or change tempo without live.object's ?
So I'd still love to have some concrete data about how many live.objects would it be safe to use; or how often can live.object actions be triggered depending of whatever parameters. On a long period, the duration of a long set, say, 2 hours.

[chapelier fou]

You can't, but usually you can use very few live.object and dynamically change the id.
Would you care posting a portion of your patch to illustrate ?

[toscanini]

I am still thinking of what to do first but I don't mind showing you the patch as it is. I'll PM you.

[madlab]

Maybe you can post it here unless it is uber-secret. This way will can all try to help and learn...

[toscanini]

Ok here you go:
Here you have 64 controllers (normally these would be all the parameters of a VST as next device in the chain, or all the send amounts of different tracks into different return tracks). For now I just try to randomize them.

One method uses live.objects for each controller. The other one uses one single live.remote~, with iteration and dynamic change of the id's, as le Chapelier suggested. First I wanted to use an uzi, but then realized that "target 0" for poly~s does that already.

What you notice is that the first method seems much more reliable (and in the isolated patch, not heavy on CPU at all; I actually suspect that the CPU hog isn't with the multiple live.objects, but somewhere in the store/recall process in a big pattrstorage situation)

The method with live.remote~ skips most of the values. So I guess first of all I could need some help to turn this method efficient. Thank you for any suggestion.


<pre><code>
----------begin_max5_patcher----------
2484.3oc4c10bahCEF9ZmeELd1K81QG8Evd2t+M5zwCwlzPWBjAHeztS6u8E
PXGmDL93HIZ6I23VCDP9UOHczadC9+tXwxKKeLsdYveE7wfEK9uKVrneScaX
wv6Wr7ljG2jmT2eXKuIstN4yoKWY1WS5iM8a+xjhOu9pxp0YEYM616sIMatN
qcGUoaZLWEHl8A1p.fI69mv9WA8GXAeZ3mo3taxJxSa5ub7cmnpz5zhljlrx
htsCCaOaa+Eu7xu7mQpcW0qJKZpy9VZ+A1c0d843vFDz2PNRqo7tl11RyWuM
0bzKWteWcez2TlWVY1S6EJNhIhWM5+CN3b109JRto+Lt7uqxRxC9mx7sKeR.
LW0dE.5132u3htWVYYeTURw1xaZUlfGxZtNHO69zOTkdSYS5O1cr4YEoaJuq
n+GPLlxM9Q75NZtl2olpntW0wcuJhbP+bLXS+Lv3Go8Ppd5ljpOm1Dz9Yr69
xkmrWRFJ5uAPi61wC6N3mn632RcsH8g1ObuRVG6NlIPeibZXMH5bDU1ID04Q
41c0pStOc651FV6mv0IMMUYWdWiYZiE6EvEKWeaZUcVcSZwlz8BuQ4sS+uOo
Zea91x7u9iOBe5U8M86HnsY0r9g0l9n.sDQuD2LgDWNc2jbjobhOa1e07y+b
mp+OSfGqe3YGvokeMqep2HXZ0mMh5G8K0MIO6Jo6N0xtW3CmZOOMd2MmssGm
OKtTbvj3fylDORZyj3R8QZNDXtlWMV2zCzYFTd5A5F5C4Qlw4Xm+3b.8mi+Y
5dmFlVcrg1LZ9IE7gQ1BCO+Q1XuSGYCcYqFE9sW0ZnjhD8Ij0+.VE7G7oVat
ruFHoRbPcqmkrpdGsXfaS17uAYAYHDTyPuR4YuPfP86HAsI3RLpoXXw67Onl
RMGopivvyUMMCCErLqqPoe2Jaeuv1Wn2SymMgzFabkSLMnpFQZiNWosSRWMr
hneNJrzcJbFN4U1ON.WOs7NF4F+NZbfukGrMMOYyTqdDLqDP.QlZaO+QVYuO
V69gpZcd1lz.wDxZnAPMCC7VTU3clptew2StffAYUapqRM8DWiIq+5ax5OMq
BOVQucU7daRU6Gf1wlqOcmiHpqaIhe9E8JdmUiVd.bR4DhMK6E3m8bc532ZU
Z+jpiP33gSZE0qOs.2NLR2Xzv4quQuown+ILNsvgCGzIpAMWmUuda58YSVaw
f.K5KSK57WErN781uRrNcEqrx541v3ymaU1r5seeFZnWQaKUa6SKo3PyIOX2
eTv+zT0HyX8HrJd+fDsugcJIGg88hCpgbXF10oEIWlmdrSzAMKcTOADqORiZ
zgetJuL4fduWTO2thOtt7gc5zy+cWtuRjIpI49j76RKuZ2l2s8C+LlWV74Sz
Q7riusAU0L1OvXG7tOwrQ12cEYM0Me0nuLy9MUK81JZ5bXLwTLVrNzSHlzFD
yzpnEhInKhImDwLtm5ADSYChIioGhIoKholBwhLU44ADSaChI.5gXJ5hX5IQ
LEySHVnMHFHnGhooKhENIhY7D2CHVjEHlJlfk6GRWDKZJDKLj6IDK1FDKjfk
6GQWDKdRDSH7ChIY1fXJBVteLYQLIaJDSO762z8HFXChIoW49O0OPODClDwT
JOgXbaPLN8J2+o9A5gXSZuuF7j69Rab2WwnW49R55tubR28GJr1CHlMt6Kin
W49R55tubR28UBO4tuzF28kZ5Utujtt6KmzceYrmb2WZi69REAK2mtt6Kmzc
eo1St6Kswceoffk6SW28kS5tuj6I28k13tuDHX49z0ceYDl.iIAsqYrX6CLl
jQIFit16KiQDXL2iXJl8AFiVHFcs2WwPDXLOfXf8AFiTHlht16q.DAFyCHF2
9.iQKDit16q3HBLlGPLg8AFiVHFcs2WIPDXLOfXR6CLFsPL5ZuuRhHvXd.wT
1GXLZgXz0dekBQfw7.hosOvXzBwnq89JMh.i4ADKz9.iQKDit16qBQDXLOfX
Q1GXLZgXz0deUDh.i4ADK19.iQKDitt6qhQDXL2iXZl8AFiVHFcc2WyPDXLO
fXf8AFiTHlltt6qADAFyCHF29.iQKDitt6q4HBLlGPLg8AFiVHFcc2WKPDXL
OfXR6CLFsPL55tOnwDXLt4AarCYLvFiwDgzKZ0.cMFCBQDXLOfX1XLlPQunU
Cz0XLHBQfw7.hYiwXBA8hVMPWiwfXDAFy8HF2FiwD.89KoDnqwXbFh.i4ADy
Fiw3wz6ujRNcMFiCHBLlGPLaLFiGQux84z0XLNGQfw7.hYiwXCe0cPKDitFi
wEHBLlGPLaLFiKoW49b5ZLFWhHvXd.wrI1qbN8J2mS2XuxUHBLlGPLah8JmQ
vx8oarW4ZDAFyCHlMt6CwDrbe55tOODQfw7.hYi69PHAK2mtt6yiPDXLOfX1
3tOnHX49z0cedLh.i4dDSXi69fffk6SW28ELDAFyCHlMt6C.AernSW28E.h.
i4ADyF28AFA+VPhtt6i5ALlo7ZGRXw1mVLRkHQ5VHFlGtXNGu.l8QEiT7Ecq
BCv7nEy8.FXePwHEfAzsHL.ySVL2SXb6yIFsHL5VCFf4AKl6ILg8wDiVDFcC
XAf44Jl6ILo8oDiVDFg+COByiUL2SXJ6CIFsHL5FuB.ySUL2SXZ6yHFsHLB+
cFBhHh4b.yAADiVOFzo6ihGDwCy43kCBGFsdN7P2mt.HhFlywKGDLLZ8nEfr
3ElXg4b7xAgBiT3EgyDFhHg4b7RXefvHEdQWCvDHhClywKo8gAiT3Egc+BQT
vbeo8Z6SBFsrlfp70oCAl6q7xAY.iRv0uUjUQ5Cs8g65.aRerueY4MYayZ0z
oB7Ezaxkx7HaMbW22zzzgQre249pxhl5ruYfkNL3olxlx7xJykqcGwQLQ7pQ
+evAW3ty2dk9uqxRxC9mx7sKGEVXtUxxJNshM7UXG6rUL3DJ1qtUIq3faRlG
8DNPO6OCsrdg4tqOtWd60lts+bQtt7tpM6Z68Q+qkQBdpgrMstIqX+HQCGTT
7yNnqy1tMs3v642lU2MVz1i2cit8.HZOunQ6y1yK9nej1CadaO.l1CLOsGEB
8QGNe5iDQ6ITNasmPL7S37oOgQXZO54q8Dho8DMusG.i9LO2e8hthizdTym9
nvNeg3Wn1CLesGI11yL0eIvvOy27ogXp2HbF0G.y86y276gLLsm4qdLc2khi
Y7Y970dNI+HlW8Avb+07LegFy765YjevL+td9leW+KV8pXVtyaczYyhCSt81
6SqpGNk8Mj10Z+EyhT0q5eaVg4s8qHdYU58Y6N9n9sjT0tP6l1UYeWkYMpOp
kKun6578K9efTJwUE
-----------end_max5_patcher-----------
</code></pre>

[chapelier fou]

can you post test_w_remote ?
i am not so expert of poly~ btw...

[toscanini]

Here is test_w_remote (strange if it doesn't open in the brown bordered box)

<pre><code>
----------begin_max5_patcher----------
786.3oc6X1saaBCEG+ZxSgkulUgMDfr61dMllhLwdstBLHiSV1p5697GDJoM
Mgl4vZTmpZo9C37meGe74XdXV.rndKqEB9L3afffGlEDX6xzQPW6.XEY6pRR
qcZPw5pBlDF5FZCQJHUrCLR8ZUISo9UCy8zgbgBFBfEDwsPv26lUCQs5Nt31
kR1Jkahn4Q2DEBv4HyEWCT9MQ82yOpEpV9usOWjYXW2ZyyEZSZkIpqSN0Js5
h6+TBbv82K5uH4jRvWqKovdII0CpXxkLAonzNsA1v8dYMB1z4iylY9S3XwG6
mZwryVJ1V6aMrQxZXBJfSeU9cTnkLewMyCAwXrAWoXeAMDdjTy7lrptrV5zi
1BKxihWDdv+CMPX6iTj+QZKScdLc2BQTlkoY9hoYWsHUAJL+7p3zFaG9rqGE
w3XKUQ1X8jTeg3zoEww9Cw5mJ.AO4hx3rE1KIdKPewzhrc5pkrgQWpUf9MbI
Qoj7h0JWFofdxE.MirbUcUES33DzNfk4dj7X3o2h06jO+iN44GslgQj1Cm5B
JvlFuYeB9.9jqg8n8S4VIYC2B1ekagReOWuEW.RNyJsb7JK0Ujp2vUxDuh68
2t.BP744RhyhtHtDz+cIOkQ7s4Rv4YWDWRzGTWxvyYeOiJz25KNuiw5f8G7k
NsvteOpyKZt0sEauj5Mu2DWnSbWuRVqpV1Qfml7H8oGL8j2izjDAstRedn7y
tVntSFfR9aNt5ApE558K.n29BclG8GeYRxe0u6k0RvRt34ezPKDM8uuapsds
b0Nj2sG..0qWpNzjKHJdsXvbzkBMHN8NNkxDCqJjxaMQhz9PwWrbYrpIaOK8
uVModPMUbZSsdqhN2CxclHbl6nQcGWxz5I63U8iOg9wSJMO0JMT1aDmcehp3
bCGSRWz25BfyjQrbv7YalHdhGgbxlL0fFSnKZ5VsgFSvqUznoQOiZ0S5zwmw
r7w7ovlJ8LB4btzwkjjzzrgIa6djVgnqZ4dWR8zPaStv0zloVWn5F9t4ma6g
H0UlnzosW6peEtMMQmUVamGm8Gv2NFVH
-----------end_max5_patcher-----------
</code></pre>

The advantage of poly~ for such cases is the sizeability. But I am not an expert either and make many mistakes. Maybe the whole "target 0" doesn't work the way I imagine it after all (although the debugging seemed to confirm the uzi behaviour)

[broc]

I think setting up live.remote~ is generally more complex than live.object since it must be prepared for handling audio streams. Consequently, dynamic changes of the id may lead to timing problems. To avoid this I would simply create multiple instances of live.remote~ within your poly~ abstraction test_w_remote.

<pre><code>
----------begin_max5_patcher----------
719.3oc4X0saaBCE9Z3ovhqYQXCge1cauFSUQFvq0UfMx3jksprm8YLPJIMc
gPPNMaJJww9.G+w24WyK1VNo7sjZGvmAeCXY8hskkdolEr5la4Th2lUfq0Wl
Ci7Cd5yNtshjjsR8xEzMjEBRIWR9cuP15RJqfH02HpawJrL6IJ6wUBRlrciQ
IQK7bA9w9MCgIM+BiW3Ad3UEwWK60jW2pzb8NqPym762xuyYRFtjnk7EAEW.
9JuHen3Z5uzhgdK50TMdCIekRQJHsBKkBZ5ZYKsXsmFrbVUQD0zZIgk0pA85
6rs6+cms6XYw0koDQOr1fE6A8gRNfBguOEBW17z.Pwvlg1I+EJD8VJLXjTXq
Vj+rhztyNTlzwE3jhYO5re6NlnmBEcZGsJAohvxAz7KkiBVlrXoxMCgztYny
vQvA6bFufKZ0h5gII1yOw8j+CNPcCHWHZprqIozZhbp9cPcDbXjA4znOxTpD
j174hoSjNEHDpCiCBOCc5OizY3ToScfu6QiFfhU.A.mn+pejtHievHK0LK4.
RLRQpFIqx3kkDVKO4bEUodelGM0ru2BlO99i4mTW.AgdCReLkt.fg2IsAPYf
fIROQgssJYx5+AyewpOboETlD+K0j3GcyLIv+OLIWbhZTbzsxj38uqIY3Q7d
ljyT25aZCuY2AGJbzFMukZykudHL1fMNFOYila22yY7DjZIWzcauhgQZSqvB
EnjDwJBCmVnUi2rGoIvrbdopA93K8sez0RJLv7GgBcME6MSQd3DOB0sH808P
1K8V4TPYG+V+zTYy5GZlp4qEY8.s+UYLHHLWEaRYXIkyFbQp9..v8WySz7bB
aXW8kz7JtxIpCCfGNoOyXgTvHQjmwPT7AO+mFQAFEQQifiLKhBmeDA8QMmwD
EoGfsm3TOaFvJ5LXEYT1aLQgQFEQvwDFBCMKlFAjLLhFiaO7Z7kTS1Y+GnQ.
3+E
-----------end_max5_patcher-----------
</code></pre>

[toscanini]

Thank you broc, multiple live.remotes is definitely the way to go! I just need to think of a nice system for toggling between the id and "id 0" for each element of the poly~ as the controllers will need to be accessed from other places.