Re: [Denemo-devel] Midi shortcuts

[R. Mattes]

On Sat, 07 May 2011 22:16:53 +0100, Richard Shann wrote
> Oh - I see, and I was blaming Jeremiah:)
> Well it has to be re-definable at runtime (IIRC), not just for folk who
> want to create their own MIDI shortcuts but for the case where a script
> wants to re-program how the MIDI controller works. 

I see - this makes sense. But I have a nagging feeling that this would
actually be a good use case for guile's hook functions.


> That looks neat stuff with scm_c_lookup() and such, as you may have
> surmised it is sheer ignorance on my part. And, now that you mention 
> it I did spend a year or so writing Tcl more recently than the Lisp 
> I did before that.

Have been there too (long ago, writing a custom editor for lute
tablature ....)

> But all that was over 10 years ago. Really, I am just
> hacking together something to do the job out of the bits that I know
> about...

BTW,  my code example is longer than it needs to be, there's no need
to establish a dynamic context at all - I was fooled by the original
code. No idea why there's  scm_dynwind_... at all. No need for it.

I guess my general concern is that there is no distinction whatsoever
between the C side of denemo and the guile side. For example, is
get_midi_control_command part of the internal C core or is it part
of the scheme side? AFAICT the function gets only called from one
other function (process_midi_event). And it duplicates a lot of code
from get_midi_pitch_bend_command. Why not just have one scheme handler
(MIDI-shortcut::lookup-action)?  Looking at the code, it might even
be reasonable to have this handler perform the action. So we might end 
up whith something like:

(define (midi-shortcut::handle-ctrl channel type . data)
  "Handle MIDI controller input, channel is the recieving
   MIDI channel (where applicable), type is a one of
   #:pitchbend #:sustain #:ctr, data is a list of 
   (7-bit) MIDI bytes"

   ......)


But, as I said, I might make sense to use hooks here, so a script could
install a handle-ctrl hook and remove it afterward, thus restoring the 
previous input state.

 Cheers, RalfD

> Thanks for the suggestions,
> 
> Richard
> 
> On Sat, 2011-05-07 at 22:55 +0200, R. Mattes wrote:
> > On Sat, 07 May 2011 17:16:25 +0100, Richard Shann wrote
> > > I am exceedingly puzzled by this: my code does not have such a 
> > > static -
> > 
> > No - this is my quick hack-up to show an alternative to generating and
> > then evaluating strings (remember: eval is evil :-)
> > 
> > >  it seems to be some version of the code developed by 
> > > Jeremiah to fix memory leaks. But I don't know where it has come 
> > > from, as I have just committed and so must be up-to-date. Where have 
> > > you gotten this from?
> > > (as you say it is wrong, a regression on the release) Richard
> > 
> > No - I deliberately did put in the static to optimize method lookup.
> > Of course - if you feel the need to make Midi-shortcut::controller
> > changeable at runtime just leave out the static declaration.
> > 
> > 
> >  Cheers and sorry for the confusion
> > 
> >  RalfD
> >  
> > > On Sat, 2011-05-07 at 12:06 +0000, Ralf Mattes wrote:
> > > > On Sat, 07 May 2011 11:58:16 +0000, Ralf Mattes wrote:
> > > > 
> > > > > 
> > > > > gchar *b(guchar type, guchar value) {
> > > > >     static SCM lookup_fun = scm_c_lookup("MIDI-shortcut::controller");
> > > > >     gchar  r_val = NULL;
> > > > >     SCM    res;
> > > > > 
> > > > >     scm_dynwind_begin(0);
> > > > >     res = scm_call_2(lookup_fun, SCM_I_MAKINUM(type), 
> > SCM_I_MAKINUM(value)); 
> > > > >     if(scm_is_string(res)) {
> > > > >         SCM2LSTRING(r_val, res);
> > > > >     }
> > > > >     scm_dynwind_end();
> > > > >     return r_val;
> > > > > }
> > > > 
> > > > Just one more comment about this code: as a result the value of
> > MIDI-shortcut::controller 
> > > > is looked up only once, hence runtime redefinition won't work. If this 
> > > > is
> > wanted, just
> > > > remove the static from the definition of lookup_fun.
> > > > 
> > > >  Cheers, RalfD
> > > > 
> > > > > 
> > > > > Cheers, RalfD
> > > > > 
> > > > >> HTH
> > > > >> Richard
> > > > >> 
> > > > >> 
> > > > >> 
> > > > >>
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Denemo-devel mailing list
> > > > address@hidden
> > > > https://lists.gnu.org/mailman/listinfo/denemo-devel
> > 
> > 
> > --
> > R. Mattes -
> > Hochschule fuer Musik Freiburg
> > address@hidden
> >


--
R. Mattes -
Hochschule fuer Musik Freiburg
address@hidden