Any use for this?

[MyCo]

Hi,

I've been playing around with ruby, and found a cool new (hidden) feature

[trogluddite]

...but not as well hidden as the purple highlighted keyword "caption", maybe?.

Here's one for you...

Code: Select all

primitive_name = caption.gsub(" ","_")  #remove whitespace
eval ("@@#{primitive_name}=self")  # builds a class variable with that name pointing at this Ruby instance

Because class variable are visible in all Ruby windows, you can now go into a completely different Ruby primitive and type this...
@@name.output 0,"Hello"
...and this output will appear on the output of the first Ruby block.
Of course, this kind of monkeying with the name space could get out of hand and confusing very easily - but I think there are some very interesting tricks to be learned.

[MyCo]

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

[trogluddite]

By writing to inputs you can even send triggered events....
@@Over_there.input 0,value - send the value to another module's input as if a link were there - though you don't get auto-summing, so multiple inputs through the Ruby ether will fight.
The only fly in the ointment is that the order that Rubies get parsed at start-up is confusing - if modules don't get parsed in the order you expect, you can easily make calls to methods that haven't been created yet. I think the rules for it are nor so complex, but hard to keep track of if you're in the middle of a hot cutting and pasting session.

[MyCo]

What, I don't like is: The inputs/outputs are not updated, when you disconnect them. They keep their value for ever. Even copy & paste of the ruby module or changing the connector type, doesn't update the value.

[trogluddite]

Hmm, can't quite work out if that is a 'feature' or not either - after so long using green, it seems does strange the inputs not polling when you read them.
Maybe interfacing different Ruby and Green threads made it tricky. That kind of persistence is all around in Ruby though - if you type out a big Class with lots of juicy methods - and then CTRL-A, DEL - all of those definitions are still active for the rest of the session. Everything you type gets interpreted, including the typo's that you rub out!
Mostly really enjoying it though - it really is very nice to be able to get some decent data structures together, the old one-dimensional green arrays just weren't really up to the job for big filtering and sorting jobs.
Should make a lot of ball-scratching about triggers a thing of the past too. I really like the way that you can define your own trigger behaviour for each and every input, that and the clear program flow make it much easier to keep track of what's going on.

[Tronic]

You can inspect all Method, Costants and Class loaded in ruby instance with this.

[MyCo]

what is 'libimprov-2.2.7' ?

actually I used x.class.instance_methods(false) to inspect. And found "parent" and "caption"...

[trogluddite]

Rather close to Xmas to be finding so many easter eggs!
Here another I just found...
The MIDI object type has attribute accessors for status,channel,data1,data2,sysex. So you can write stuff like...

Code: Select all

@myMIDI = Midi.new(176,2,10,150)
@myMIDI.channel = 5
ccNumber = @myMIDI.data1 if myMIDI.status = 176

Many of the FS classes also seem to have the Marshal class methods _dump and _load defined - so it should also be quite easy to store pretty much any object or collection of objects to file.

[Tronic]

what is 'libimprov-2.2.7' ?

sorry my experiment to integrate other library
i have uploaded the correct file now.

I'm trying to create a wrapper for the midi,
because there is not yet a full implementation of all the messages,
and I regret to to know that is not a priority for developers
but until the support does not tell us how to run the callback with the current Win32API,
I do not think it is possible to do something shared with other users.