IML crosstalk

[woodslanding]

I have a script that uses IML to layout various objects. But when I put more than 1 copy of the script into a patch, the layout messages get all garbled, and all the positions are wrong.

The code looks like this:

SendInternalMsg('SET_TARGET_PATCH','SENDER_PATCH');
SendInternalMsg('SET_CTRL_POS',name,IntTostr(round(GetValue(posXIN))),IntTostr(round(ypos)));
SendInternalMsg('SET_CTRL_SIZE',name,IntTostr(round(GetValue(widthIN))),height);

Do I need to be more precise about TARGET_PATCH, and not just use SENDER_PATCH? If so, what is the nomenclature? Or do I need to do something to make sure all three messages get sent at once??

This actually seems like a bug, as though the IML is getting crossed wires internally, but maybe there's a workaround?

here's a test patch:

http://www.sensomusic.com/forums/upload ... roblem.wkp

thanks,
-eric

[nay-seven]

I'm not a specialist about scripts and iml, but maybe you can use 3 sub-patches ?
and use

SET_TARGET_PATCH subpatchname

[woodslanding]

Okay, so I made the example wkp work by putting a wait1 between each track, so the scripts get called a little later each time.

So now my next question:

Trying to figure out how to make a script that will delay any response to a change of input after a delay whose time is a function of track#.

Unless there's an easier way, of course!

I doubt the subpatch solution will work--it would be nice if a single IML message could select the target and the action, but failing that, it seems like this will always be a problem with IML.

[woodslanding]

I tried the data delay script and that is working for now.... but it would be cleaner to put the code in the layout script. I don't really understand what's going on in the data delay code, though

[woodslanding]

Is this a case of where I should be using:

SetFastCallBack(MyIMLTriggeringInputParameter, false)

If so, where do I put this line in my script?? I can't find an example of it. The ''set vst parameter" script does not employ it, but shouldn't it?? The help file says it should be used anywhere IML is in the callback method.

thanks!
-e

[bsork]

I think you could call SetFastCallback anywhere before the parameter is actually being used, but the most natural place would be in Init after you've created the parameter.

[senso]

Yes Bsork, anywhere after the creation.
But the FasCallback is VERY dangerous in the general case. Don't use it except if you know precisely what the VST does when parameters change, which is impossible. Moreover if you use the IML which is not a "realtime" process. You may encounter unpredictable hard crashes...
You should leave parameters as their default callback settings (will work like in the actual VST engine of Usine).

[woodslanding]

Wait, you have confused me Olivier. Is setting fastCallback to FALSE dangerous, or not doing so?

I thought the default was TRUE. I've set fastcallback to FALSE for of all my parameters that create IML, and usine seems more stable. It's fixed a bug where 256presets was setting commatext wrong when more than one instance was in my WKP and it fixed the layout problem that started this thread. I also set it FALSE in the script that updates my combo commatext via VST program list and the one that renames busses based on track number, both of which have randomly misbehaved at times.

Is this a mistake?

Or only in the case of setVSTparameter?

[bsork]

I have also ended up setting the FastCallback to FALSE in a couple of scripts using IML.

[senso]

Oups you're right,
By default the FastCallBack is set to TRUE...
Which is obviously faster but dangerous...
So you can call SetFastCallback(.,FALSE); It will improve the stability.
Now, I have to find a solution to set the default value to false and ensure the backward compatibility, which is not easy...

Sometime Usine is so huge that I can't remember all the settings myself.
I'm sorry for this confusion.

[woodslanding]

What do you think the fallout of the change would be? I'd actually given up working in usine since last fall because of this instability. Do you think there's such a negative downside to the reverse?

What kind of scripts would stop working? I guess audio would stop working and MIDI timing would get sloppy?

That seems a lot easier to debug than random crashes

[senso]

I don't know exactly which scripts will stop working properly with fastCallback(False)
It's hard to answer in the general case.
I think you have to try.

[woodslanding]

Well, it's a moot point for me, as I now know to look for that when debugging.....