[SOLVED]✔ VST: Win32API not work?

[Tronic]

as the title says, does not work when exported as a vst.
I run the example in the manual, to capture the movement of the mouse cursor.
But it works fine when run in Flowstone.

[trogluddite]

Probably the plugin cannot find the Win32API library - it is an extension to Ruby that is stored in a separate file, so if the plugin cannot find that file, the .dll call will not work.
The files are in the Ruby folder of the FowStone install, and a copy of that folder will be needed whenever you use the plugin in a different environment.
The easiest way to do this woud be to copy the folder into the same location as the plugin .dll, and then you'll need to add a little bit of stuff to the plugin to make the file visible.
- Add an extra string input to the Ruby primitive, and call it something like "my_path"
- Connect a "start folder" primitive to this input
- inside the code, add the following code...

Code: Select all

$LOAD_PATH << (@my_path + '/Ruby/libraries/win32/i386')
$LOAD_PATH << (@my_path + '/Ruby/libraries/win32/common)

That will point the library loader at the files inside the "Ruby" folder that you copied into the plugin directory.
NB - from memory, haven't tested yet. The principle is right, but I may not have typed the paths exactly right - if you type $LOAD_PATH into a blank Ruby primitive, you'll be able to see the correct names of the sub-folders.

[Tronic]

THX
OK got it

[trogluddite]

Quick correction.
After re-reading the User Guide, it seems that if you put the entire Ruby folder in the same location as the export, the $LOAD_PATH code should not be required - it looks like the export 'home' folder is automatically added to the default search locations.

[Tronic]

Quick correction.
After re-reading the User Guide, it seems that if you put the entire Ruby folder in the same location as the export, the $LOAD_PATH code should not be required - it looks like the export 'home' folder is automatically added to the default search locations.

i tried not work in vst mode, the load path in vst work different.
$LOAD_PATH point to a virtual path like this:
C:/Users/<username>/AppData/Roaming/lib/ruby/......
but it not realy exist.
i have found $EXE_PATH and $INSTALL_PATH
but it point to CWD directory, ie, the last or current working directory used in your Host.

so I think for now it is mandatory to define the load path of the vst.
I defined it as a class variable @ @ Path_MyVST, taking the value as you suggested from the primitive Start folder.
I have not declared as gloabl variable to avoid future clash with other plugins.

[trogluddite]

Ah thanks - I hadn't tried it yet, so that is good to know.

BTW) A class variable will work the same as a global variable for FS plugins - because all Ruby primitives are instances of the same class, RubyEdit. I've even done a couple of experiments deliberately passing values between two plugins using class variables, and it works very well (or badly, depending whether you want them to or not!)
This is going to be something that we'll all have to learn to deal with.
Best not to use RubyEdit class variables at all - even if you are very careful with naming, this will not help if two instances of the same plugin are loaded at once.
Modules and classes are simlarly visible across plugins, but that is slightly less of a problem, as the actual objects made from those classes will be local. The common practice in other Ruby enabled app's is to always wrap cutsom class definitions inside a Module named after the developer etc. - just in case two people use a common name for a new class and overwrite each other's methods. And NEVER redefine one of the built in Ruby methods - sounds obvious, hut I have had my CAD software brought to its knees by a plugin that did this!

In the case of 'require', appending the paths to $LOAD_PATH from an instance variable is probably safest. Require only ever loads the same library once anyway (so custom libraries must have unique names!) - plugins loaded later will know that "win32api" is already available and not bother loading it again. (there's a different method 'load' that does re-load the file every single time).

[infuzion]

BTW) A class variable will work the same as a global variable for FS plugins - because all Ruby primitives are instances of the same class, RubyEdit. I've even done a couple of experiments deliberately passing values between two plugins using class variables, and it works very well (or badly, depending whether you want them to or not!)
This is going to be something that we'll all have to learn to deal with.
Best not to use RubyEdit class variables at all - even if you are very careful with naming, this will not help if two instances of the same plugin are loaded at once.
Modules and classes are simlarly visible across plugins, but that is slightly less of a problem, as the actual objects made from those classes will be local. The common practice in other Ruby enabled app's is to always wrap cutsom class definitions inside a Module named after the developer etc. - just in case two people use a common name for a new class and overwrite each other's methods..

This does not sound good; will this be fixed soon?
I think we could use clearer workarounds for this please...

[trogluddite]

Yes, I'd like to see something done about this too - it will potentially lead to a lot of confusion.
Prior to FS going VST, it was probably not such an issue - but multiple instances are par for the course for us.
Not sure how you'd deal with it though - firing up a separate instance of the Ruby interpreter for each plugin would be very wasteful of resources.