DSP Robotics Support

BTW this keyboard is quite ancient on that timeline

You are right. but this keyboard is most wanted as it gives that x-factor value of graphical respond to coming midi notes. why is it good? because its aimed to the "bells and whistles" fan-boys (and there are lot of them!) and it helps to sell, as it gives that people the fill of playing a real instrument.

the principal of this keyboard is great. we just have bring it to it's optimal condition.
here is a version that fixes most of it's problems, except the CPU usage on note releases (and its come significant when you play 7-8 notes together in lets say, jazz session). If anybody has an idea how to reduce CPU to minimum,
I think we have a the winner keyboard here

yes its better when playing with midi keyboard, but the keyboard has no graphical reaction when played with mouse

i also did some fix on it, midi from outside is translated to green by ruby now and happens directly in the "midi note/ext note" module inside the "note on/off" modules which fixes the cpu propblem

i also included an keyboard octave shift selector, so when you just want to show 4 octaves or less you can shift oktaves up and down so that you can play all 128 notes

yes its better when playing with midi keyboard, but the keyboard has no graphical reaction when played with mouse

yeah, stupid me, i forgot to connect the keyboard's midi output to the midi split's input...

Well done, nubeat. i'll test it as i come home. i don't like ruby stuff as i still don't trust it. power is always welcome, but not at the cost of stability. i prefer using Ruby only when there is no other choice.
Hope it works...

for me its still a mythos that ruby is bad for stability, but if you find a better solution in green, it is welcome

the only thing which is done in ruby is to get triggers from midi directly from the ruby module, its a clean and fast solution to get note on/ off triggers out of the midi signal and it also should be more accurate

but its no problem to do the same in green you can test and compare if you like, basicly all i did was to get the external note on/off triggers directly inside of each key module instead of getting them at the midi input on the upper level, like this green triggers get only generated where they should and not sent over the whole schematic and get blocked at the individual keys

LoL - can't believe this old beast is still drawing attention all these years later...



The M-Audio fix is redundant in most of these as the incoming notes module takes care of that.

The disappearing keys seems to be related to the octave ID passing... each octave adds one to the incoming ocatave id and passes that to the next... For some reason it's failing a lot. You can fix bydisconnecting the pass and just manually number each but it's less elegant for adding octaves or changing the starting octave.

I used to find that if the module was selected in the program it would slow down a lot for mouse control but I don't see that from the posted version. Could be my newer computer has 100 times the processing.

As for displaying chords... you might never get it to really be capable but I'd start by looking if you can limit screen redraw somehow.

I'm not sure where the velocity zones come from... I don't think it was my addition although I do recall starting to add the feature after someone else made one with a very slow response. It should be that hard to figure out but it might be easier to add from scratch that figure out from that one.

Let me know if there's anything I can help with. I was up to a version 10 before I gave up on it and I have no idea which version you guys are starting from but it looks like it was pretty much from the final tries. (I deleted all my files from SM server after getting pissed with OutSim but I guess these are so old they're still on my shaw.ca pages from the days where you had to host your own images and schematics.)

oddson wrote:... I'd start by looking if you can limit screen redraw somehow

Yeah... looking under the hood I see each note redraws it's area separately.

Maybe it could switch to a global redraw when there are incoming MIDI notes... maybe even calculate the redraw area from the min and max notes so to only redraw the area being played??

But at some point you hit diminishing returns and becomes time to learn how to do the same in Ruby.

hello oddson, thanks for linking in and explaining the disappearing issue, not sure if the ruby stuff fixed this too? i never could found the disappearing bug when testing it..

this is a great keyboard, which is also very flexible in gui modifikations, which i love it for.

one thing i fucked up with my mod is the latch mode with right mousebutton which doesnt work as it should be after i disconnected the mouse up with the note off trigger to avoid double triggers, i was working on it at my work today a bit but couldn`t get it fixed...

sadly my time to work with FS is very limited atm..

oddson wrote:Maybe it could switch to a global redraw when there are incoming MIDI notes... maybe even calculate the redraw area from the min and max notes so to only redraw the area being played??

but any way each key area gets redrawn with its own note on boolean so all key areas are only triggered when played changes i think this is the best solution or?

Hi oddson
Thanks for the explanations and for this (old but great) module. I tested your suggestions and so far, found out:

1)nubeat's Ruby-midi fix works o.k. . no audio slowdowns with coming notes, but there are still audio slow-downds
when lots of keys get released in very short time (when playing both hands with my hardware midi keyboard).
2)the gui disappears after 10-15 minutes of intense playing in some cases (don't even know in what cases... it's an enigma... )
3) I was thinking about separating the midi module from the graphics module by making two keyboard modules that run Simultaneous (the one for midi notes would be transparent, the second will only show graphics) because i suspect one of this 2 processes (midi or graphics) is slower than the other and therefore, "harm" the whole process.
my separated module works fine (using nubeat's ruby-midi module), but with few issues:
a) some pop and clicks occur when playing both hands
b) when using midi learn feature for any cc knob, the keyboard go crazy sometimes. tried to limit the midi data access to the keyboard module by filtering and passing only "status" massages (144,128) but then the graphics part slowdowns as hell and actually is out of order

so, for now, i give up for the "graphical incoming midi notes indicator". i won't show up the any played midi
note in my synth, but only the ones which played by the keyboard it self (so it will have no active midi in, just "gui notes" and "midi out").

anyway, thanks for that great gift, oddson. maybe one day we i'll find a stable solution (like savihost's built-in keyboard)

Kortezzz

why not just use one of the working gui keyboards that are out there? does this one work for you? ive never had any probs with this one

i still dont get why people insist that they need to see the notes they are playing on screen! you already know what notes are being played because YOU are playing them lol