parameters sticking and abstraction re-ordering help?

[pid]

hello.

i have some parameters related problems.

1-- i copied and pasted some patching of mine from one patch to another in development. now, whatever i do, the long names and short names 'stick' - they remain the same as the previous patch, even though i have renamed them all and checked and re-checked the parameters view menu. they are all live.gui objects i think, no pattr ones. they reside in a bpatcher abstraction. that shouldn't make a difference though? anyone else come across this oddity?

2-- maybe causing the above? -- i have an abstraction. i use it 4 times in the device patch. when the list of parameters appears in the live automations menus all the parameters appear as "something", "something"[1], "something"[2], "something"[3] - as expected. however, they do not appear in the order i want them to - "something"[3] is controlling what i perceive to be abstraction 1, etc. is there a way to A- force parameter names and B- force parameter orderings. i have tried this with dynamic arguments to my abstraction with no joy. i have manually chosen the 'orders' of parameters in my problem abstraction, but i presume that is unrelated. i am reading all abstractions from the current .amxd files folder, not a max search path. again, should not make a difference?

i am hoping that i am fundamentally misunderstanding something / doing something obviously wrong.

ANY help / suggestions / similar-experiences-stories / etc much welcomed.

core duo, mac osx 10.5.8, live 8.1.1, max/msp/jitter 5.1.3

thanks.

[broc]

Once I have experienced a similar problem. After copy and paste of a patch section with live.dial objects, and changing the short names, for one of the objects the original short name always reappeared. So finally I had to create a new object for it. There was no abstraction involved I think.

Generally I'm using only short names and find the 3 name types quite confusing. It seems like M4L is sometimes confused too..

[pid]

thanks broc. indeed, re-making the objects almost worked. but some of them kept sticking, weird. of course i was essentially being an idiot, as once in the master patch (device) i just used the parameters view of THAT to force rename everything...

...however, this ordering / naming issue not clear: in the master patch parameters view, when clicking on "reveal in patch", some named parameters were showing me completely different unrelated objects highlighted in yellow. further testing revealed they were indeed just completely confused parameter names compared to what i had actually named them. i am sure i am naming correctly. the problem abstraction is inside a bpatcher which is inside the main device. presumably this is not a problem? (i have dealt with all parameter view names in the intermediary patch correctly). anyone any more thoughts?

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. is this 'good' practice, or am i being needlessly ocd?

question for gregory taylor:
somewhere on some forum you once posted the exact initialisation order for m4l devices. i cannot find it now. could you tell us again? could you put a detailed side by side comparison of max / m4l initialisation orders in the documentation somewhere?

thanks, sorry to go on, any help / thoughts greatly appreciated.

[Gregory Taylor]

question for gregory taylor:
somewhere on some forum you once posted the exact initialisation order for m4l devices. i cannot find it now. could you tell us again? could you put a detailed side by side comparison of max / m4l initialisation orders in the documentation somewhere?

Here's the order in which things are initialized:

1. parameter enables [M4L objects]
2. pattr
3. objects with a 'loadbang' method
4. loadbang objects

[Gregory Taylor]

i have an abstraction. i use it 4 times in the device patch. when the list of parameters appears in the live automations menus all the parameters appear as "something", "something"[1], "something"[2], "something"[3] - as expected. however, they do not appear in the order i want them to - "something"[3] is controlling what i perceive to be abstraction 1, etc. is there a way to A- force parameter names and B- force parameter orderings.

a. If you want to see the contents of the parameters window ordered by parameter name, click on the header for the column.

b. Those numbers you see after the name of the object (e.g. dial[1], dial[2]) have nothing whatsoever to do with the order in which pattr parameters are recalled. You would use the priority to control that (see the Parameters window).

[broc]

re-making the objects almost worked. but some of them kept sticking, weird.

I've just encountered the same problem that re-making of objects did NOT work to assign new short names.
The issue seems related to copy/paste of objects in abstractions.

As I understand it, abstractions require some internal re-naming to ensure unique object names.
Apparently there is a bug changing/overwriting the short names. But it seems unpredictable and difficult to reproduce.

[olivierseb]

question for gregory taylor:
somewhere on some forum you once posted the exact initialisation order for m4l devices. i cannot find it now. could you tell us again? could you put a detailed side by side comparison of max / m4l initialisation orders in the documentation somewhere?

Here's the order in which things are initialized:

1. parameter enables [M4L objects]
2. pattr
3. objects with a 'loadbang' method
4. loadbang objects

Sorry Gregory, but could you give us example for 1) and the difference between 3 an 4 ?

thanks a lot

Olivier

[pid]

hi olivierseb,

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[3]" 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!

[olivierseb]

Thanks a lot Pid,

this helps

I share with you the fuzzy sight on some parts of M4L.api

We have to learn, experiment, and ask when we are stuck, that's a very normal process to me.
As long as we have someone from C74 to answer, that's good, and if they can improve the documentation that's even better

Bye

Olivier

[broc]

Regarding initialization order I did a little test observing the print output in the Max window.
The results are different from Gregory's list. Here is the test patch that I've used in a M4L device.

<pre><code>
----------begin_max5_patcher----------
1003.3oc4X80bhBCD+Y3SACO2yQ.As2a2miNcbBPTy0XBCDr1qy8c+xePIQR
Ps15b2bOHJY2r42tY2eahu66ElS2CaBC9dvSAddu664IGRLfW26dgaA6KvfF
oZgD3qz7eF9fRDCtmIGtJnoM+vnqnDVC5WPgjn3IS6FlztEQvPlzPGFrBvJ1
fHqWVCKXJfDmlvmSPb7TwWyjOE+N34t4fJkqIGGeaQXuwosrSst.IDvVIRB+
QMBfC0WWXcmm14p7Ifvvcv5FDkHQ+CciqiNAdxdT9TAtYKzPGO.tFSKdAVpA
DuvR3pqwFzJHoWeoFFOL0DQppgMPBCv5.t95BZwrkF6ISmXU9JPAz4jsFF8B
WWiJoDAHLloX3CK2SAKDndgNpkxIfJKSkQo3bP8NTCJGCM1E3ol.BZKfAYHE
ZhmdbdnsU0HByvVPBfaiMME0TL1vTJI6rHoDtCU.eEUx1HsUerxnXQKqwnnw
X7wJdNo.RfcshnQJjFVLEoIvVA0bUMTlrtJcwoETmVTEGZtPCKrbUbcP3u88
O7iG97iUXJnLGPV+EFphjgprnyEphbGpzWI0vr2p5JHBkv2vnWVzruBBiHtR
Fk9kPt8vbCsst3.P5bh.SOrD1vPjirIOcLu3D81fJKMKek6inxJJOctCdAOa
0Q76xOT7wMfcvxk7UguUrDvX0n7VlxAM3msQS8g313jz4.bWafiA9vqf5aDQ
tXc86iBxmpxiaouqj1nRDvtltuQt69Fo3GRl9n8J.8r+4Wc22a1y2A52r3q5
v.hHTDnI4lCGyUGFI57giL6gijtQGPBvKmTeNZL2mW4BqOp.07oyf0KUM3L5
rgHHlvjJGap8Rvi1djUYG.2BoqNRubfbQa4apfvRLZqA2ftbFrpwkP3d9ACf
pd4QSroQK2UZXu04f1zXKOIRsmOehc4HhY+ccoCBUVz4vNYj64aYWvHHrgV2
ue2tfej2oSidLKzpE0NQjUGhVdFWFPHT0QDWNfvSWOLkr1RQ1fUar.Hu8yKB
azLFbokN8FDYE0I.o0kpit6L0PMUe8tNeLZ21s4vOYp03rYxygM5EaRsykD6
hKQbx2GN4bEeIDvmz5Ai1A+jBOYYpni7qzzwhNytGMdDt1DQB.WKKcerH9J8
zXYdPh7knT6dZR+EVcxreo4HhDjU7COy5yP9mky+KlxO4tv3OLE5uBJ+y.q+
Wn9Gi1S65m2JsWhhFHNS8mBMaLdu36+Atccq6a2s0+W9xFsYXjc2NxEQ20zE
Tpl4soUAoSuEcWnZvsmSzuUriaNOyPmA2Z19MlGrscoHJ6BPT5cEQQW.hhuq
HJ8BPz7a.Q7W9s+e.WPGiGA
-----------end_max5_patcher-----------
</code></pre>

[olivierseb]

Hi Broc,

You can't trust the print objects timing this way, because timing will vary according to where they are in the patcher.
Timing is always bottom left to top right.

we have to find a reliable way to monitor this

Olivier

Regarding initialization order I did a little test observing the print output in the Max window.
The results are different from Gregory's list. Here is the test patch that I've used in a M4L device.

<pre><code>
----------begin_max5_patcher----------
1003.3oc4X80bhBCD+Y3SACO2yQ.As2a2miNcbBPTy0XBCDr1qy8c+xePIQR
Ps15b2bOHJY2r42tY2eahu66ElS2CaBC9dvSAddu664IGRLfW26dgaA6KvfF
oZgD3qz7eF9fRDCtmIGtJnoM+vnqnDVC5WPgjn3IS6FlztEQvPlzPGFrBvJ1
fHqWVCKXJfDmlvmSPb7TwWyjOE+N34t4fJkqIGGeaQXuwosrSst.IDvVIRB+
QMBfC0WWXcmm14p7Ifvvcv5FDkHQ+CciqiNAdxdT9TAtYKzPGO.tFSKdAVpA
DuvR3pqwFzJHoWeoFFOL0DQppgMPBCv5.t95BZwrkF6ISmXU9JPAz4jsFF8B
WWiJoDAHLloX3CK2SAKDndgNpkxIfJKSkQo3bP8NTCJGCM1E3ol.BZKfAYHE
ZhmdbdnsU0HByvVPBfaiMME0TL1vTJI6rHoDtCU.eEUx1HsUerxnXQKqwnnw
X7wJdNo.RfcshnQJjFVLEoIvVA0bUMTlrtJcwoETmVTEGZtPCKrbUbcP3u88
O7iG97iUXJnLGPV+EFphjgprnyEphbGpzWI0vr2p5JHBkv2vnWVzruBBiHtR
Fk9kPt8vbCsst3.P5bh.SOrD1vPjirIOcLu3D81fJKMKek6inxJJOctCdAOa
0Q76xOT7wMfcvxk7UguUrDvX0n7VlxAM3msQS8g313jz4.bWafiA9vqf5aDQ
tXc86iBxmpxiaouqj1nRDvtltuQt69Fo3GRl9n8J.8r+4Wc22a1y2A52r3q5
v.hHTDnI4lCGyUGFI57giL6gijtQGPBvKmTeNZL2mW4BqOp.07oyf0KUM3L5
rgHHlvjJGap8Rvi1djUYG.2BoqNRubfbQa4apfvRLZqA2ftbFrpwkP3d9ACf
pd4QSroQK2UZXu04f1zXKOIRsmOehc4HhY+ccoCBUVz4vNYj64aYWvHHrgV2
ue2tfej2oSidLKzpE0NQjUGhVdFWFPHT0QDWNfvSWOLkr1RQ1fUar.Hu8yKB
azLFbokN8FDYE0I.o0kpit6L0PMUe8tNeLZ21s4vOYp03rYxygM5EaRsykD6
hKQbx2GN4bEeIDvmz5Ai1A+jBOYYpni7qzzwhNytGMdDt1DQB.WKKcerH9J8
zXYdPh7knT6dZR+EVcxreo4HhDjU7COy5yP9mky+KlxO4tv3OLE5uBJ+y.q+
Wn9Gi1S65m2JsWhhFHNS8mBMaLdu36+Atccq6a2s0+W9xFsYXjc2NxEQ20zE
Tpl4soUAoSuEcWnZvsmSzuUriaNOyPmA2Z19MlGrscoHJ6BPT5cEQQW.hhuq
HJ8BPz7a.Q7W9s+e.WPGiGA
-----------end_max5_patcher-----------
</code></pre>

[broc]

Hi Broc,

You can't trust the print objects timing this way, because timing will vary according to where they are in the patcher.
Timing is always bottom left to top right.

Sorry, I don't quite understand.
Are you saying that the print output order doesn't reflect the real timing of the objects?

[olivierseb]

Hi Broc,

You can't trust the print objects timing this way, because timing will vary according to where they are in the patcher.
Timing is always bottom left to top right.

Sorry, I don't quite understand.
Are you saying that the print output order doesn't reflect the real timing of the objects?

yes, printing is just a task like others, when there are many print objects they can't print all at the same time.
So priority is followed as I has described.
We could use only one print object with tagged datas but I am not sure it will be enough.
If anyone has an idea, it will be welcome
olivier

[broc]

Ok, how about sending all messages to a common [zl stream] object and then printing the collected list?

[olivierseb]

Ok, how about sending all messages to a common [zl stream] object and then printing the collected list?

yes, would be better than sending all messages to a unique print object.

Olivier