Re: [Lmuse-developer] aftertouch and channel pressure

[Tim E. R. <ter...@ro...>]

On October 21, 2012 02:52:43 PM Robert Jonsson wrote:

> Hey guys,
> 
> 
> Sort of fell off internet again.. main reason being kitchen renovations. 
Haven't read all mails yet so not sure if there's anything I should respond 
to. I'll get there.
> 
> 
> Anyway, there were some new forum messages I've tried answering but soon got 
stumped by a aftertouch question.
> As this isn't really my area I tried learning by doing... setting up MusE to 
record and edit aftertouch, seems though my keyboard doesn't send aftertouch 
but Channel pressure, 0xd0 so I tried with that instead.
> If I start muse with -m I can see muse registering that pressure messages 
has been received but I can't seem to find them in the pianoroll controller 
view.
> The playback device I currently tried does not support pressure so I can't 
hear if they are recorded. Looked at the songfile but couldn't find anything 
that seems to correspond to the pressure messages.
> 
> 
> I think this is mostly directed at Tim, is there anything specific needed 
before the messages show up?
> 
> 
> Regards,
> Robert
> 
> 


OK Listen up! 
Before answering I need some input here:

My keyboard is also old and can receive, but not generate, channel and
 key pressure.

So while I always respect pressure coding while I'm in there, I've never 
 really expanded upon it or fixed many bugs with it.

Here's what I found, and have done locally:

First, our Jack Midi driver doesn't take key pressure input, so I 
 quickly fixed it:

MidiJackDevice::eventReceived()
{
	...
      switch(type) {
            case ME_NOTEON:
            case ME_NOTEOFF:
            case ME_CONTROLLER:
            case ME_POLYAFTER:				<<<--- ADDED THIS
                  event.setA(*(ev->buffer + 1));
                  event.setB(*(ev->buffer + 2));
                  break;
            case ME_PROGRAM:
            case ME_AFTERTOUCH:
                  event.setA(*(ev->buffer + 1));
                  break;
	...
}

So far so good, that should record key pressures from Jack Midi.
But now look at the corresponding section in our ALSA driver:

alsaProcessMidiInput()
{
	...
                  case SND_SEQ_EVENT_NOTEON:
                  case SND_SEQ_EVENT_KEYPRESS:
                        event.setChannel(ev->data.note.channel);
                        event.setType(ME_NOTEON);
                        event.setA(ev->data.note.note);
                        event.setB(ev->data.note.velocity);
                        break;
	...
                  case SND_SEQ_EVENT_CHANPRESS:
                        event.setChannel(ev->data.control.channel);
                        event.setType(ME_AFTERTOUCH);
                        event.setA(ev->data.control.value);
                        break;
	...
}

We are converting ALSA key pressures to note ons ! 
Thus we're not even creating any MusE ME_POLYAFTER events.

Does anyone know why this was done?

** I've changed it here so SND_SEQ_EVENT_KEYPRESS create true
 ME_POLYAFTER events and will commit if NO OBJECTIONS.


Now, on to the sending. Our Jack Midi driver sends both
 channel and key pressures, but our ALSA driver does not:

MidiAlsaDevice::putMidiEvent()
{
	...
            case ME_POLYAFTER:
                  // chnEvent2(chn, 0xa0, a, b);		<<<--- WEIRD, WHATS THIS?
                  break;
            case ME_AFTERTOUCH:
                  snd_seq_ev_set_chanpress(&event, chn, a);
                  break;
	...
}

Unfinished business. There is a "snd_seq_ev_set_keypress" macro.
** I've changed it here and will commit if NO OBJECTIONS.

Seems pressure events could be considered as note ons?
Is it desirable?


Now, on to  the pianoroll:
MusE does not graph channel or key pressures, although they should 
 show up in the event list editor.

Poster gave an excellent idea because these are large data streams
 that should lend themselves well to graphing.

I reckon that since we already have specialized code for velocity...
 we could leverage our knowledge there and show pressures as well.
Except... Here in MusE velocity really IS a controller... Trouble ahead?

const int CTRL_VELOCITY = CTRL_INTERNAL_OFFSET      + 2;

Oh yeah! Internal controllers! Veeeerrry good.

Let us define 2 new controls, similar to the velocity:

const int CTRL_VELOCITY = CTRL_INTERNAL_OFFSET      + 2;
const int CTRL_POLYAFTER = CTRL_INTERNAL_OFFSET      + 4;
const int CTRL_AFTERTOUCH = CTRL_INTERNAL_OFFSET      + 5;

And similar to the velocity control, let us create 2 new controllers:

MidiController veloCtrl("Velocity",  CTRL_VELOCITY,   0, 127,   0);
MidiController polyAfterCtrl("Key pressure",  CTRL_POLYAFTER,   0, 127,   0);
MidiController afterCtrl("Chan pressure",  CTRL_AFTERTOUCH,   0, 127,   0);

This should make our task a whole lot easier from here, as far as displaying
 the controllers in a popup, or drawing them in the graphs.
I mean, the graphs need midi controllers. Without 'fake' midi controllers 
 for the pressures, we're nowhere. Right? 

Let's browse through the graphing code to see what can be done... 

Cheers. Tim.