A couple of IML-suggestions

[antwan]

Here's my IML-wishlist so far, for this near-perfect tool:

1)
Ability to set target patch to be a certain sub-patch and then do IML-commands within that sub-patch.

2)
IML-created names (module names etc.) should maintain letter case and be case-sensitive.

3)
When creating a sub-patch FROM FILE using IML, it would be great if the loading-window (the big semi-transparent progress-bar window) would either not appear at all or would be something small in the top-corner.

4)
Would be great to have access to a module's layout settings via IML. For example:
- Create a switch module (currently possible)
- Set the switch's visibility to Interface Builder (currently possible)
- Position the switch at X:100 Y:100 in Interface Builder
- With size 150x30
- Using layout-preset 'Switch01'

These additions would certainly make my day... year.

Side-note:
I found out (pure luck) that there is also a DELETE_MODULE command but this seems to be undocumented.

Cheers,

antwan

[Vincent]

Yes, yes, very good Antwan!
+1 for all

More about the loading window, it also sometimes hides other important VST loading windows (Altiverb, GVI...) so:
since it can be usefull to have it anyway, would it be possible to implement it in the trace window (just like the quantize warning)?
The start-splash can of course stay as is.
No?

[senso]

The IML was designed for the template engine, so something simple.
I didn't realize that it could be so popular!
I can turn it into something more powerful

1)
Ability to set target patch to be a certain sub-patch and then do IML-commands within that sub-patch.

ok,

2)
IML-created names (module names etc.) should maintain letter case and be case-sensitive.

I'm not sure it's a good idea?

3)
When creating a sub-patch FROM FILE using IML, it would be great if the loading-window (the big semi-transparent progress-bar window) would either not appear at all or would be something small in the top-corner.

I'll see if I can disable the progress bar. It looks easy but in fact it's not so...

4)
Would be great to have access to a module's layout settings via IML. For example:
- Create a switch module (currently possible)
- Set the switch's visibility to Interface Builder (currently possible)
- Position the switch at X:100 Y:100 in Interface Builder
- With size 150x30
- Using layout-preset 'Switch01'

could be possible of course, but we have to fix a limit of functionalities?

Side-note:
I found out (pure luck) that there is also a DELETE_MODULE command but this seems to be undocumented.

It's a mistake. corrected

[antwan]

The IML was designed for the template engine, so something simple.
I didn't realize that it could be so popular!
I can turn it into something more powerful

Yes, don't ignore the fact that you have created something ground-breaking

2)
IML-created names (module names etc.) should maintain letter case and be case-sensitive.

I'm not sure it's a good idea?

Well, this is naturally not crucial. You are right that there's a greater chance of coding errors when case-sensitive, but on the other hand I think we're quite used to it thanks to previous scripting work. Maybe we can leave this for now and gather more opinions.

3)
When creating a sub-patch FROM FILE using IML, it would be great if the loading-window (the big semi-transparent progress-bar window) would either not appear at all or would be something small in the top-corner.

I'll see if I can disable the progress bar. It looks easy but in fact it's not so...

I understand. But as Vincent pointed out there are several reasons why it's causing trouble when fired by IML. Because now it's not only happening while we prepare & patch but also during a live show.

4)
Would be great to have access to a module's layout settings via IML. For example:
- Create a switch module (currently possible)
- Set the switch's visibility to Interface Builder (currently possible)
- Position the switch at X:100 Y:100 in Interface Builder
- With size 150x30
- Using layout-preset 'Switch01'

could be possible of course, but we have to fix a limit of functionalities?

My current opinion is that this addition would pretty much complete the required functionalities. Otherwise we will quite often end up in a situation where we can automatically create modules and wires between them but that does us little good if we don't see the results or get access to them as part of our custom interface.

Side-note:
I found out (pure luck) that there is also a DELETE_MODULE command but this seems to be undocumented.

It's a mistake. corrected

Thanks. Now everyone knows of it's existence!

I'm not only having fun with this I'm also getting clear-cut gain in performance. I've remade a patch that used to take 5-8% of CPU when sitting idle. After remaking it with help of IML (excluding the interface) it's down to 0.8-1.2%.

Best regards,

antwan