Ruby MIDI switch/glitch oddity

[tulamide]

I needed to take this day off, but I can't let this be uncommented. So, just a quick bit:

No higher language will force a time limit on you. That would be counter-productive. You might use an iteration to just add numbers. I might use an iteration to calculate the amount of stars in any given universe. How should I get to my goal if I had only 10ms per step?

Instead, as described in the user manual, Ruby is event-driven. Whenever an event occurs, it is put on the event queue. As long as it isn't empty, the events are worked on one by one. This means, the accuracy of Ruby is at around 10ms, but there's no upper limit for executing events (well, there is, but that is introduced by Flowstone, which will interrupt if Ruby takes too long. Too long is defined by a time factor in the range of some 10 or 20 seconds or so)

Never, I repeat, never use a for-loop in Ruby. Ruby is object-oriented, and therefore it has a module called enumerable. Every other class that implements the enumerable module, is able to iterate. For example, the array class implements the enumerable module.

You iterate through an array with one of the many methods of the enumerable module and a block.

Code: Select all

myarray = ['apple', 'banana', 'peach', 'strawberry']
len = 0
myarray.each { |n| len += n.length } #'n' can be any name you like, it represents each object in the array
watch len #total count of characters in this array

For longer code, use the second form of a block, which is 'do' 'end'

Code: Select all

#'n' = object in array, 'i' = index of the object
myarray.each.with_index do |n, i|
  ... #code
  ... #code
  ... #code etc.
end

Here's more about the enumerable module. Everything is documented there, including every existing method.
Enumerable module on ruby-doc.org

[HughBanton]

I needed to take this day off, but I can't let this be uncommented.

Never a problem .. we're so grateful for your insight at any time!

Never, I repeat, never use a for-loop in Ruby.

Ooops Big oops.

I'm going to study all of this without delay. Thanks again.

Hugh

[HughBanton]

I have studied

Success I think, I realised my MIDI Switch needed a hash rather than an array - I've definitely learnt something good today.

It's the most satisfying thing when you reduce some code by 50%, AND speed it up by x72, AND it still works!
Thanks again for the tips tula. (Hope I've got it roughly correct, Sir )
H

[RJHollins]

working well here Hugh.

Nice !

[Spogg]

Never, I repeat, never use a for-loop in Ruby.

Just to clarify stuff:

I wanted to see if the 100 Hz applied to a whole RubyEdit for all the code. I quickly found that it didn’t.
Then I made a while loop just to get a feel for how fast the code interpreter could run on my PC. Of course the loop execution used a lot of CPU so, as tulamide said, I wouldn’t even try to use it in Flowstone for a real application. It was just an experiment, but it demonstrated to me just how bloody fast the interpreter can run.

And thanks for again taking time to teach me (us!) tulamide.

Cheers

Spogg

[tulamide]

I have studied

Success I think, I realised my MIDI Switch needed a hash rather than an array - I've definitely learnt something good today.

It's the most satisfying thing when you reduce some code by 50%, AND speed it up by x72, AND it still works!
Thanks again for the tips tula. (Hope I've got it roughly correct, Sir )
H

You have studied indeed! I'm surprised how quickly you could adapt it to your needs. The code doesn't look pretty (whitespace!), but its functionality is top. I couldn't see a spot for optimization in terms of execution speed. Well done!

Spogg, I hope you didn't feel attacked! I was just trying to be serious about it, and better now than later, when such a thought is already deeply routed in the brain.

[Spogg]

Spogg, I hope you didn't feel attacked! I was just trying to be serious about it, and better now than later, when such a thought is already deeply routed in the brain.

Not at all mate. I thought I should say what I was trying to do in case others were interested. I particualarly wanted to avoid the situation where someone thinks "Well, that handsome Spogg guy can do it even though tulamide says you shouldn't"

Cheers

Spogg

[HughBanton]

I think Spogg & I are both just trying to get a handle on FS Ruby's speed.

Everyone here's familiar with what green does best, and how fast stream & dsp coponents can compute. I've had some success with writing C in dlls (I won't claim c++!) which appear ro crunch through numbers at mind-blowing speed whenever triggered. (Brilliant once you get them settled )

Somehow Ruby's performance doesn't seem so clear, not quite sure where it sits on the FS rev counter.

Hugh

[tulamide]

Somehow Ruby's performance doesn't seem so clear, not quite sure where it sits on the FS rev counter.

Ah, I see! Ruby being an interpreted language is of course slower than C. But it is created with C and crucial parts of it are executed as compiled C-Code, so it is as fast as an interpreted language can be (it might be that Python is a tad bit faster, because it doesn't act as strict on the object-concept).
Within Flowstone however, it is always a slave thread, because audio performance always comes first here. Everything is tailored to offer a by-sample-operation, which means that everything else has to wait in critical situations. That's why trog, who was one of the first to check out the then new Ruby implementation came to the conclusion that Ruby and green are pretty much on par.
I would extend that statement, saying that it is slightly faster as long as it doesn't need to communicate with green. For example, data tranfer via Ruby-value-connection is a myriad of times faster as a transfer via green connections. And it is more reliable than green, for example when dealing with midi streams (because of the more precise timing). If I had to list them in order, fastest on top, it would be

Assembler
DSP
Midi/Ruby
Green

But that doesn't cover aspects like accessibility, comfort, expandability and maintainability. If we factor in those, the list would be led by Ruby.

p.s. Since you have experineces in C, here's something you might want to consider: In your code you "buffer" the results of methods in variables. This is what we all learn early on in languages that are not object oriented. Save time by only executing a function once, then access the spot in memory instead, where the variable points to. However, in Ruby everything is an object. In your code it works as you'd expect, because numbers are singleton classes. That means, the number 1 is an object, but only ever exists one time in memory. When you assign a class, that is not singleton to a variable, you don't make a copy. You just have another pointer to the same class instance. So, in case you try to build code where you need a copy, you have to run .dup or .clone (read about the difference between them on Ruby-doc) explicitly!

Code: Select all

a = Someclass.new
b = a
# a and b point to the same instance, changes to b are reflected in a and vice-versa

a = Someclass.new
b = a.dup
# a and b are seperate class instances with the same status quo. changes to b don't influence a and vice-versa

[HughBanton]

I couldn't see a spot for optimization in terms of execution speed.

I can!

Code: Select all

      if v.status == 144 then @midiNotes[noteNo] = velocity end # ON
      if v.status == 128 then @midiNotes[noteNo] = 0 end # OFF
      if (v.status == 144) && (velocity == 0) then @midiNotes[noteNo] = 0 end # zero vel = OFF
   @midiNotes.delete_if{|key,value| value==0 } # delete off notes

Seems to me that the 3rd. line is superfluous - the hash entry it creates is immediately deleted again on the 4th line, doh.
Also the MIDI 'Note-on with zero velocity = Note-off' scenario that it's intended to catch is now already effectively taken care of in the 1st line anyway. A left-over from my earlier 'array' version.

At least I think this is all true ... err

H