Hi.

Since day one of M4L I have been using the standard technique to save id #'s assignments in Live sets.

I have a number of my own abstractions to do this. Recently they seem to be not working anymore.

To test I used this standard setup using the provided Live api abstractions:

<pre><code>
----------begin_max5_patcher----------
897.3oc0XsziaBCD9bxuBDm2f.yi.8Vq5wtRUsGihV4Dbx5VvFgcRy1U8+d8
CLwYCPXa1n1dXg3wy3YluY7G16ySm3thd.wbcdmyBmISdd5jIJQRASZFOwsD
dXcAjoTysDwXvsH26zywQG3J43bGeiPxtR5NdAhqLInQpVD+oJj1ettNKalZ
CkvY3eplHv2yuQbUMhgHbHGSIOTiVy0FFjEHTwIHHS9JD3EKFj342tbUP95G
wjsV1DARjJChS6yFKeYG03bU5QW8sYgQVIHlXxOfURPfkpjv880XXgyGnE4t
xY+0zoxG2MRPt.uG4wJv4nZiK2CqaWbNhwmUAqgkyh5FyA8h4243tofB4tcl
4VHVnBnjOR7UvcXvvPLHporzuQi.ii6DiCZcqHoQbT8CHBbUAxdNFbOJ+AHm
WiWsiiN9KVCR2.0RrrXGhtwH1H2d4KENWNeay3IyhIXtn9pyaeuXSFdhRFTe
fE37r3DsXORqO1RcZA+EK2dLC2rRc4uRZtnAS4Gv7NSIHgPa5AZ8XWtpfR1N
Ti3YtcHbr.S9tbwX8g.xEflO.Ltg1ajRqkae5wxchBfduVEqKiYUHTdAtrO6
YbTEquIQGpnDQitJq75087m5uzWZJWd95IULHlWuR5DB5Gh8Vcwjbezm9HZO
dM5yRO+ETIkilcOMOYAX4YT7Bk8fUXOKKjwp1pt4gBGhGR82E+Fv4DMAIJt7
Pe0qfDEkdPpEQiMgRRmDJg2HRaAeCWPt0ATaMsE39p+TYOr0o.IHneFDadND
ccXiZIw8YyHXqm++.asAGAihH1+hDwmWn+mfLtyFr+b5X++Nzwu8jwhVylcQ
zMajbNx14kuAz192Zd6UpssceFPCY7WQEhszsjwKBNRsbAU8D9R3f2Zln4Y5
SANW8RyQC.V7Jhp.C0n7LEsyL6ChCq21bgjQvdAhi6yMig9Jsa5qaZoR+0yK
Wmz5ciJRopSmmo+xoezv0njqrF4OuO2LlZT1EqQpkSP+Qd4MYUwjT9oENFcW
8ZCTYtXmywnJWbpVLoMnVb7fDNfVkdDmmiHVjNtk37JJlvaBhnvX4kLAoYxW
gfn1QNK6rAazQa7Xi1fwGsfXeU7MWGlwp9C0nqMZmOlnM6DktXzJQSYKUl9R
pZrUM5Zi1zaPmfo1q+2VXO5Zi1rwDsoudrUFehaya02JGcRzJF7qo+V2R+Wv
-----------end_max5_patcher-----------
</code></pre>

... but now not even THIS is working.

What should happen of course is the device should recall the same assigned id # and the different Bpatcher abstractions should recall the correct menu locations. This no longer is happening for me, testing in various ways.

Are the abstractions not recalling Saved Ints etc? Well, using print, the M4L.api.SaveInteger's seem to work, but not the saved paths.

One more strange thing: if one opens the said device in the Max editor, the umenus AND id #'s recall correctly. They just do not recall when embedded in the actual Live Device / Set.

Have i suddenly forgotten something / started doing something wrong? Have my installations become corrupted somehow?

Just throwing this out there in case anyone else has experienced this?

Live 8.1.3 // Max/MSP/Jitter 5.1.4 // OSX 10.5.8 Intel

Thanks.

Hi pid,

I had a quick look at your patch and can confirm the behavior you describe.

Are you sure it worked before?

For me the different behavior of Max vs. Live is not really surprising as we know (from discussions on the cycling forum) that the initialization/load orders are not consistent, in particular regarding loadbang. So the timing of loadbang within SaveInteger might be the problem here.

Generally I think that loadbangs in abstractions are problematic and should be avoided.

hey broc, thanks, as ever...

so, unless i have suddenly woken up in a scene from total recall, yes, i did have this concept working before.

problem is i am still essentially 'experimenting' with m4l, and i have folders and folders of stuff that at their conception were supposed to resemble clever programming organisation but have become somewhat bloated over the last 6 months, so i could be cocking something up.

at the moment i am using bpatchers nested 7 deep into the device. so, i am going to go away and repatch everything from scratch into one ugly huge patcher with very specific load orderings and see if i get any joy.

i'll report back (next year!).

have you not had this issue working yourself before?

thanks,
pid

Actually I don't have much experience with API abstractions, but remember similar inconsistency with my patches.

Btw, I wouldn't waive subpatchers in general, just provide an additional inlet for globally controlled loadbang initialization.

Cheers.

Don't save ids, save paths.

This is the only reliable way to do it.

-A

thanks broc and andrew.

so, yes, i am doing it with saving live paths, like in the example .api abstractions. the problem is, M4L.api.SaveLivePath is just not firing on load, my version or the.api examples version.

i use it twice - once to save the path of the device and once to save the path of the parameter. And really it should not matter which order they fire in as each section is self contained, although i have got my own loading sequence just to be sure.

anyway, i am only half way through trying to fix it / pulling hair out, so i'll keep at it till i find something...

ok, so, i need some help, if anyone can...

after much testing, just to be sure, i can confirm that this very basic set-up is absolutely not working for me anymore:

<pre><code>
----------begin_max5_patcher----------
1374.3oc6Z07aihCG8b5eEHN2FgMN.Y0dYGMWpzLRq18XUUEI3j5c.6HvIa6
NZ9ee8WPbZ4yBMSGobnPM1w942ume1Fy2uZl6J1S3BWmey4NmYy99Uylodj7
AyLom4lE+z5z3BUwbWsKlu9Qbt605LODmSiyvp79J5Kyi2Ql+23T7Z9eFmKx
ferncUt4hFRT6UEeeFaOOEyUMLv7T8i3OuCqQsqqy8lr1kiKvTdLmvnOjKpY
cI.gy8t1IvWdE.PxaPvbupeFaylBror2nJ6MAVYGmu0PPGaHIEPnasZDeenp
hW5oal.4M+EV0iM5r6PjDEmvV8O2.8r56DZUWW9reb0UxKWO4goOiOPVi6HF
oKz6Z.BAsCPv2q.j+RqlYnAH.ZxBPY3hh3sU7NG+jBntxd5ake2vn7Bx+ox.
HEhlNvVJSPDoj0eythpgjPfHEsfz2fyWHnJat1lKhpkKfVXoRL8G4j3TmOwR
SbeCTUJ4.d9p8btHtTib1J66f2O4hSjx3.okMvxqsI0JYQefpzKJuNHkFndk
VUqZ7Le.SiWkhsyqH9.N4gXNOmHXE7w+qvvwFRVxho6wrMkOt741Uelnwk4W
olNI2RhDVSdDJgKh5V.rtZn3QVNutPoasU4ARAokZKikHTNJx.FVKhioTlIF
W0p00ToL511UXupgainRIzuIqth1PNKowNFgtg0HVY4IBi9F9k6EgghF+oE6
v3jTRVigGNdWiXFKjllgQBKZ2qE2nUimNsjOsiQEJdUjYdivj+rQIWKCUFYm
6oyT4hTdafVJaDwWA3q0q.1jWg3GIm7SL4ZLcamttM4mXrPTtBHsCQjsCauM
qAQZmIO0ThK7dUU0GalksZy7ywDGL8l3Z2aunlLjajc8QnQXhGdwD+CoIN3h
I9ES7QYhubpbwM6KYbt3AmKW7edTdzjMuIbQz3Y7EmKF+E6Sbp1SXiBa0zcA
AVTSvaSWGnBX9gnFpp9vxvOdaw7cZoIA8ekIkuICO+QrxDuKqL4i3JStrrje
8WVhJbVjRRp+suVS18bdTIKnmKsSSE8rkJChfPsAie6tJP+H86GUusGkqzxA
5pD8qjoh2DYpnd9MBjx+v4obhJ6hmx.cJZ0nPFqFuUAE+uhwMscFM5Cdo5Hx
9KbFi+5CMnWk9TWF+1bYT+04RHa9klnWzGHH50KS+naQ8Kg1e5Wb2ZVVlLr+
RV62c9zdRZhyyr84Ne81OeqCdyFQew4QbdEqIFIfWy1qUMvZoRuAySKUK2CF
nnonE5SNrdVBct1nQSrjVS4b.myIqE0uXzGoginZ3DgdaAglCMsU4R6uoxGI
IIXZ6TyTxJJ4Bm47EgOqclqYor7x9l+0xKH4UwE6ybdS91UcWpdvtf1XW+.q
ygJTucgFjYguEYlys7XwVAmbdcSNK6CNy5o+LBTLaTTaLavYlYOcNkJhMijP
Dc4oZfq4Dh0mlAJrsAtvykCVK8bxP22NgxeKS.hLKh17N8ZiV.ikVTUpZ9oW
7A7nvk74mxUEho4VW1+LKW2ATAsDwJXIzpk2eW0jzVk4nKaIGHH2cLAYYf.T
raiExuqBO4MnduGpTN2WaDsuXUhCuNvp7vrrJTmfErT8AN3uT+JXrRMAfE1E
XCFFX8Q.KvZmZB.aWp.vhgA1x.uFrkhhI.rxuPpN0AmR+8lYQmvrnyDXkuiy
gLB6Tzh7fSEZkeOO8CsCPHff5PuXm.xagfpTiEsg8THLP+.oBP+1uK8CBBFO
0h5AXegZouBAXjQObL0XQKnOBgngKDTitBjvrTVHSMVz1qAYngyspuBwHKKA
Upwh19HDFFVWDpC7pYbsRbBREI9wU+OPQE+pI
-----------end_max5_patcher-----------
</code></pre>

by 'not working' i mean:

first and most important problem - the M4L.api.SaveLivePath inside the M4L.api.DeviceParameterRemote is not loading or restoring when instantiated by opening a live set with a device in it that utilises it.

however, this IS firing inside the M4L.api.SelectParameter Bpatcher abstraction as that menu is rebuilt on load, but in that abstraction the M4L.api.SaveInteger is not firing on load as parameter item is not reselected on load.

the M4L.api.SaveInteger abstraction inside the M4L.api.SelectDevice Bpatcher abstraction is also not firing on load, as that menu is never rebuilt or set-recalled.

i have tested all of these in various combinations and with print objects to the Live-Max-Window. And i have tested my own versions of the abstractions using 'buddy' to determine my own load orders, and various other tricks, etc.

important to note - when first instantiating the device, by dragging from the Live Browser, loadbangs and Patrr recallings act differently to when a set already containing the device on a track is reopened - for example, if M4L.api.SaveLivePath has nothing saved in it, nothing is sent out, whereas on instantiation from dragging from the browser, a "0." is sent.

more important - when opening a failed-to-reload-properly device in the Max Editor - everything has been saved and reinstantiated properly, including the id # to the parameter, which is controllable upon using from the Max Editor. close the editor again and then everything works.

i know about initialisation order problems in M4L - but in these provided abstractions this should not matter as each is theoretically self contained on load. and I know about differences of behaviour between editor and 'compiled' device of course. the point is, i am absolutely certain this basic setup with these above-described abstractions used to work for me pre- 8.1.3 / 5.1.4 - i.e. - recalling the id # (via the saving of a live path) used to always work - the parameter assignment would be reassigned on reload of the saved set.

if anyone could confirm, or point out something ridiculously stupid i must have forgotten, please let me know, as if this is / is-not working for others on Live 8.1.3 / Max 5.1.4 i will write into support.

thanks.

all you have to do is to save the PATH,
save the path with the "PATTR" object, and recall it with a delayed loadbang @ livestartup. see this: viewtopic.php?f=35&t=144026


http://www.phatline.at/m4l/NochSimpler1.amxd

take also a look @ this maybe it helps...
i have made a patch for Launchpad... it memorys Pathes, and recall them, and transform them in IDs... it works with the PATTR object... ...but make sure you give the pattr object no name> "pattr savepath1" dont work but "pattr" works...
here is the whole patch: http://www.maxforlive.com/library/device.php?id=302

Dear PID, broc, Andrew, et alia:

Yes, things that used to work fine don't anymore. What doesn't work at this point is pattr recalling its value when in a subpatcher.

Pattr (in parameter mode) does not initialize properly within subpatchers. On the top level of the patch, everything is fine. In a subpatch, however, nothing is initially sent out when the device is loaded, or if the "Initial Enable" option is on, the initial message is always set out, even if the current value is different (banging the pattr proves this).

http://dave.rhymeswithart.com/pattrParamTest.zip

This is a little device I threw together to make testing this easy: 4 pattrs (one set to each data type) on the top level setting message boxes with a button for easy pattr banging, and the same thing encapsulated in a subpatcher. The device was saved with all message boxes blanked so anything showing was actually loaded by Live. With very rare exceptions, nothing is typically output by the subpatcher pattrs. You can set data through the device, save your session, and then reload it. Nothing will be output in the subpatch, but clicking the button will show that the data was stored correctly.

Addtionally, even if these pattrs are banged at load time (either triggered by a loadbang or the last parameter, etc.), they don't know their contents yet and simply output a zero. Banging them later, however, does work, as phattline indicated with his delayed loadbang approach. His part about pattr not working with an argument is not correct, but I don't blame anyone for being a little superstitious with something this hairy to track down.

A work around for now? With the device you pasted, pid, de-encapsulate the M4L.api.DeviceParameterRemote, and then de-encapsulate the enclosed M4L.api.SaveLivePath. With the pattr now on the top level, it should go back to working fine.

So yes, this is a seemingly new bug, but definitely a bug. Any confirmation from official folks (and anyone else who can reproduce the issue) would be nice.

Dave Linnenbank

Hi Dave,

Thanks for the clear example. I can reproduce the problem you are seeing.

I had not run into this because I do not usually store parameters in this way. What I do is have a pattrstorage in my device in parameter mode, order 0, and none of the pattr objects in parameter mode. This way the pattrstorage stores its slots in the Live set, and you can recall different parameter states of your whole device. If you use a Live.numbox with order set >0 to trigger the preset change, you get to avoid all startup sequence issues as well, as the pattrstorage blob will fully restore before the preset is chosen. In this case it solves the restoration issues in this patch.

I'll log the issue you have reported here and we'll look at it.

Cheers

-A

dear dave linnenbank,

thanks SO much for clearly describing what i was trying to articulate (sorry for my inarticulate ramblings in fact). yes, THAT is what is happening these days in m4l, and it did not used to. i am very pleased i am not going mad.

andrew, it would be great to hear what you discover with regards this pattr in subpatch behaviour.

workaround excellent idea dave, but i would rather get it fixed, as i am working with abstractions i made a while ago (when i am sure this used to work) and everything is somewhat deeply ingrained in the multi-encapsulated bpatcher idea. however, i'll have a go and see how long it will take me to rebuild. but i mean, abstractions are simply how to use max - top level patchers should not be for busy embedded data structures.

andrew, your idea you mention is great. IT SHOULD BE IN THE M4L DOCUMENTATION as a suggestion. in the future i will only ever do this. (by the way, why not write a comprehensive paragraph explaining all this and the nature of pattr in m4l when possible).

thanks all for now,
pid

Here's how you use pattrstorage to store API paths in the Live set.


<pre><code>
----------begin_max5_patcher----------
1730.3oc2ZszjiaBD9rmeETpxwISIPR9Qts4VpJGx8s1xkrE1lLRfKIr2YxV
6+8vCIavFzCO1d8tWzC.Ac+0MecCnu8znfEr2vUAf+.7YvnQe6oQiTEIKXT8
6iBJReaYdZkpYAKYEEXJO3Yccb7abU4UbVIFjS1iAe5e9Kv1T9lJ.gB3avf+
VVZElC9JguQTBo5YPJMCThWllmCH0UvJyvkfvltNmPwKY6np9GUW3JFkWQ9O
rrLX3Kg0ESxTBAaw+96vIMcfPFVtgPWOWLNbsNlDmH9F.DEIugfp2PydID7k
5OhtqfPywbk1BOVHaGuozPCYglVnjkfOURRyA+IKOKPV62e5I4km+fnZMBIZ
FYMU1hpiXXMdAEX4Jt3AIRKTYdozTjtFC1jVIfXkgI6iBpiaETQRXb5jGKLU
5K9hXTjspt22mVdnycTsINfbiCwsfCwSCU3vT40wpmQiMfgsokhAWXpliooK
xwmfFcAQMVKcQ722h0CaPvyffU4rTgXzLTUo6wYykNCjE633iOUUCX0HlDRx
2gYqZJtobSosPHZJaTChXUaif3pNBkvElPC80Uqp1vJ4sXWNoK2SpHszaErL
gafBFQSbJwoTJimxIL57CipqgJmQW2WwRNpsgRh4cuJ6qp1DaVVKH4JlWAUQ
DX33XU4NgMnx6mVsEiyxIEdsMb7VuxL9ssLJVyk.cp1pAm+dKVKSaktZ0z7l
aCbNu.fqDTedhNAC5OgWTaSzQJBuYpo3wpPIvw936PNmLC6fuy6bcvWt.Xgh
+pPobwBV797L7dxxygLqPIm0rdffvtQv53vM2lNrXFe.LzhlTHsBAqENRk6p
jK6zYnAKyIB+eCECFJUD4kjPUTfCZTq7+iBpQZitBI6.0ko08m11Ks6+vX4i
tRr7m5P4miGd+33aUndLX3CenY3g+.o3kq3Ps9i4xUZvKSW9ZEHDTPdSHCZy
pH8XJUPDM.RrvVHwfMKlPmwaB5wOPfOv6ZiaSaA1PSTKTHQy4Oa7urn1dV9t
hADwbRqfl1IKVCZ+D3pIVQhX3co8QN09jVmoo0a85LUOGCGVxBnKT40KrRrB
qEohI.W4ruNPRdNaF3r551AJpaHTCdim1d9VnaT9VJ4RGHyL6jUjb7dbYkHZ
sUNQFt+Ju+wydQmHj5kDC2egIXcNa4q3LqzyxvqFRev1hoGaupEVWraIgtsD
WIBNpRy3zwMcWNetkIC8hy5WktD68isg4lv6AqKIYLpTHr9RYwMCmvhqiNkX
J2pVPS253i4LV9hzRGYdIcuSojhTNlSJp2cjCeGoXaIQmgvgxzYBtoZYIKO2
pqz0r2QMZRyuRx3arSxxdOJMyd0bhmU4st6Z1Szj6Zl7EbFgCzqD.HyqtRse
ZMakYyNYpVTDn5cQRSElcm01pEYTgGOfSl3Fa1WNY+UAKiB0wLSzK7zX5qWV
P+a0lmoxAMUVmiVCQ2kf65AMvsNi5PmgPUZBwI0YW0b8ipxMNCp7kuhJqEK+
Ij4kXwrsLkmTvfcNfcATS0oPEqH0mBU.U3kATv18MLp0WVB2dzrTLz54rdwx
PuXYT+75hlnR0HY7owIGBXhZELMiY5eecutnpchrmrEYh7XUaS.32fCGXiS5
.XGqiFMUgqimbZ9qdyAYvNo8.WuWdpp8LVGS4BPztbUqOokX8IMjLqaW0eAf
zFpzJ7E.oQI8iJEocVq8RmdKnRu2PZSJNlCo4JQbU+GXqU7dViCwZA6GWMZl
NqnnC42eIlq3q.YsLM3muE71mOg3rUQNG5yzIRX0QK5oMHrCaf9vNQwp4MS9
PSXhtFgKe1X4l0qgTc1O0sQmA1wctQ9r1eV7jP1CL8okU13Va0mcbrA1VR26
6e3g5O3dbOBF0ZFn9yZpKdSjNI8XjJ4yD3ChavUDXURtmUxb3ONo8be5+BYB
6UPEOaUkU2dqVrSqvwz9EksdkJ2N7XXPwwMIQF2xy9MnzFY8twnJ1txkMCeS
Zw.aMKSPHQnG1ynOeLauSZ3FRVl8dznLCjrsLQflZAbR7KIxyfNRdCgN9VO8
9GpBE0WERF89RTnakbC6obCidrjaQ.X.7mO7VRBzO79wRrmz24qIOVx8f3Yf
ONxcTOkaziEb2WwFdgtIPzXISdzrY50iFe3sakF0WZ8GL+9ascXVhNv5XC6.
R+Wc5LGBW+fNc9+E0iS7w4IE0miWxU8qyYKRyqOLty98XZYiecevUm+ubn.Z
67nzGT5o125iK8L6pUzCethlLYmaNc6Ad1Q21WIZxCmDkzSIJ7tIQQ8Phfg2
UPR9Ca2sLAuqvDL5VKShW99S+OHpcjrG
-----------end_max5_patcher-----------
</code></pre>

ok Dave's issue has been fixed for MaxMSP and MFL 5.1.5, which we don't have a definite release date for just yet.

Cheers

-A