Re: [Denemo-devel] Midi-status

[Nils Gey]

First report on midi. I just write what I noticed. I am sure you probably know 
most of these already. 

I compiled Denemo with --enable-jack. Latest git.

Then I start my jackd, after that Denemo.
Denemo shows up as input and output client. The output has voice 1, which is 
the first staff.

Creating new staffs, with a custom name "test", shows a new port in QJackCtls 
[+]Denemo

Renaming of the staff has no effect. It stays the the old one for jack.

With these two staffs, "voice1" and "test", deleting the first one results in 
the deletion of the qjackctl port and leaves only "test", which is fine. 
Creating a new staff (create new staff above) does not create a new jack-port.

Creating a new staff with an existing name ("voice1") does create the staff but 
not a new jack-port.

I loaded an existing .denemo file with four voices and they show up correctly 
as four ports.

Quitting Denemo leaves no traces. Everything is fine.

Now to midi-in:
For the midi-in testing I used the software jack-keyboard to avoid any hardware 
and/or alsa-bridge related errors. 

I remember I got it working once, a few weeks ago, but today there was no 
success at all:

Like I said Denemo creates an in-port "denemo" on startup. If you connect 
jack-keyboard to it and send notes nothing happens in Denemo. I know this is an 
expected behaviour, but in fact this is not the right behaviour and confusing. 
If there is already a midi-in port I (as an uninformed user) don't see why its 
not possible. See the suggestions below for that.

So I choose Input->midi input from the menu. The dialog pops up (which is sooo 
ugly with my WMII window manager because its stretched over the whole screen).
In QJackCtl I now see a second in-port named denemo-01. I am sure this is a 
known bug. 
If I connect to the new "denemo-01" it automatically switches to the first 
"denemo" port. So connecting to denemo-01 is not possible at all. 

Now comes the freaking part. To avoid confusion: I am some 80% sure this is 
related to my system and not to Denemo. I encountered something like this 
already with the Video-Lan-Player but I don't know what it is right now.

Status: Midi-in is now activated, I see two denemo-in ports in jack and have 
connected the jack-keyboard to the "denemo" in-port (btw. same results with my 
hardware-keyboard via alsa-bridge).

If I send a note now my systems totally freaks out and my hardware(!) makes 
constant freaking noises which changes if I send another midi-note. It sounds a 
bit like a dial-up modem and it sounds very very unhealthy.
To be clear: I don't mean my audio-hardware! And its not the pc-speaker. It 
sounds like scratching or somethings going wild. Maybe harddrive, maybe some 
fan... I don't know. 

The source of this is Denemo. The sounds are going on until I close Denemo. 
Cutting jack-connections, stopping jack or other software has now effect.

Like I said I believe this is only my system, but there is some error 
nontheless. Other software works fine with midi-in/out and routing. 


Suggestions:

1) Make --enable-jack default on. Give a warning to the console if jackd is not 
started, but let Denemo run. Its a common thing to restart the client(Denemo) 
if you want to have jack in the end. I never saw a "reconnect on the fly" 
function in any Jack-app that works flawless (like starting the software anew)

2) Prevent staffs with the same name at all. Every staff, which means 
"jack-port" here, should have a unique name. This should have nothing todo with 
lilypond staff names. The printout-names should be allowed to be different from 
the internal/jack-name and should be allowed to be non-unique.

3) The midi-in behaviour is not optimal. I expect sending midi-notes to Denemo 
as a standard task. So I suggest to get rid of the midi-in dialog (enharmonic 
range etc.) as a popup and leave it as a preferences tab.
In case of enharmonic and key-related behaviour it would be better to look at 
the actuall staff-keysigns.

4) Also I suggest to open the Midi-in port right from the start. Maybe use lash 
indepently from a lash-project (don't know if thats possible) to remember the 
last midi-in connection and try to recreate it. Of it was the midi-keyboard its 
likely that its still there. Then you can do an autoconnect, instructed by 
Denemo.

5) This creates a situation where Denemo constantly listens to midi-in, which 
is a good solution in my eyes. To prevent accidental use of the midi-in feature 
(like putting a dish or some heavy notation on the keyboard, which is a real 
live situation) I suggest a switch in Denemo which reroutes all midi-in signals 
to /dev/null, but which does not cut any connections. Its just a bypass.


So far...

Nils