Page 1 of 2

"Green" midi keyboard - best solution so far

Posted: Sat Jun 30, 2018 6:01 pm
by kortezzzz
As discussed on Adam's post on facebook, I noticed that the Ruby based virtual keyboard acts just the same when triggered by outcoming midi signal and creates hard CPU spikes on some DAWs. So I made a decision to abandon that method until this bug will be fixed and go back to the green method, but this time, image based. The attached keyboroard works perfectely. It's actually combines 2 keyboards. The first is for midi triggering and the second is for the visual feedback. Hope you'll like it, and wish that the gurus will help me to add in it a "mouse dragging" feature (which allows playing the keyboard with dragging the mouse, without the need to use Ldown every time).

Thanks :)

Re: "Green" midi keyboard - best solution so far

Posted: Sun Jul 01, 2018 8:33 am
by Spogg
I love it!

With ASIO I found it very fast and responsive, no noticable lag and the display of incoming MIDI (from my USB keyboard) worked well.

My only concern is how it would perform in a complete synth with green-based readouts etc happening.

Thanks for sharing this.

Cheers

Spogg

Re: "Green" midi keyboard - best solution so far

Posted: Sun Jul 01, 2018 11:09 am
by kortezzzz
Thanks for the feedback, Spogg :)

Tested it with my (heavy) old synth line and it works great. Nevertheless, I would love to read some more feedbacks from the gang.

Re: "Green" midi keyboard - best solution so far

Posted: Sun Jul 01, 2018 4:02 pm
by tulamide
I understand why you seperated the individual keys for mouse events. However, that is exactly why you can't implement mouse dragging. For that you'd need to enable the complete top view area for mouse events and transform the mouse position to "key over" events. The individual keys would get an input boolean indicating if the mouse is currently over or not, and react accordingly (start or continue playing, stop playing)

I thought the issue with Ruby was that midi produces peaks. So why did you exclude it for drawing purposes as well?

Re: "Green" midi keyboard - best solution so far

Posted: Sun Jul 01, 2018 11:46 pm
by kortezzzz
Thanks for comment, tula :)

tulamide wrote:I thought the issue with Ruby was that midi produces peaks. So why did you exclude it for drawing purposes as well?


That's very interesting point; drawing the notes system with ruby, implementing the midi system with green? Well, if you meant to say that, you probably know what you are talking about, but its far beyond my coding skills anyway. Besides, how can we avoid of adding a midi input in the ruby code and still get a visual feedback from the incoming midi signal?... :roll:

Re: "Green" midi keyboard - best solution so far

Posted: Wed Jul 11, 2018 4:17 pm
by keyjslider1
kortezzzz wrote: Besides, how can we avoid of adding a midi input in the ruby code and still get a visual feedback from the incoming midi signal?... :roll:


I guess, there is no way of avoiding that, but this shouldn't cause any problems. Probably I'll try of implementing that in a couple of weeks or so, cause I'm not confident for Ruby graphics programming.

Re: "Green" midi keyboard - best solution so far

Posted: Mon Jul 16, 2018 2:17 am
by nix
I may be experiencing this issue at low latency(16 or 32) with the NuBeat keyboard
I have 3 synth builds, and the one with the keyboard was the only one to underrun perceptibly-
I took it away and no more underrun-
will look at this schem now,
thanks for it Kortezzz, that's very nice of you

Re: "Green" midi keyboard - best solution so far

Posted: Mon Jul 16, 2018 3:06 am
by nix
my inference is that Ruby drawing might be the problem, not Ruby MIDI per se-
in NB kb

Re: "Green" midi keyboard - best solution so far

Posted: Mon Jul 16, 2018 3:59 pm
by kortezzzz
keyjslider1 wrote:
kortezzzz wrote: Besides, how can we avoid of adding a midi input in the ruby code and still get a visual feedback from the incoming midi signal?... :roll:


I guess, there is no way of avoiding that, but this shouldn't cause any problems. Probably I'll try of implementing that in a couple of weeks or so, cause I'm not confident for Ruby graphics programming.


Heya, keyjslider. Thanks for trying :)
But I don't think there is a way to extract midi signal from the Ruby drawn keys without adding to the Ruby code a midi output as well. and Nubeat allready did it...

nix wrote:my inference is that Ruby drawing might be the problem, not Ruby MIDI per se-
in NB kb


Heya nix,
Thanks for the feedback :)
I think you are right. Therefore, My best guess is thatIf we want the dragging feature to work with no spikes, we better stay with green, but the challenge then would be drawing the keys in one top GUI group (withput separating them into individual GUI components, as I did).

Re: "Green" midi keyboard - best solution so far

Posted: Mon Jul 16, 2018 5:25 pm
by nix
hmm, I tried this years ago- hah, it was so awkward
Here's the file I found for the precursor to that one->
keyboard_highlight_0.fsm
(47.79 KiB) Downloaded 1173 times

It doesn't help solve the problems, but maybe you'd like a look