December 26, 2017 at 8:20 pm #73938
I’m revisiting a panel and making some updates, my DAW (Reason) now hosts VSTs so I am now looking to use my panel as a VST. However I have hit a problem.
LUA scripts in Ctrlr Standalone and the Ctrlr VST work fine. If I export an Instance or Restricted Instance from the Ctrlr VST it seems that none of the LUA scripts function.
Oddly the same panel exported from the Ctrlr Standalone works fine.
I am using a Mac running OS 10.9.5 and Ctrlr 5.3.0.
Any pointers would be much appreciated. Thanks.December 26, 2017 at 10:20 pm #73941
how about making a simple mini test panel to test a single script?
or a selection of operation types, so you can narrow it down?
a thought: when you run it in Ctrlr VST, it’s running Ctrlr
hosted in a VST plugin, isn’t it? ie: has everything it needs.
does the VST need to unpack any resources first time it runs?
have tried it in other hosts? ie: minihost etc.December 27, 2017 at 1:14 am #73942
Hi human fly,
Indeed, I will try a simple panel… that said the problem is anything LUA across the board, every single script both large and small.
To your second point, that is exactly what I thought and the fact that it works as a standalone but not a VST points towards an issue with the Ctrlr VST or my implementation of something the Ctrlr VST requires.
I tried my exported VST in Minihost and Defective Records Klee; same result no LUA.December 27, 2017 at 10:54 am #73943
- Topics: 16
- Replies: 72
- Total: 88
the problem might be the Ctrlr version you are using, if you use the latest build you shouldn’t. Atom said few times already that it is full of bugs and the Lua implementation might be broken there. I use a Ctrlr version from March 2016 and all works as intended. Cheers!December 27, 2017 at 12:57 pm #73944
Thats cured the problem!
It’s ironic as I recently updated due to using a really old version of Ctrlr.
Have a great day guys and thanks for your assistance,
M.December 28, 2017 at 10:47 am #73992
It’s gone again, how odd!
So it worked the immediately after I backdated Ctrlr then the next time I saved my panel and exported it… zilch. That doesn’t make much sense.December 28, 2017 at 4:36 pm #73995
kill your ctrlr.settings file?December 28, 2017 at 7:33 pm #73996
Hi human fly,
Thanks for the suggestion, I deleted the ctrlr.settings file as suggested, I also cleared out the ctrlr folder, deleted the com.instigator.Ctrlr.plist and by my exported VSTs prefs folder.
This worked and then again it failed.
But from this I have found that it seems to be an interaction between the com.instigator.Ctrlr.plist file and the exported VST prefs folder. Deleting these seems to sort out the problem until the next time I launch the VST.
Not sure where to go from here.December 28, 2017 at 7:51 pm #73997
soz, i don’t know… was just a wild tilt to help
remember that Win10 doesn’t allow unpacking of certain
files on first run – depends on directory permissions.
synthedit plugins always had a problem with this. was
with the *.sem files (that are really *.dlls)
the workaround was the run the file locally, and then
distribute with the unpacked files in the zip folder.December 28, 2017 at 8:06 pm #73998
I am going to try disabling some LUA drop down menus in my panel. I have noticed when I place my VST into the Reason rack from the side bar these drop downs all launch outside the Reason VST wrapper. Which isn’t right!
This may or may not be causing issues… but at least I should eliminate it.December 28, 2017 at 8:40 pm #73999
do your drop down methods have this at the top?
if panel:getBootstrapState() then return end
i think this is the script. basically load was
hanging because of popups.December 28, 2017 at 8:42 pm #74000
or this one:
-- This stops issues during panel bootup if panel:getRestoreState() or panel:getProgramState() then return endDecember 28, 2017 at 9:37 pm #74001
OK I disabled the drop down menus and deleted the methods for them, re-exported but still had the same problem. So it is not the drop down menus loading outside the VST that causes the LUA issues.
Regarding the above post this is the method I have in place:
-- This variable stops index issues during panel bootup if panel:getRestoreState() == true or panel:getProgramState() == true then return end
It does seem to come down to an issue with the instigator / panel prefs. Deleting these, especially the former cures the LUA issue.
Cheers M.May 13, 2018 at 10:34 am #83855
OK, so I found what was causing the issue.
It was a conflict between the Lua data in my old panel and my new panel, because the panels shared the exact same name. Ctrlr creates a preferences folder on the Mac that also shares the panel name, so if you have two panels with the same name but with differing Lua methods it creates a conflict.
So to get around this problem (as I was still using and referring to the old panel) I renamed the new panel.
I hope this helps others avoid the same issue.
You must be logged in to reply to this topic.