Another IML Question(s)..

[gurulogic]

I'm trying to wrap my head around how to work with variables or "destvariable" in IML. I am assuming that the get functions
can get a value from one module that can be applied to another (or same), for example, "GET_VALUE modulename terminalname destvariable" would be [GET_VALUE]=Get the value from>[modulename]=Name of the module> [terminalname]=the caption/pin to retrieve the value from> [destvariable]=the stored value that can be retrieved for other uses?
Assuming I'm on the right track, or even close, what I'm not getting from looking through the wiki documentation is how I would assign the retrieved value to another module's value.

(Rather than spamming the forums with new topics, if I have any further IML related questions I will try to keep them here. Thanks for patience! )

[23fx23]

yes destvariable is kind of temp buffer variable with given name, so to reuse use same name

GET_VALUE VSTNAME_A PARAM_TO_GET TEMP_VARIABLE_NAME = get value from vstA param X and temp store to tempvariable

SET_VALUE VSTNAME_B PARAM_TO_SET TEMP_VARIABLE_NAME = reapply value stored in buffer to vst b param X

[gurulogic]

Of course.. its when it is too easy that I get lost..
Thanks!

[gurulogic]

When I drop an VST on a subpatch, and use the IML template for clear patch and open plugin, the behavior I see is not what I would expect. The wiring inside the sub patch is connecting the wrong pins internally until I double click on the sub patch. In this first example , I have just dropped a VST onto an empty sub patch, and none of the i/o pins are visible on the patch. As there is no wires connected to the sub patch one might say just a GUI refresh issue, but this is not the case.


When I double click on the sub patch, then return to the parent view, the i/o pins are correctly displayed


Now if I Wire some of the i/o pins (to show a better visual example, and to also confirm incorrect internal wiring) and drop another (or same) VST on the subpath, the internal wiring is all funky again. Once again this is not a GUI refresh issue, the sub patch wiring is definitely wrong. Each time I reload the contents of a sub patch in this fashion, the internal wiring sems to randomly change, but it is always reset after double clicking the sub patch. Does anyone else see this sort of behavior in their Usine HH setup? I am wondering if perhaps sub patches are just not intended to be used in this way or if what I am seeing is a bug of some sort..?


Also, in my digging around the concept of IML and sub patch loading / wiring I am noticing the behavior for wiring sub patch pins to be a little quirky. For example, audio inputs to a sub patch can be addressed by terminal name in IML. however audio outputs cannot? Also, in order to load a patch and wire patch i/o modules pins by terminal name, I need to send the CREATE_LINK messages in a separate message after the patch has loaded. Is I use terminal numbers instead of names, I can put the commands for both load patch and create link in the same send message module, so it seems there is a lag for terminal names access?

Also it seems strange for me that that if I insert an i/o module in the sub patch, all of the following terminal numbers are changed, so for example if the terminal number for name out in a sub patch is 11, and I add a data in module to the sub patch, name out is moved to terminal position 12, which breaks and existing IML for wiring to that pin (and no pins below bitmap in and bitmap out are addressable be terminal names at all)

What would make more sense to me and be a lot more user friendly for IML access of sub patches i/o is if all of the default i/o of an empty sub patch had fixed terminal numbers, and any additional 1/o would be be added to the bottom of the terminal index in the order added to the sub patch, and if all terminals could be accessed by name.

I'm still just learning my way around this stuff so maybe this is all normal, I am not really sure.. But maybe if there is some unusual behavior in sub patch i/o handling / IML etc it might explain why sometimes wires in patching have wiring to the wrong / no pins or error messages when i/o modules are created or renamed..

[woodslanding]

I can verify this bug. If I load a subpatch via IML, I see extra outputs which disappear with a double-click. Did you log a bug report yet?

I've addressed everything by number, so I don't know about addressing by name.....

[gurulogic]

I did report it yes. Nay was unable to reproduce but it is forwarded to Senso. Have not heard back specifically on that since, but was hoping to track down perhaps a machine/system specific root cause in the meantime. One thought is maybe the IML is processed too fast and the patch gets confused. I know that in the case of loading a sub patch and then wiring with IML via names rather than numbers I have to wait X milliseconds after the patch has loaded to send the IML for creating links to terminal names.Terminal numbers don't have the same lag to be available for creating wiring links. Accessing terminal by name makes so much more sense for IML wiring to sub patches because of how easy it is to change terminal order and mess everything up. My OS is Windows 7 64 bit btw.

[woodslanding]

Well, I am no help, as the prob has disappeared here, and I"m not sure what I did to cure it :^/