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 > [email protected] > _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
