DSP Robotics Support

and i was so close to change some routines of my plugs into ruby...
I'm glad to see you guys discussing these issues and it seems that FS is no real option for commercial VST releases at the current state!

stw wrote:and i was so close to change some routines of my plugs into ruby...
I'm glad to see you guys discussing these issues and it seems that FS is no real option for commercial VST releases at the current state!

No definitely not right now. I feel it could be the most powerful easy to use software if they make the right decisions on the fix. If not, then who knows where we'll end up. I have faith in these guys though and I believe they will do the right solution of which I can only see two that will work for everyone, and one that will work for a small subset of users.

-Either get it statically linked.
This is the perfect solution!

-Change and use Windows Scripting Host
This is a great solution although not perfect because some people do not have scripting turned on in Windows. I have never come across this yet though..

-Require the user to install Ruby themselves.
This is the least liked fix because it would require all SM plugs to have the user of those plugs install Ruby. There would be a big set of complaints regarding this move, in fact its not really an option because of that. In a normal world this would have been the way to do it in the first place, but the audio plugin world is different in that snobbery from other developers and users is rampant. You can have a perfect functioning, low CPU VST and because it was made in SM they will complain about it and flame it. Can you imagine now telling everyone they have to install additional software now too for it to run? Forget it. If it were not for that, then this would be a good option..

Hi all,

It should be pointed out that it is not necessary to "install Ruby," but merely the Ruby interpreter DLL. There is a huge difference between these two tasks.

Having users install the DLL does not mean that the current wrapping method ("one file" solution) needs to be abandoned, nor does it necessarily mean that users need to independently install anything --- this is simply another file that could be part of an installation program or script, just as transparent to the user as the current hidden installation (overwriting at run time).

Not wrapping the Ruby interpreter DLL could be an export OPTION for Flowstone for those of us who want to put the Ruby interpreter DLL in a more suitable place and handle it according to widespread programming practices.

I would like to see either static linking OR the OPTION to skip wrapping of the DLL and allow me to include the DLL installation as part of the overall installation process (which could be as simple as copying the exported DLL and the Ruby interpreter DLL to specified locations).

Static linking is not the "only real" solution; it is a solution, and it has its own drawbacks as well as advantages. For example, bug fixes to the interpreter and improvements to it cannot be easily propagated. A bug fix to the interpreter is a bug fix to the Flowstone exported DLL as well, potentially requiring redeployment everywhere of ALL such DLL's.

However, if static linking would actually work and work the same as dynamic linking, I would accept that gladly over what it being done now.

Regards,
Dave Clark

Yes good points Dave. I didn't think about the Ruby DLL updates when statically linking, that could be a problem in and of itself.

We're going to be having another look at static linking and some of the other options that have been suggested. Might take a bit of time to explore this though so please bear with us.

Many thanks.

Glad to hear you are investigating these topics. I did some research on the "only 1 Ruby interpreter per process" topic and for me that seems to be the most difficult but nevertheless necessary problem to solve.

rlr wrote: ... most difficult but nevertheless necessary problem to solve.

"Difficult" --- probably so.

"Necessary" --- depends on what Ruby is asked to do, so one actually has a lot of control over how "necessary" this is.

Regards,
Dave Clark

The method of .dll linking certainly doesn't bother me so much - but then I'm not releasing software on the open market, so I'm not sure I quite undertand all of the consequences.
The chance of 'cross-talk' between plugin instances does bother me a lot though, that could well end up affecting users who don't share plugins, or even those who never share and never use anyone else's. I've made a couple of suggestions to Malc to see if a different method of using the namespace for RubyEdit might help with that if a way cannot be found to have separate interpreters.

@Support..
We should NOT be distributing VST and EXE files though right?

DaveClark wrote:
"Necessary" --- depends on what Ruby is asked to do, so one actually has a lot of control over how "necessary" this is.

There is a big chance VST plugins break other plugins without knowing.
Scenario: user loads VST plugin made with FS into VST host. Plugin loads Ruby dll and starts ruby interpreter. User then loads a 2nd plugin made with FS. In case the ruby interpreter can only be loaded once per process (the VST host), the 2nd plugin's ruby code has to be evaluated by the ruby interpreter that was loaded in context of the 1st plugin. In case the 2nd plugin would need a different ruby: Game over.
Consequences: It is not allowed to customize the ruby runtime. Future versions of ruby need to be 100% compliant to old versions. FS *now* needs to do a version check before unpacking the ruby dll from the VST dll into the appdata\roaming folder (don't overwrite newer version).
But thats mostly speculation from my side. Im pretty confident, the devs find a proper solution, since the problem would also apply to FS running as a FLstudio generator.