sorry i am not gregory... or maybe i should take that back?!
as far as i can tell,
1 = ALL live.UI objects. but maybe this is also / instead the live.* objects?
2 = pattr - i presume a pattrstorage would come before pattr @bindto's, but not sure
3 = objects with an initial state, for example, [gate 5 2] would make sure outlet 2 is open next in the initialisation chain, but more complex would be loadbangs that are called from objects internal code. note, i am guessing here...
4 = your good old friendly [loadbang] objects. presumably this includes [loadmess] and the like. note that loadbangs are only ever called ONCE, as device is dragged onto a track initially or set including loaded devices is opened - never if the device is simply moved etc.
my reading of the above is guesswork as gregory taylor's list is not very well elaborated on and there is no conclusive documentation regarding this issue, which is odd, as it is the crux of all our patching.
i must admit, since gregory re-posted this info for us (thanks by the way!) i am VERY confused about the standard "M4L.api...." abstractions and how they must work. for example, have a look at [M4L.api.SaveInteger] - if gregory's list is correct, then the saved data in the 'pattr' would load followed by the 'gate 0' (single gate 'off' at load, default anyway - this i presume is an undocumented shortcut for 'gate 1 0') followed by the 'loadbang' object banging the '1' message into the gate. therefore, this abstraction should NEVER work! but of course it does and i use it all the time. so either the initialisation list is wrong or my understanding of what that gate is doing is wrong. i presume the latter - clarification from someone in the know would be useful!
more on parameter naming etc:
on another note, i obviously explained myself very badly before, as mr taylor's response to this issue misunderstood my problem and did not help. i STILL consistently get this problem. there is a bug, OR, more likely in this case i think, a lack of documentation / clarity with regards how to deal with this issue of parameter naming / ordering:
so, if .ui objects are copied / pasted (either 'shortcuts', 'alt-click-drag' or 'save as' on a patcher), the parameter names become confused and 'stick'. when making patches that utilise multiple abstractions inside of bpatchers inside of bpatchers etc, this becomes a mess, even if you name bottom up in the abstraction chain. if for example your master .amxd file is opened, a bpatcher that hosts other bpatchers is loaded, THEN you go back and change things in the original abstractions two or three levels deep, the parameters view of the .amxd is completely screwed. sorry for the lack of technical language, this post is already too long. ALSO, if i call something "hello_dial_2" as the scripting name, then copy this to use as another dial, RENAME it, SOMETIMES the name sticks AND, if using the abstraction a few times, "hello_dial_2" not only refers to a completely different parameter but also NOT to the 4th instantiated version of that abstraction but maybe the 2nd (or whatever - it is quite random). for the record, i studied that beautiful 'loopshifter' .amxd which has nested bpatchers in this way, but could not garner anything useful.
i am sure most of this is user error down to learning how to deal with something new. for the record (again), i think the parameters view is an awesome and brilliant concept, i am not whinging, i would simply like to understand it all better.
an 'M4L parameter view primer' would be an excellent candidate for the next article on the c74 site. it might include initialisation informations to!
in short.. we live in disappointing times..