How to compile Ruby from source on Windows for FS3

[VPDannyMan]

OK.. That just increased Flow stone's power by at least 100 times. This is important and has to happen...

Question..
Where does the Ruby DLL live?
It is just copied to the same folder as your plug right?

[digitalwhitebyte]

OK.. That just increased Flow stone's power by at least 100 times. This is important and has to happen...

Question..
Where does the Ruby DLL live?
It is just copied to the same folder as your plug right?

When you use FlowStone it is in the folder of Flowstone exe.
When you export EXE or VST is embedded with it, and when executed it is exported in the ..\Roaming folder.

[VPDannyMan]

Exported in the roaming folder? Meaning pulled out of your plug and placed in the roaming folder?

[digitalwhitebyte]

Exported in the roaming folder? Meaning pulled out of your plug and placed in the roaming folder?

Yes

[VPDannyMan]

Umm..
I have never heard of anything doing that before. Is that a "normal" way to do things? I think I would much rather have the dll live alongside my plug in a folder under the shared VST pliugins folder.

[infuzion]

I have never heard of anything doing that before. Is that a "normal" way to do things? I think I would much rather have the dll live alongside my plug in a folder under the shared VST pliugins folder.

Seems to be. All exports are the .DLL & your schematic wrapped inside. SM started to write new files on the HD from the VST for OSC wavetables. No, I don't think SM/FS does the most optimized way of doing things; they aim for allways working at the expense of optimization.

[VPDannyMan]

Wait..
I want to be clear.. are you guys saying this is what happens.?
I load a plug in my daw of choice. That plug then takes the Ruby DLL out and writes it into the roaming folder. My plug then makes calls to the ruby dll file it just created.

I'm sorry guys but that really does not sound right.. you must be playin with me? haha Funny..

[tester]

I don't know ruby, but it makes sense. According to descriptions made by others - FS plugins seem to be made of engine + fsm schematic + other files (like ruby), zipped all toghether. In order to make the ruby work in windows environment - it must be extracted from the "zip" archive so to speak. On the other hand - fsm can be processed on-the-fly, because this part - is a communication (readout) between the engine and fsm schematic only.

[trogluddite]

I load a plug in my daw of choice. That plug then takes the Ruby DLL out and writes it into the roaming folder. My plug then makes calls to the ruby dll file it just created.

I'm sorry guys but that really does not sound right.. you must be playin with me? haha Funny.

It ain't pretty, but I think it is the only sensible way to do it for this kind of modular system.

Apart from DSP Code and Assembly, FlowStone is not a compiler - the triggered and Ruby parts are all interpreted at run-time. Which naturally requires there to be an interpreter running - just as you won't get Java applets working unless you have the Java run-time installed to make the language available to the operating system.

If exports were completely self-contained, that would require a separate instance of the triggered/Ruby interpreters to be run for every open program. To save on system resources, all instances make calls to a shared interpreter - so the interpreter is extracted somewhere safe from where it can be a shared resource.

The only alternative is that end users of our exports would need to have the interpreters permanently installed on their PCs. That might be preferable in purely technical terms - smaller .dll files, faster loading etc. - but for plugins etc. being distributed online, I think it might put people off downloading if they got a "You need to install <all this other stuff> before you can use this plugin!" message the first time they tried to run it.

This will also be why global variables and classes etc. all share the same name-space across all Ruby instances - because they are all running inside the same interpreter. That issue worries me more than the issue of how exports are bundled.
Whatever resources need copying etc. for installation, it's easy enough to give instructions, and you only have to do it right once - but the shared name-space could potentially lead to multiple instances of plugins interacting with each other in strange ways due to clashing class definitions etc.
Much of the power of Ruby comes from being able to create your own classes of objects, but it has to be done with great care - I have seen in other app's with Ruby plugins how bugs can often stem from totally unrelated plugins, by different developers, clashing because they share a class name etc. Without 'sandboxing' individual plugins, the whole system can be brought to its knees by one rogue plugin that re-defines a Kernel method that all the others rely on; for example...

Code: Select all

class Float
def + (other)
return self - other
end

Now every Float add system-wide does a subtraction instead - even if you're not a Ruby programmer, all those handy Bitmap Knobs that you used from the toolbox are all broken!!

[VPDannyMan]

I don't know what to say? and and a little