DSP Robotics Support

Yes, I think it could be great development environment too, of that I have no doubt. There is some mis-steps, thats to be expected its new. As far as I can tell, the robotics guys don't seem to have put it through its paces in terms of the audio side of things either. So natually since we're here now, the audio side of things will be tested a little further. As a matter of fact, this error was caught because the Robotics side opf things works a little differently than the audio side of things. On the robotics side it would be less likey to have 10 robotics EXE programs running at once, whereas in audio processing, having 10 vst plugs running is entirely possible. So in that case, if there is ever only one FS EXE running at a time then this error would not matter. Its only when you start getting more than one running where the user has edited the Ruby DLL for whatever reason.

As a guy who went through all the trials and tribulations of SM, having to create a text files and then load them back in when some external process had ran, etc.. Having to rely on batch files and external languages just to get the simplest of tasks done. I've just been noodling around in FS and Ruby again and this is absolutely fantastic. I am just bummed out beyond belief at the amount of power FS devs now have at their fingertips with Ruby, yet this error exists.. Damn it! I can see such a bright future for this application as long as crazy stuff like this is not done anymore and when you add a prim you open it up completely.....

Sorry to keep you waiting.

I'll start by clarifying how everything works and I'll explain why we made some of our decisions.

As you've seen the Ruby dll is wrapped into the export and then extracted to the App Data folder. We couldn't extract to the export source folder (where the exported exe or dll has been placed) because it could be a folder under User Access Control so unless you ran as admin or worse asked for elevated user rights writing to the same folder was a no-go.

Another option would have been to leave it to users to distribute the ruby dll alongside their export. This we didn't feel would be as neat. We also didn't think that users would like having to distribute more than one file.

Static linking of the dll was mentioned. This would have been our ideal option - no dll to deal with. The problem is we tried very hard but just could not get it to work this way.

So this is how we ended up with the solution we have. It will all work so long as the dll doesn't change. However, as people have been looking at how much further they can push things they have discovered that the dll can be changed and as you've observed here this could cause compatibility problems if you make an export with a new dll and it is used alongside an export which uses the original one.

Whilst we didn't originally envisage anyone building their own ruby dll it would be good if we could find a way for this to work alongside everything else.

We will have look at it this week.

One thing that we know is running two or more Ruby interpreters within the same process doesn't work. I'm pretty sure this rules out having differently named dlls for each export.

Hey support. I've noticed that you avoid "user selectable options" and their "default settings" in general preferences. Such approach would work for toolbox, views (with or without scrollbars), mouse/zoom behaviors, as well for ruby behaviors and maybe for other more specific stuff. More advanced users can change such options, knowing what this means, don't you think? You seem to "force" people to use "the only right choice", which is not always the only one comfortable option. And it still can be simple.

Hi all,

If it was I who had to provide a short-term solution, I would:

1) Rename the file mscvr90-ruby191.dll to something like dspr-mscvr90-ruby191.dll because the FS version is NOT the same as the official ruby DLL. (Ref: FS User's Guide.)

2) Create a structure such as DSP-Robotics/Flowstone/Ruby/lib (with backslashes if you prefer...) in either <username>/Application Data or in the appropriate "Program Files" folder.

3) Remove the wrapping of the DLL and bad overwriting behavior. This is tantamount to a "hidden" installation at the root of "Application Data" every time the DLL is loaded. Even worse, the DLL cannot be protected as it could be under some versions of Windows through a proper installation, i.e. in "Program Files."

4) Inform the FS community that they need to ensure that they and their users INSTALL the FS version of the DLL and folder structure. This is a very small price to pay for the additional power of "Ruby-Inside." This installation would allow one to place it into "Program Files" if desired, something that is a problem with the current wrapping and overwriting, the overwriting being prohibited in many cases (and why is that, one should ask, leading to an understanding of why the current behavior is unacceptable). This installation could be as easy as copying the folder structure into the target folder with the appropriate rights granted.

Just a suggestion.....

Regards,
Dave Clark

support wrote:Static linking of the dll was mentioned. This would have been our ideal option - no dll to deal with. The problem is we tried very hard but just could not get it to work this way.

I found some people struggling with static linking, who finally found a solution fairly recently:
http://klayout.de/forum/comments.php?DiscussionID=196&page=1

Could this be helpful?

support wrote:...
One thing that we know is running two or more Ruby interpreters within the same process doesn't work. I'm pretty sure this rules out having differently named dlls for each export.

Ouch. Looks like a limitation. Scenario: with Ruby 2 around the corner in case a future FS version updates to use Ruby 2, this would mean that VST plugins built with the current version of FS cannot run together with plugins built with a future FS version in the same VST host. Right?

I can see why the choices that were made, were made...

Here is something to consider, it might not be an option given all the time already spent on Ruby, but it does provide a relatively quick fix and should be as clean as static linking.

Windows Scripting Host..
Why can't you just embed that into Flowstone? I have done that in the past and it was quite a trivial process. As simple as creating a link to a COM object and then sending your code to it as a property. What I did not do however, is handle events with it, but that seems to be a relativbely trivial matter too. As long as the scripot event handler has trhe correct name then the event will be fired.

So the positives of using WSH are

-It automatically supports two wide spread, well known languages right out of the box. VBScript, and J-Script. There is support for Ruby, Perl, Python, TCL, and pretty much any other language you want to through at it as well. Although support for the other languages has to be installed.
-There would be no need to install anything external(unless you were going to keep the Ruby support)
-Adding new custom FS classes to it are as simple as sending code to the component when its started.
-Standard Code base that is maintained by someone else!
-It should literally just drop right in your code, and you should be able to pass it a ready made class to interact with.
-All systems that a DLL or EXE is likely to ran on will have WSH
-All Windows OLE is already handled, you need to do nothing for it..
-DirectX is also immediately available.
-ADSI is available out of the box
-ADO is available out of the box
-Essentially every Windows service is available with no or very little hoop jumping immediately.
-Has been in service since Windows 98 so its dug in and not likely to go anywhere any time soon.
-Most of your robotics customers will have developers on staff that know these languages already so its a selling point for FS's other service.

I mean, really, lets face it, FS is never going to support MAC, so, lets understand that and move forward. If it is going to be a Windows only based system, then it should support all windows functions internally and without hinderance. If its going to be single platform then then lets make it amazing at running in that platform.

Unless you can get the Ruby DLL statically linked, then there's not many favourable options left. I just don't like the idea that my software development platform performs a hidden installation every time my plugin gets scanned, let alone loaded. No one has even mentioned clean up, what happens if the system crashes, that DLL gets left where it is. In fact does it actually delete the dll when the plugin/exe stops running? I think if you go down this road any further you are going to have more trouble and it will take you more time than if you just bit the bullet and went with the WSH. Ruby can still be supported as far as I know as well. So, I think if you install ActiveScriptRuby WSH supports it. I have not tested this myself, so I will stop short of saying for sure it will work.
ActiveScript Ruby download
http://www.artonx.org/data/asr/

I really hate to give you guys a hard time about this, but In my opinion the only real option is static linking, which I know was what you were originally thinking. We had conversations where I mentioned static linking CINT and you had mentioned about static linking Ruby, so I know this copying DLL stuff was never part of the plan and its just a fix. If you were only dealing with the Robotics side of things, then no one is going to care if they have to install support files, so including the Ruby DLL as an installation would be fine, but you also have the VST side of things. I cannot imagine trying to explain to KVR users that they need to install another DLL in addition to the VST DLL. So really, like I said, static linking is the only real option. Second on my list would be to include the Windows Scripting Host if the static linking does not work. At the very least I would start running some tests on it to see if its even viable...

Here is the Windows Scriopting MSDN information
http://msdn.microsoft.com/en-us/library/fdee6589(v=vs.94).aspx

Best of luck..

TheAudiophileDutchman wrote:

support wrote:Static linking of the dll was mentioned. This would have been our ideal option - no dll to deal with. The problem is we tried very hard but just could not get it to work this way.

I found some people struggling with static linking, who finally found a solution fairly recently:
http://klayout.de/forum/comments.php?DiscussionID=196&page=1

Could this be helpful?

That looks promissing...

rlr wrote:

support wrote:...
One thing that we know is running two or more Ruby interpreters within the same process doesn't work. I'm pretty sure this rules out having differently named dlls for each export.

Ouch. Looks like a limitation. Scenario: with Ruby 2 around the corner in case a future FS version updates to use Ruby 2, this would mean that VST plugins built with the current version of FS cannot run together with plugins built with a future FS version in the same VST host. Right?

Thats a really good point I never thought about...We'll have to wait and see..