Manipulating midi with ruby, internally.

[kortezzzz]

On my previous post, I was after a solution that would block stuck notes when switching between 2 midi sequences. As suggested by kg, I'v tried to kill the switched midi sequence's notes at the time it switches, but still ended up with few stuck notes, pops and clicks. But then, I relized that a possible key to solution is lying in my tool box: A While a go, a forum member (sorry, dont remember his name..) suggested a great module that uses "case" order in ruby abd outputs values according to the incoming midi velocity parameters.
Which means that ruby may maybe manipulate midi parameters internally? So here is an idea that may help many other too: a ruby module with 1 midi in, 2float ins and one midi out.. When float input =30, the midi pitch will never be lower than 30 but will output a value that is greater than 30 in 12 notes, from the upper octave ( key 42). Is that possible?

[RJHollins]

Don't know if it was me ... but I had to use CASE statements sending specific MIDI values [0-127] from a range of knob value [0-1] to an exact MIDI value.

Even with 128 CASE conditions, there was no lag issue ... worked great for me.

[kortezzzz]

Yes, it works great
But now its a different story. In your case, you extracted a single value (velocity) from the midi event, and its a good sign, as it proves that ruby messes away better with midi content internally than green does. In my case, i need ruby to output the full midi event+manipulation from it's midi output.
For instance, if the incoming midi event contains "status=128, channel=1, data1=30, data2= 100", the output would be "status=128, channel=1,data1=42, data2=100".
Which means a full midi event inputing/outputing instead of just extracting int. values. The question is if it possible and if it does, what are the advantages of ruby compared to the clumsy green process.

[RJHollins]

hmm ... actually, I ended up using both RUBY and GREEN ... just seemed like a good idea at the time

The RUBY part was taking a range of knob values, and through CASE, would output a single MIDI DATA2 value.
From there I went GREEN ... to assign STATUS & Channel values. That combo all got sent to MIDIOUT.

It would probably be quite simple to have kept [my needs] all within RUBY.

The ONLY thing that I got caught on was not having a DEF EVENT at the start of RUBY to monitor INPUT values from the KNOB [something like that, would need to go back and look].

Although I'm not fully understanding your need ... from what I read from you, this should be easy for you. So there must be much more I'm not aware of.

I'll hide in the background and follow this thread hoping to glean some knowledge

Someday I hope I can return a token of help to anyone ... after all the help I've received here ... someday

[RJHollins]

re-reading your post ...

Which means a full midi event inputing/outputing instead of just extracting int. values. The question is if it possible and if it does, what are the advantages of ruby compared to the clumsy green process.

I would say that it is possible to do this all RUBY. I think that GREEN can get clumsy as you say. [it definately has its place]. I don't know if there is any speed differences between the 2 designs ... however, with RUBY, you can construct a 'logic' and control that can get messy with GREEN.

again ... me watch to learn.

[kortezzzz]

The RUBY part was taking a range of knob values, and through CASE, would output a single MIDI DATA2 value.
From there I went GREEN ... to assign STATUS & Channel values. That combo all got sent to MIDIOUT.

mmm... just an Of topic thought that came to my mind when read this line: What would happen if we try to seed ruby
midi learn system instead of the green one? Would it solve the CPU spikes that occur with the green?

Although I'm not fully understanding your need ... from what I read from you, this should be easy for you. So there must be much more I'm not aware of.

Well, yes, there is much more . This internal midi processing should help me saving some CPU and make things smoother and a way reliable, since the project it self is already manipulating a lot of midi data simultaneously.
Unfortunately,The ease of implementing it depends on my (very poor) coding skills in ruby, so no doubt I'll need a help from the guys here.

after all the help I've received here ... someday

Yeh, I feel just the same as you. At the time, I can't really contribute to the knowledge of the community, but ended up with a decision to "kick" the start of 64bit upgrade project by my self, if my project becomes a great seller

I think that GREEN can get clumsy as you say. [it definately has its place]. I don't know if there is any speed differences between the 2 designs ... however, with RUBY, you can construct a 'logic' and control that can get messy with GREEN

I can say with no doubt that there is a difference between the 2 designs; Ruby may encapsulate tons of green prim.s
and wires into few lines with a way better reliability, minimum bugs and lugs (after compiling) and excellent durability to problems that may occur with extra fast midi manipulations by the end user. Can't tell much more about my project right now, but thanks god ruby is in the picture

[kortezzzz]

Finally, here is it. The ultimate midi manipulation module. It contains 1 midi input and 2 float inputs that
function as threshold points. With this module, you may determine the lowest and the highest notes that
allowed to play. Every time the user goes lower than the low threshold point, the module adds +12 to the
key value. Same with high notes: every time the highest threshold point is passed, the module adds -12
to the key value.

Would like to thank Nubeat7 for developing this great module. Have we already noted that a new generation
of Gurus is rising here?...