Any use for this?

[trogluddite]

but with global variables you could do this the other way around, too (polling a global variable and then change the output)

...and with a global Module, you get this...

Wreless Class 001.fsm

(5.95 KiB) Downloaded 1412 times

Kind of a virtual wireless patchbay for Ruby modules, including the ability for updating a parameter to pass the value and trigger multiple inputs or outputs anywhere in the schematic. The storage of the links values inside the module means that it should be possible to save the link data to HDD and restore it again.
Experimental still, and not one you'd use every day, I think - normal connections would be more efficient than a load of method calls - but maybe useful for a big 'global preferences network".

Oh, and another thing to ponder...
Remember the warning in the manual about the shared namespace if you have multiple schematics open?
Well, it is the same for exported plugins too - only one instance of Ruby is opened for all running FS3 VSTs.
Good or Bad? Hmmm.
Lots of chances for weird bugs once we all start using Ruby in our plugins. Ruby seems pretty good at dealing with variable scopes etc. - but it will still take some effort from programmers to avoid namespace clashes, and to resist the temptation to take shortcuts by re-defining methods that everyone else relies on.
OTOH - you can send values between plugins. I haven't tested extensively to look at timing yet, so maybe only good for preferences etc., but the values definitely get back and forth - even Modules and Classes defined in one plugin are available in the others.

[Tronic]

Trog have also investigated?
Modules and Classes have been declared as private, still present in other instance?

[trogluddite]

Trog have also investigated?
Modules and Classes have been declared as private, still present in other instance?

I'm looking into this now - before I go any further with making new classes etc., I want to get clear in my minds how all that stuff works. Because I'm new to object programming, concepts like private, protected, singleton this-and-that, are all a bit alien to me.
For sure, each Ruby prim is an individual instance - so temp variables and @instance variables will always stay completely within their own block It's only when you start introducing new classes and modules that there is any problem, so for most day-to-day stuff, where Ruby is just treated as a "green" substitute, I don't think people will run into problems.
But a way to reliably include new classes in the schematic (or 'require' them reliably at startup) opens up too many exciting possibilities to ignore - so I will carry on investigating. I've just starting making my own Ruby plugins for the SketchUp 3D software too - and that has been really helpful, as there is a whole community there that have had lots of experience with exactly the same kind of issues. There are some plugins for that software that are very powerful, yet are best avoided because they re-define methods in ways which affect other installed plugins - but the guys there have found some good programming practices that they use to avoid the pitfalls. When I've had a chance for their wisdom to sink in a little bit, I'll post up some of their recommendations.

Here's a link to the SketchUcation forum's Ruby resources page - not all of it useful to us, as some references are specific to the SketchUp API, but there is plenty of good advice to read if you sift through the Developers forum a little bit.

[rlr]

When inspecting the ObjectSpace as suggested by tronic to my surprise I found that IO, Dir and File are available!

This works:

Code: Select all

@f=File.new("c:/tmp/xx.txt", "w+")
@f.write ("hello world");
@f.close

even binary:

Code: Select all

@binary_file="C:/Program Files (x86)/DSPRobotics/FlowStone/msvcr90-ruby191.dll"

@fb = File.open(@binary_file, 'rb')
@buf = @fb.read()
@fb.close
output @buf.unpack("C*")


There are some more:
- Fiber seems to work
- Thread doesn't (error: excessive processing detected), or I'm doing it wrong.



Now: how to get a HWND Windows handle out of the View object?

[trogluddite]

I would expect threads to be a trickyy one - FS will need to rely on Ruby running on a particular thread in order to interface with the inputs/outputs to the rest of the system (in Ruby 1.9.x they are genuine CPU threads, as opposed to Ruby 1.8.x where they were 'simulated' threads). As soon as Ruby is running a task on a different thread, FS loses track of it, and the 'protection' assumes an error - as seen by DWB in his experiments.
Indeed, there have been bugs (fixed) in the past in SM due to MIDI and green not sharing the same thread, and some obscure green-stream timing issues are caused by the same thing.

The other classes you mentioned are indeed part of the Ruby core. You can see the full listing on the official API docs site (an essential bookmark! - it is VERY useful). You can see at the top the tabs for 'Core' (all present in FS3 AFAIK) and 'Std Libs' (the libraries, of which we only have win32api' as standard).

Re; HWND. All FS3 views will share the same HWND, as they are just 2D graphics all drawn within the same window - no idea how you'd do it in Ruby, but you'd only be able to get a single HWND for the plugin or .exe window as a whole.