initialization order inconsistency

i have noticed this too.

we have a discussion on this topic here:
http://forum.ableton.com/viewtopic.php?f=35&t=137593&start=0

feel free to join us :-)

Olivier

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.

Thanks!

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)
2. pattr
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.

Have fun.

-A

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.

Andrew,

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!

And here is again an illustration of the issue.