DSP Robotics Support

That's a nice bit of "cleaning up" - almost nothing there once the on/off switch logic is gone, good work!

may someone enlighten me what the

Code: Select all

input 100,..

thingy is supposed to be. According to the guide book:

Code: Select all

the index refers to the input you want to send the event to

but where is input 100?

great stuff guys

thanks for all your answers, its hard for me to pick up on stuff due to being an aspergers wonder kid but, i am slowly understanding some of this ruby thang

Ive made some completely useless items sofar like txt save, ranged random float/int and trigger splitter modules, oh and the clock!

changed the events slightly to get milliseconds working, don't know if that's right or not!

in the random float int modules how do i get them to start with zero values?

heres the file

no loling!

rlr wrote:but where is input 100?

There is no actual input 100 - but it is exploiting the way that Ruby works when it "talks" to the connectors...

When the green values come in, they have to be turned into a format that Ruby understands - so each value is "translated", the value put into the '@ins' array, and tagged with the input number, so that the 'event' part knows where the value came from.
Ruby doesn't really know or care whether there's a real input there or not - as long as it sees those 'tagged' values, it will fire the 'event' section anyway. So the 'input 100' is just creating an event, totally inside Ruby, that 'looks like' a real input. You can send one of these 'internal messages' to an input that does have a real connection too, if there was ever a need to.
With a bit of Ruby trickery, you can even send input messages to a completely different Ruby primitive, or even one in a different schematic - though those are 'party tricks' rather than good programming practice!

I guess they chose 100, because no-one is ever going to want 101 inputs, so it leaves plenty of room for 'real' inputs if you decided to add more. You might think that would make the @ins array get a bit big - but, as I understand it, in Ruby arrays are implemented more like hashes - there really is nothing there for empty array entries, rather than using up memory storing a 'default' value like the 'green' ones.
(You wait, someone will go for a 101 input Ruby now that it's been mentioned! )

Jay wrote:Ive made some completely useless items

Phew, thanks for sparing us, and only posting the nice examples of some important Ruby fundamentals!
And the rand thing is cool, i didn't know it understood ranges like that - very useful.
No big howlers as far as I can see. One tip - triggers don't send or receive a value, so storing a value in the trigger example isn't needed. You can emulate a green 'pure trigger' in Ruby with the special value 'nil' - 'nil' represents literally nothing, and in Ruby is a very distinct concept from 'false' or 'zero'. But I think pretty much any value is fine, as it will be safely ignored anyway if the output is set to be triggers.

Jay wrote:In the random float int modules how do i get them to start with zero values?

You can make a startup routine by writing a method called "init". That method name is recognised by FS, and will always be run first when the module starts up (or you edit any code). So you can set start values of variables there, and all the FS "purple" Ruby commands work too, so you can zero your outputs.

Code: Select all

def init    # NB) init should not take any arguments
output 0,0
end

And if you ever need to do a manual 'reset', just put 'init' in your code, and you can call it yourself.

The only thing to watch is that at load-time, Ruby starts before 'green' does, so input values will always be whatever got saved to HDD inside your schematic, because there are no 'green' values yet for 'init' to read - not a big problem, but something to watch if you are relying on green prim's to get values for things like sample-rate, as 'init' will miss any changes.

Easy init !?.

(Oh, I hang my head in shame, i really can't believe my humour has stooped so low )

ah thanks for the reply and the tips Troggie

im really getting into this, im going to try replace the old string search and replace module from the SM forum next,

i may never be as good at ruby as some of you guys but, i reckon in my case it will be great for replacing a lot of the old multi component based modules we have all used and loved in the past and reducing them down to one item!

LovingIt.com

Best Regards

Sounds like we could do with some sort of Toolbox thread - start collecting some of these useful little modules together.

From what I can tell, it's well worth taking the time to convert things too - Ruby seems pretty fast compared to green from what I can tell - especially for anything using loops or arrays etc.
The number of different methods you can use on arrays is simply staggering - sorting, filtering, re-ordering,slicing up - you name it. And because many of those things only need a single method call, they run mostly as super speedy compiled C code with the parser/interpreter barely involved.

Only problem I've got now, is that I started off too many projects over the Xmas holidays - I need another month off work now to get some of these babies finished off!