Script for Getting IML from controls

[woodslanding]

Currently I'm using sends and dedicated inputs on my script, to get control values. But it occurs to me my wkp would be a lot cleaner if I just got the control values via IML, especially since I've already named all the controls.

But I'm not clear what the syntax would be for that.... Is there an example script that gets control values via IML??

[woodslanding]

I tried this:

Code: Select all

function getIMLString(control: string) : string;
var text: string;
begin   
    SendUsineMsg('SET_TARGET_PATCH','PARENT_PATCH');
    SendUsineMsg('GET_STRING_VALUE', control, '1', text);     
    debug('got IML from ' + control + ': ' + text);
    result := text;
end

But I get an error: 'don't know which overloaded method to call'

[oli_lab]

Hi,
Isn't it the Usine object new thing that you need ?
Faster than iml I guess

https://www.brainmodular.com/manuals/hh ... ne-objects

Cheers

[senso]

yes, right the UsineObjects are modern version of the IML, faster and more robust.
The IML is no longer adapted in your case.

[woodslanding]

Yikes, this looks amazing! Thanks!

[woodslanding]

Edit: removed old question I figured out the answer to...

So it looks like there is one disadvantage vs. IML. The IML code for a control doesn't change if I move it from one sub-patch to another, as long as it's in the parent patch. Either way, I can just address it by its title. But with objects, their sub-patch is necessarily part of their address. Is this correct?

I had hoped that in the case of a control with a custom name, I could just call getObject('patch.MY_CUSTOM_CONTROL'), but it looks like the subpatch needs to be included....

The scripting will get less automated with the subpatch addressing. And if I later move a control to a different subpatch, it won't be found when I try to recall it.... I will definitely want to strip the subpatch name off when I store it, (since it's not info I want to store) and add it back when recalling, but then I have to change the loading script any time a control moves in or out of a subpatch. With the IML it's all automated. And one big reason for saving my settings as text files instead of in the PM is that I can do major re-architecting, and as long as the control names stay the same, I can recall all my old presets.

So unless I think of a good workaround, I'll stick with IML for now, (except in poly subpatches, of course!)

[SylvainT]

Hi,

Your feedback is true.
But we recently added an option for this, maybe not in the manual.
In the setup of your control, remote setting, you have a user address filename. I think it probably do the trick as it is no more related to the location of your control. It is also directly accessible via OSC

Sylvain

[woodslanding]

I'm not seeing a field for this on the remote page....

Is it only in the beta?

[SylvainT]

Yes

[woodslanding]

okay I see it in the beta. It looks like the scope of this is necessarily the WKP? And there is no way to set this programatically?? There's no inlet for it on the module, looks like.

If so, this won't work in my case, as I have 15 identical GUIs, one for each channel, and don't want to change the names to be unique for each channel. If the scope was the patch, that would work nicely. And if I could rename based on channel number, (or voice number in poly) that would work too.

However, I may experiment more with usine objects, and figure I'll just need to group controls in the script by subpatch, so the script can add and remove prefix strings as needed.... I already put all the control names into arrays by data type, I'll just need to further subdivide by location.... I can store the substrings as constants, but of course they'll need to change any time I re-name a subpatch.

[woodslanding]

So I am trying the usine objects, and running into a problem.

When I have a control whose name is changed programatically, I create a custom name for it that will not change, using alt-click. Problem is, now in the local object name list, the simple value for the control shows up under the caption name, but NOT under the [unchanging] control name. Seems like it should show up both places.

I guess I can query the control for its caption, and use the resulting string to change its value. Or else I shouldn't do dynamic captioning, which means creating a lot of new textfaders.

Hmmm. Keeps getting messier...

Is there a better way?

[woodslanding]

Well, I got this mostly working, but the above is a real headache. If I query the control for its caption, I still need to add dashes (and truncate it?) in order to get the actual ID of the control. It did occur to me to just use the Alt-name of the control, but that gives me nothing.

Also, my textfields are all coming up as '0'. I'm confused as to why there is no getObjectString command. But getObject is not giving me a string at the moment.

Going to bed, I'll try again in the morning. Tomorrow I'll try with the beta, maybe it will work better. But I don't want to lose backward compatibility working in the beta, since I can't use the beta in production (because of the rack count limit in the free version) and I don't have an actual release date....

[woodslanding]

Fixed in the beta, but new issues, sent bug report.