Forums > Max For Live

initialization order inconsistency

March 13, 2010 | 12:59 pm

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?

– Pasted Max Patch, click to expand. –

March 13, 2010 | 1:12 pm

i have noticed this too.


March 13, 2010 | 10:45 pm

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


March 15, 2010 | 12:46 pm

Any comment from the developers would be much appreciated.

Thanks in advance.



pm
March 17, 2010 | 7:00 pm

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!


March 18, 2010 | 4:10 am

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



pid
March 18, 2010 | 10:20 am

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.


March 18, 2010 | 11:50 am

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.



pm
March 19, 2010 | 1:44 pm

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!

– Pasted Max Patch, click to expand. –

March 20, 2010 | 10:23 am

And here is again an illustration of the issue.

[attachment=127701,248]

Attachments:
  1. Picture_1.png

March 20, 2010 | 12:34 pm

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.

[attachment=127703,249]

Attachments:
  1. Picture_2.png

March 21, 2010 | 3:53 pm

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.


March 21, 2010 | 5:37 pm

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.


March 21, 2010 | 8:14 pm

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.


March 21, 2010 | 10:32 pm

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.


March 22, 2010 | 2:55 am

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.


March 22, 2010 | 10:15 am

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.

Jeremy


March 22, 2010 | 12:30 pm

Jeremy,

thanks SO much for the explanation!
It’s good to know that the behavior is "intentional" for technical reasons.



pid
March 22, 2010 | 6:55 pm

jeremy. a ‘thanks SO much’ from me too. thanks for taking the time to placate all us neurotics over here…


January 15, 2011 | 4:05 am

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.


January 15, 2011 | 6:08 am

seems less straightforward than it was for [pp].


January 15, 2011 | 6:44 am

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.

-A


January 15, 2011 | 3:43 pm

Redacted (thought i found the culprit, but i didn’t. stripping patch)


January 15, 2011 | 3:50 pm

NEVERMIND.

sigh.


January 15, 2011 | 5:05 pm

So you know the live.button in that patch is triggering output from live.text?

-A


January 15, 2011 | 5:59 pm

oh hang on, I see what you mean.

I’ll get back to you about this

Sorry for the inconvenience

-A


January 15, 2011 | 6:06 pm

I think this problem is because you have "bang when transition from" set to "both" in the Live.text

-A


January 15, 2011 | 7:18 pm

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’


Viewing 28 posts - 1 through 28 (of 28 total)