DSP Robotics Support

I think I'd rather prefer that every plugin DLL would contain its own ruby interpreter. Technically there is no need to deploy the Ruby interpreter as an extra DLL. It could be statically linked with the other flowstone code. The DLL size is 1.19 MB. No big deal on a 32 bit address space. (A minimal flowstone-created VST DLL is about 2.5 MB)
Security consideration: Imagine someone builds a malware msvcr90-ruby191.dll and puts it in the users .\AppData\Roaming folder. Would all FS built plugins now execute malware code? (I should do some more test).

OTOH: the shared interpreter should allow some cool side-chaining audio processing.

No matter what way I look at this, Flow Stone cannot remain to function like this...
I wish I had good news for you guys at DSR and Outsim, sorry, but this is a bad situation and bad coding practice. This has the potential of turning all Flow stone applications into a jumbled up mess like Windows used to be back in the Windows 3.x days.

Back then people would customize the Windows API files, you would install a program and all of a sudden other programs would stop running. Why? because when you installed the last program it overwrote DLL files with its own custom versions. Sometimes programmers would remove functions to save space and make the DLL source more readable. The problem is other programs relied on them! Microsoft incorrectly assumed that no one would ever remove funtions from the DLL files. Programmers assumed that no one would ever overwrite their customized DLL with a new one as a result of installing. So you ended up with just a big mess and no one knew what was supposed to be where.

Well Flowstone has the potential to do the same identical thing, but will only target its own customer's programs! Other software on the system will continue to run, but under certain situations your programs won't.

I had every plan of making my own custom Ruby DLL with my own objects and other things. I totally thought that I would need to install it and would need to identify what DLL I want my plug to use. None of that is possible, you cannot tell Flowstone to use "DannyMansAwesomeRuby.DLL" it will only use Ruby1.91.DLL. The ruby dll is specified by flowstone and that setting seems to be hidden. I cannot find anywhere that it lets me specify what DLL is to be used.

So, Here's a scenarios...
FS Dev A creates his own Ruby DLL compiles his plug, everything works fantastic! So release day comes, now tons of people are using it, awesome! Joe the VST freeloader loads a plugin made by a different flowstone developer, FS Dev B. FS Dev B has done nothing different to their Ruby DLL, there's no custom functions. Now Joe loads FS Dev A's plug. It sees that the Ruby DLL is already present so it does not try to overwrite it. It's already present because FS Dev B's plug created it. Guess what?, FS Dev A's plug does not run because the customized functions in his Ruby DLL do not exist in the DLL created from FS Dev B..

Another scenario
FS Dev A is a total idiot, He thinks the Ruby DLL is too large and he only needs a few objects, so he thinks he'll just delete the objects he never uses. Joe the VST freeloader, loads FS Dev A's DLL. seems to work great! Awesome he thinks, I got a great new plug for free! Then he decides to load a Bootsy plugin and the system crashes. Its not because of Bootsy's plug, although to the user, thats the plug he'll blame. Its because FS Dev A the idiot deleted all the Ruby DLL objects and Bootsy's plug relies on them..

-There is absolutely no way, so long as you can edit the Ruby DLL that this type of system can work. You just cannot guarantee your plug or executable will run.

-There is no way so long as you cannot specify a custom name for the Ruby DLL that this system can guarantee every plug or executable will always work.

Guys come on...
You have a new product, a chance for it to make a decent name for itself, now with this type of thing people will be saying everytime you load an FS plugin you run the risk of having to reboot your daw. That leaves everyone who makes plugs with it persecuted again, like we didn't get enough of that with SM..

I don't understand why you guys decided that packaging up a dll file inside another, then copying it out and into a folder, then the original dll file could make calls to it.. Why did this process get accepted?

Something like this should have been handled with a recompile of the FS DLL and the ruby dll, not just a wrapper with a ruby dll placed inside it. These commands should be internal to the plug, in other words live inside it without a Ruby.dll file at all. Is there not C++ compilers that you can distribute with FS and have the DLL's recompiled, maybe just linked? That to me is the proper way to do this, the easy way (duct tape solution) is to simply allow us to specify the Ruby DLL to include. Thats not an attractive option though...

Right now, no matter what you do, or what you created, you cannot guarantee your plug or executable will work until this is fixed. If you release software with this flaw still in FS, as is right now, and someone else releases software with a custom Ruby DLL thats missing functions your plyug will crash if its loaded 2nd.

Life-based scenario: Are you experiencing instabilities? Nope? Then forget it
Besides FlowStone is for different purposes developed if you haven't noticed, not only for audio.

p.s.:
If you call someone a total idiot, then it's very probable, that you are not better one; discuss but show a bit of respect.

tester wrote:Life-based scenario: Are you experiencing instabilities? Nope? Then forget it
Besides FlowStone is for different purposes developed if you haven't noticed, not only for audio.

You missed out one very important word. "Are you experiencing instabilities YET ?". It's very early days for FS and Ruby, but as the library of downloadable schematics on the forum starts to grow, the potential for problems will grow exponentially....

Scenario 1...

tester wrote:Troggie troggie - could you make for me - editable timeline with adding/removing points?

So I write one for you - it's a complex bit of graphics that would really benefit from a new class of objects called "TimePointer". It works great, and the use of "TimePointer" objects makes the code simple to understand so that you can customise it easily. You love it, so you use it inside several of your schematics.

A few months later you need a clock to time the interval between mouse events, for another cool project you are working on. Lucky you - one of the other guys has written a module to do just that - so you download it, put it into your schematic - and now both this plugin and the old 'Timeline' one start behaving erratically.
Because the author of your new 'clock' module also created a new Ruby class called "TimePointer". Those two definitions of the class are guaranteed to have at least one method in common - the most important one of all, "initialize", that creates the a object when you invoke "TimePointer.new".
Are you going to edit and rewrite those two class definitions yourself to fix the problem? What if they are from compiled 'C++' libraries that you don't have the source code for?

Scenario 2...
It's now 2020, and our FS toolboxes are full to overflowing. You open one of your early plugins, only to find it's not working any more? Hmmm....
Then you remember that when FS5 was released there was something in the release notes about Ruby having been upgraded to the latest version. The scoping of variables within loops and blocks has been subtly changed, and now there are loads of custom modules inside your plugins that are misbehaving.

This situation does happen - between Ruby 1.8 and Ruby 1.9 there were subtle changes to the way that file paths were parsed for 'requires' and 'loads' - and this messed up quite a few people's nicely worked out Ruby routines. And changes to variable scoping are mooted for Ruby 2.0 when it comes out.

Making sure that each export runs in its own "sandbox" would prevent this by ensuring that each export had access to whichever version of the libraries was current at the time of export.

Now is the time - ESPECIALLY for non-rubyists.
So I think it is very good to have a debate about this now, BEFORE we start seeing these problems. The Djinn is now out of the lamp - maybe the developers thought we'd only use Ruby as a form of "Green Code", but the things it can do once you get fully "object oriented" are too powerful to ignore.
As I said before, you do not need to be a Ruby programmer for this to affect you - all of us are using modules we downloaded from the forums every day, and we are used to just plugging them in and they work. We need uploaded modules that use Ruby to be equally robust, precisely because it is the non-Rubyists who are in the weakest position to fix broken Ruby modules.

tester wrote::-D
Life-based scenario: Are you experiencing instabilities? Nope? Then forget it
Besides FlowStone is for different purposes developed if you haven't noticed, not only for audio.

p.s.:
If you call someone a total idiot, then it's very probable, that you are not better one; discuss but show a bit of respect.

ok well we've obviously found our FS User A.. In a user called Tester

In my post I didn't call anyone, an idiot, it was a fictitious user. I will read my post again and see if it could be interpretted as me calling someone an idiot, and if not then you, owe me an apology...

Yes Trog, and anyone who can understand the situation, for sure this is going to happen. Like I said unless it can be guaranteed that no one will ever edit the ruby dll. I think that by not allowing the RUBY DLL to be edited it may violate the license in some way? I don't know for sure though I need to look into it.

All they have to do for a quick fix is allow us to specify the DLL name. Its absolutely not the proper way to fix it, IMO, but it would work for sure.

tester wrote::-D
FlowStone is for different purposes developed if you haven't noticed, not only for audio.

I'm sorry to have to say this, but that is a moronic statement and shows a total lack of understanding of the problem...
"tester"... This affects all Flowstone developments!
In fact it will affect EXE files that do not process audio, and it will affect audio processing plugs. It will cross contaminate between them as well. So running an exe that does not process audio, could contaminate a plugin that does. Running an audio processing plugin could contaminate an executable that does not.

VPDannyMan wrote:In my post I didn't call anyone, an idiot

Calm down guys...
Think maybe we just have a little translation problem. When you are a native English speaker, it becomes obvious when "you" means "you" rather than meaning "one" or "anybody" - seems most other languages are a bit more strict about that kind of thing!
@tester - honestly, Danny was not aiming his remarks at any particular person, it's just a quirk of the English language.
But seriously, this is something that could cause eveyone serious headaches if we don't get it sorted, though it is hard situation to understand until you get a little deeper into Ruby.. What it comes down to ...
You want all the modules you download from the forum to work reliably, surely?
@Danny - I've known tester through the SM forums for a long time, he's a cool guy - please don't let a misunderstanding become a flame.

Back on track.
I think my personal preference would be for the folder containing the export (and sub folders) to automatically be included in the targets to search. This would make including Ruby files for "requiring" much simpler too.
If the required files (or Ruby interpreter .dll) are not found there, then default to the current method, otherwise always use the "local" versions.
It would also make passing around schematics etc. easier - just .zip them along with their "support" files, and then 'explode' the zip file at whatever location you want, knowing that all the files will be in the right place without any further file management.

trogluddite wrote:

VPDannyMan wrote:@Danny - I've known tester through the SM forums for a long time, he's a cool guy - please don't let a misunderstanding become a flame.

Fair enough, and for the record Trog, you and I have known each other for years...

So yes, lets move on..
I think their idea was to have it so that one only needed to supply a DLL and not have to include the Ruby DLL when distributing your app. If thats the case, then statically link the RUBY DLL with the FS dll and call it a day. Sure there's no editing possible of the Ruby DLL, that a bummer, but that avoids this problem, and it allows the users to not have to supply an external Ruby DLL.

I can't understand why they did it like this in the first place? If the intention was to allow you to edit the ruby dll then they should have allowed you to specify a name and enforced a naming convention for the Ruby DLL. Perhaps the Name would have to be a GUID or something. That would ensure uniqueness..

VPDannyMan wrote:I think their idea was to have it so that one only needed to supply a DLL and not have to include the Ruby DLL when distributing your app.

Yes, i can understand that - but even if we stick to the standard .Ruby dll, we might still want to add other custom libraries. For pure Ruby code, that isn't much of a problem, as they could even just be resident inside Ruby primitives inside the schematic.
But that won't work for compiled .so libraries, or for any of our own .dlls that we want to include alongside an export. And to my mind, if we're sharing this stuff with 3rd parties, we need to make sure that they don't end up with any file management headaches.

I've just posted to the dev's with a couple of suggestions that I think might help...
1) Export option "Run in a separate Ruby instance"
2) Plugin folder path added to the default load paths (it isn't at the moment)
3) A "Run me first" Ruby where we can safely put "requires" and class definitions knowing that it will always be parsed before there can be any method calls from other primitives.

I also just though - how about also an export option "When exporting, include this folder....". We put all the required "support" files into a particular folder, point at at, then every time you export, a zipped or self-extracting bundle is made.
This way, even if the main Ruby .dll is locked out, we could still bundle up individual classes and modules from any other Ruby libraries by putting their files into the "export with me" zone.