broc

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?

initialization-order-inconsistency

http://forum.ableton.com/viewtopic.php?f=35&t=137593&start=0

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

Any comment from the developers would be much appreciated.

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.

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. 

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)

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.

1. parameter enables [M4L objects](with an eye on the "order" property)
2. pattr
3. objects with a 'loadbang' method
4. loadbang objects

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.

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

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!

And here is again an illustration of the issue.

Below is a funny workaround using live.button instead of loadbang. Thus the initialization can be controlled with the order parameter. In this example numbox order was set to 0 and button order to 1, and apparently it works as expected.

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.

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.

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.

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.

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.

It's good to know that the behavior is "intentional" for technical reasons.

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?

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:

https://cycling74.com/forums/live-thisdevice-bang-comes-before-control_surface-init-on-live-exe-startup/

initialization order inconsistency