"Green" midi keyboard - best solution so far

Post any examples or modules that you want to share here
User avatar
kortezzzz
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

"Green" midi keyboard - best solution so far

Post 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 :)
Attachments
( green keyboard_30_6_18).fsm
(41.64 KiB) Downloaded 1215 times
User avatar
Spogg
Posts: 3368
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England
Contact:

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

Post 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
User avatar
kortezzzz
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

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

Post 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.
tulamide
Posts: 2714
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

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

Post 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?
"There lies the dog buried" (German saying translated literally)
User avatar
kortezzzz
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

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

Post 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:
keyjslider1
Posts: 20
Joined: Tue Mar 13, 2018 2:19 pm

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

Post 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.
User avatar
nix
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

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

Post 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
User avatar
nix
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

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

Post by nix »

my inference is that Ruby drawing might be the problem, not Ruby MIDI per se-
in NB kb
User avatar
kortezzzz
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

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

Post 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).
User avatar
nix
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

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

Post 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
Post Reply