I would not put too much emphasis on the ms delays and traffic volume
generated by these messages. It has been generally agreed that the bandwidth
of MIDI would have killed it a long time ago had it not been for 'integrated'
systems that passed MIDI internally hence had no bandwidth limitations and
that MIDI/USB is keeping it alive today. The device you are talking about has
a USB connector which can be used at a later date when you need bandwidth
so perhaps concentrate on functionality for now? Just a suggestion.

A bigger problem regarding pressure is whether the device can support either
channel or poly pressure. There are surprisingly few that support poly pressure
as the hardware required to do it (sensors under each key) is still exorbitantly
expensive and also pretty heavy. OK, it can be done cheaply as well however
the cheaper hardware gives two problems that make it's use difficult:

a. it can be overly sensitive so difficult to control
b. it is generally low resolution so you hear each step in pressure change

Velocity sensing by contrast typically just uses two space separate contacts
and some high speed key scanning - very cheap and cheerful. And portable.

Any hardware that can do velocity sensing for note on can also do it for note
off events if suitable software coding is done. Whether a synth can track the
note off velocity is variable and there are naturally good and bad targets for
note-off velocity:

Bad targets:
Volume/gain, filter cutoff, FX depths, : All of these might be normal for
note-on velocity but are very bad selections for note-off. They cause pops
and clicks when key-on velocity is very different from key-off velocity.

Potentially good targets:
ADSR release rate.
Exceptional processing (bv. piano damping effects).
LFO speeds

I think one of the reasons that many synths have avoided doing anything
with note-off velocity is that the typical targets are not the same as with
note-on velocity hence there are some semantic issues associated with how
they need to be directed. Most synths have 'velocity sensitivity', but if it is so
glib that both values control the same parameter then the results will not be
what you are probably expecting: they should vary rarely be directed to the
same synth parameter.

Kind regards, nick.

"we have to make sure the old choice [Windows] doesn't disappear”.
Jim Wong, president of IT products, Acer




> Date: Sat, 26 Sep 2009 23:09:38 +0200
> From: ralf.mardorf@alice-dsl.net
> To: jens.andreasen@comhem.se
> CC: linux-audio-dev@lists.linuxaudio.org
> Subject: Re: [LAD] "Open midi-keyboard"
>
>
> > Jens M Andreasen wrote:
> >> On Sat, 2009-09-26 at 14:03 +0200, Ralf Mardorf wrote:
> >>
> >>
> >>> When using several MIDI ports even a lot of SysEx can be sent
> >>> real-time, but using only one MIDI port even aftertouch can cause
> >>> timing problems.
> >>
> >> A stream of channel-aftertouch is single bytes, and can at any point be
> >> interrupted by more important data (note-on) with at most 0.3
> >> miliseconds delay ...
> >
> > When interrupted it's 2 bytes, one byte only when running status can
> > take effect. To be honest, I don't know if aftertouch will be
> > interrupted by applications and devices by default. Is this MIDI
> > standard? And to be honest, much more data is produced by the pitch
> > wheel, because of the low and high byte. I never had any timing issues
> > because of aftertouch and pitch bend, but I noticed that they produce
> > much more traffic than real-time SysEx for filters. IIRC I had 4 MIDI
> > outputs for the Atari ST, I guess using just one MIDI output can cause
> > trouble for pure MIDI music.
> >
> > Ralf
>
> Yes, the Midex had 4 MIDI outs.
>
> Have you tested heavy traffic with just one MIDI port?
>
> I can't speak for aftertouch, but SysEx can become problematic. Okay,
> SysEx always needs to be transmitted from $F0 to $F7, while aftertouch
> can be interrupted, anyway, aftertouch can cause really a lot of data,
> much more than SysEx for filters.
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

---

check out the rest of the Windows Live™. More than mail–Windows Live™ goes way beyond your inbox. More than messages