Re: [Denemo-devel] Midi shortcuts

[Richard Shann]

On Tue, 2011-05-10 at 11:40 +0200, R. Mattes wrote:
> On Tue, 10 May 2011 09:02:45 +0100, Richard Shann wrote
>  
> > This sounds really great. I should mention that up until recently I did
> > not consider making a round trip to scheme for every note played on the
> > MIDI keyboard as the handling of MIDI-in was in a very bad state. 
> 
> Is there any factual evidence for this claim?
Well the claim that the handling of MIDI-in was in a very bad state
scarcely needs evidence :)


>  After all, running a hook 
> only involves a 'scm_car' on the function stack and a 'scm_apply' on the
> returned function for the common case of a single handler function.
>  
> That's not really a high penalty, esp. considering the Quadrilles the current
> code dances
The point I was making is that for note on/offs there are no calls to
scheme
>  ... A single string eval would have a magnitude higher performance
so there are no string evals for this case

> hit. Even in venerable Emacs every single keypress dribbles through hooks and
> layered keybindings - in Elisp!

So if we have a good no-string-eval hook it will cost us nothing -
great!
>   
> > The
> > code still has the response to all note on and off messages routed 
> > in C to actions while other messages call a scheme hook (interpreted 
> > strings ...) There is a similar story with pc-keyboard in for which 
> > I wrote a proposal 
> > http://denemo.org/index.php/Scheme_hook_for_keyboard_input
> 
> I'm tempted to use the same mechanism for keyboard input as well.
Sounds good - I could have saved myself the bother of writing the
two-keystroke code in C.

>  
> > It may be that we will need to make scheme hooks for MIDI note events
> > optional - else playing-in at full speed may not work properly on slower
> > machines.
> 
> What's your fear (or your goal) ? Midi events should be collected by a
> dedicated thread anyway (otherwise you might loose events due to GUI
> code running in the same thread) [1].

Right. This issue is being addressed by this year's gsoc, or at least
the clean-up that would enable separate threads to be use.

>  The C-level event handler should fetch
> events from that queue and feed it to the handlers. Now, if your box is
> to slow for keeping up with the incomming events, that's bad but there is
> little you can do about that - the handling will fall behind the performance
> and at some point
especially if it is performing lots of eval-strings ...
>  you'll start loosing midi events (because the queue gets
> filled). But that's not a problem of calling _one_ scheme function, 
> scm_apply... is pretty fast. 
Yes - I am sure you are right; the key is to make non-ticklish calls to
scheme. Thanks for the insights into this stuff.
Richard



> 
> Cheers, RalfD 
> 
> 
> [1] at least in Jack Midi events are timestamped so you don't loose 
> timing information.
> --
> R. Mattes -
> Hochschule fuer Musik Freiburg
> address@hidden
>