initialization order inconsistency
I have noticed that the initialization of Max patches works differently in M4L compared to Max standalone, in particular regarding the execution order of ‘loadbang’ and live.* objects.
Below is a simple patch for demonstration. It produces different results when loaded as M4L device in Live or loaded in Max standalone.
I wonder if this inconsistency is a bug or intentional?
----------begin_max5_patcher---------- 578.3ocwV0rbaBCD9L9ofQG63xffhcbu0miNY7HrV6nVXECR35zL4cuRBA1j .NjLtsWjL6ue62trlmVDPxkm.EI7qgeOLH3oEAANQVAA9mCHkrS6JXJmYjRP oXG.xxVc6knVI9MX0QShh8hwlRAV.ZmOIdgUL8tGD3gs0vNcaNoYwFeBSVkZ uxxrmz6hhCu26if6xpL+GeNgbN3xFcWzodoshzOVAsglP5ChEjHqzof7sZAq fXU77hE1ikerJWCmbEAI6VwE2sxU9qcTRZRT1zbw5+ybAB+x.iWQEeJjdaIi jD2fQp6LIdbxXy6jLDn9VyGEhiPjI8Vq7A9HqtOtindN7CcZ9IIaiaXIkZu9 Rb6jy37SJoON0FDog5s.xxKfKywPtKYxAokgj8ER1ELnhcD3aYZcsHuQCm+k xSXdFyRIEMfbem3N4WBLUE.7BQo0FOmLTuFpTSoDNUIQ.cTDMZLKZPgVoers zGyfRSasskrNZb8Bz46nZElvamfZGg6aFCroiLoS6+qaOC4fGj05qLa8hPdT nD4Wohk72nlYHJ0LsPha6y5XopPhGlKrrY8ZLYg.+oMVpqAaIexpRf6kSBTY MGpmxS2HRqqsJcqB5ttM6IMu.wyY3gazxft+4H0sFXU70VVRemKKcvblaKcl Y573K+jBGlsxGRUJYS8ttD42jGdF0bPoEnav6BaLeFPHs2lGDbNfWzKIkBdk zrh2Cgv6GssMWDQmAhVOvl+1HZ8LPzl+oHJclH5i10LO77h+.XGgRhL -----------end_max5_patcher-----------
i have noticed this too.
we have a discussion on this topic here:
feel free to join us :-)
Any comment from the developers would be much appreciated.
Thanks in advance.
I am really worried about that too…
It seems that sometimes, the loadbang does not work well in Max4Live. The "initial value" is a nice thing, but it doesn’t get you very far when you need to load things in a certain order, as it is for the majority of my patches.
Would there be a way to set priority in initialization?
Or maybe being able to initialize some values with a delay?
Any hint or comment would be appreciated.
loadbang order with multiple loadbang objects is not defined in Max or now in MFL. It never has been. Most of the time, successful loadbanging uses one loadbang object ( "to rule them all") and an ordered system of triggers for your data.
It can be pretty tweaky patching, and difficult to manage in large patches. If you guys can show conclusively that the order of initialisation is busted
1. parameter enables [M4L objects](with an eye on the "order" property)
3. objects with a ‘loadbang’ method
4. loadbang objects
Then we’ll definitely look at it. I’m personally not having problems with it currently.
Establishing Live API load state is even more difficult, given that we have no idea what’s going on in the rest of the Live set. The way I do it is loadbang all my paths, then if I need to trigger further state gathering at load, I use delays and other hacks.
hi andrew. thanks SO much for confirming all of this. it really does help.
just two more things from an ableton post i made:
also, a silly "order" question: if i order 20 objects 0 – 19, these will get recalled on load in order 0 – 19, yes? as opposed to the documentation which says "Name: Order / Description: Order" in the REF pages (that is all!) and "By setting an attribute to have a lower order number, you can recall parameter values in complex patches whose initial values may need to be calculated based on initial or preset values so that the dependencies are preserved" in the parameters help page, using the word "lower", when surely the word should be "higher"? or am i being really stupid?
‘order’ question 2: sometimes i ‘order’ parameters not sequentially, so say i have 3 parameters in a grouping i want to recall first and then 4 in another grouping, i might ‘order’ them 4 9 12, followed by 19 22 25 27. is this ‘good’ practice, or am i being needlessly ocd?
also, ‘order’ is linked to the logical order parameters should be recalled / enabled at load AND to the ‘order’ they appear in in the automation and modulation lists? if so, this is not very useful. of course the ordering for enabling at load takes precedence, but then the lists may not be very useful in terms of their ordering for an end user to choose from. maybe i am misunderstanding something fundamental?
apologies for verbosity. and thanks again.
please look again at my patch above. When used in a M4L device it gives me the value 5. But according to the ‘official’ initialization order it should give 50. Doesn’t this show conclusively that the order is busted?
And interestingly, in Max standalone it gives the value 50.
You can try it with this patch (inspired from broc). To me, it clearly shows that reloading a patch is not a simple thing in M4L. Cause the float does not always get back to initial value when you save preset and when you save the patch, it shows that the loadbang doesn’t get trigged after the initial. Or is it the "initial" that does get triggered at all in Live? I say so because you can see that it works when you open the editor… Please help!
----------begin_max5_patcher---------- 597.3ocyVssbaBCD8Y3qPCO6x.XicReq82nSFOBq01pUHwfDtNIS92KZ4RfF DgI0cZewX1qGc1CK7ruWPl5JnCHel7Mhm2y9ddnIqAu168BxoWOHnZLrfbPq omffUM9LvUCZOkrIoynrJWUYDfASIt0ZA0b3LWdZeIbvzzxjj0gQqHwIarWR iva1FFQdnMmlxXdr.ZRHHn2Emg8Uk88OEuoqyGURijliQG7kRNUP9pRvF5Vy eBcGa6VOd4xN3lXs8huu8mUKjTjvOqwwa3jmDjSkppBhClIYFlYcpkLtGojz 6Ph4tYIlUtHmj+wjiSEyGPtjXIhMas+tNIL8cIkoHjT27wjTQxsiJD7KPXcU rQ0VyKzxdLLg6kKXtGEL6PBp4Aocumd4nPQMSKZhB5aUYM7LP4dPRyDvvQzR notX0zK.aO0XJ4YUF30+oa4qVByxHhJPcrybm8gPQnjmlg0FEathUCGaj8Z5 w0hK+gsVHNhbT.ECb4lKOpPbLUyUkLnzUlURdCGMYp5B.XBdtqr0FnvIlgqE JIHQsQbnyladT37bkWqbaFr6Bm1+brJut71GnPwVbuNbTLcpwX24+VQ2XN3r pzrTg.Wdgq4YybhqGzyeloRoxPMbkbeeWCZBC2Dzc4175i5mNYYT4oO5dRbM 4VbWPRzb6BvlL4Zf3aytx3AjB1m5Yk72+tC7fXsOlozppxCcHs6EZjWOMLPa 3RbnLLn5OIfD2GzYNiAxAC9fbNqPwklVPPdXx41RwT5RfzXb+2FR1U3+2go3 Efoz+.HUeyK9+BvSBxIy -----------end_max5_patcher-----------
I wonder if this is really incorrect behavior…
I noticed that in the original patch the number was provided by a live.numbox. From what I can see the behavior in Max itself changes as soon as you replace it with a regular number object. Then you’ll get the same results as you got in M4L. So not 50 but 5.
Thanks ShelLuser for looking at it.
Your observation is correct of course. But if you replace the live.numbox with a regular number box you’re actually eliminating the influence of initialization order since a regular number box can’t be initialized.
That’s not really what I’m getting at. I’m wondering if M4L isn’t simply compensating when using the live.numbox in order to get the same results as you’d get when using a number in plain Max. iow; if live.numbox isn’t simply behaving differently within Max.
Ok, I see what you mean. Interesting theory.
But you can easily check that live.numbox behaves equally in M4L and Max.
Different behavior would be quite disastrous I think.
By the way.. Just to get no misunderstandings; when you mention "number cannot be initialized", do you mean to say that it cannot hold an initial value? Because that’s wrong; it can.
Hey guys, thanks for bringing this ‘problem’ up. Let me try to explain what’s happening.
When a device is opened in Live, the entire patch is loaded/created, just like in Max, loadbangs are serviced and so on. Automated parameters, however, do nothing until Live initializes their values. We tell Live what the initial value should be and Live, after the patch has loaded (incl. loadbang servicing), sends the value. So the order is loadbang, then parameters.
When a device is opened in Max, we have complete control over the process, and the loadbang sequence services parameters first, then loadbangs.
If we were to initialize parameters when devices are loaded, you would get double-output from parameters — first when the patcher loads, then when Live initializes the parameters. This seems wrong, too — why should a parameter output its value once when opened in Max, and twice when opened in Live?
All that said, we might be able to make some adjustments so that you don’t have to worry about this, and I’ll discuss some ideas with my colleagues and get back.
thanks SO much for the explanation!
It’s good to know that the behavior is "intentional" for technical reasons.
jeremy. a ‘thanks SO much’ from me too. thanks for taking the time to placate all us neurotics over here…
I am seeing double output from parameters now. I use a parameter set to priority ’10′ in place of a loadbang and it seems like the parameter is loaded a few times.
seems less straightforward than it was for [pp].
Show us device code which illustrates your problems and we’ll definitely check it out.
BTW, you should only need to make a parameter order 1 step larger than your other parameters in order to insure it gets loaded later.
Redacted (thought i found the culprit, but i didn’t. stripping patch)
So you know the live.button in that patch is triggering output from live.text?
oh hang on, I see what you mean.
I’ll get back to you about this
Sorry for the inconvenience
I think this problem is because you have "bang when transition from" set to "both" in the Live.text
yeah, thank you. figured that immediately after i posted it. tried to delete the attachment, but no dice. that’s why i sighed with my nevermind.
sorry for the flurry of false alarms. I am just trying to get rid of all of the warnings in my patches that i have ignored because ‘it still works’
As an experienced programmer in other languages and coming to max relatively recently but now developing at full steam, M4L initialization behavior is a major stumbling block in the learning process. Things can get ‘interesting’ really fast with complex patches, especially when interacting with hardware. For example, a complex initialization routine’s time-sensitivity can be revealed when you start saving patch files. There is generally no notification for this. [live.thisdevice] and load bang are not the same thing. It goes on and on. But, there appears to be consistency but it just isn’t always documented well. So here we are.
I am currently working with a disparity between [live.thisdevice] init bangs and control_surfaces when the Live exe is launched by double-clicking on a patch with an M4L device in it. See this thread: