Re: Project - Emacs mode extensions for LilyPond

[Francois Pinard]

[Nicolas Sceaux]

>  > [...] I was peeking around to find how one could use Timidity as a
>  > server: and it seems you did it all already! :-)

> This is the ugliest part, but its merit is that it works :)

And God yes, it does work.  To my surprise, I confess; would you ever
forgive me? :-) It's very encouraging, and stimulating.  Thanks a lot!

Experimenting a bit more, I saw a few tiny problems in this area:

1) Interpretation of played notes is absolute octave, even when notation is
   relative, and in relative octave mode.  Is it an experimenter's error?

2) If one has `<c e g>' say, the notes are heard separately rather than
   simultaneously.  I presume users might have different preferences,
   yet for one, I much prefer to hear notes of a chord simultaneously if
   from within a single voice, even for proof-hearing.

3) If one fastly types notes having long duration, we have to wait for the
   completion of the current note before starting to hear the next one.
   When typing notes one at a time, I'm mainly interested in the pitch,
   so a consistent short duration might be more appealing.  Who knows, the
   ideal might be that each note starts exactly when being typed, and uses
   its natural duration, would this means some overlapping between notes.

4) Even after byte-compilation, there is a small but notable time lag
   between a request for playing a small region (a few lines) and the
   actual start of the play.  I presume, but am not sure, that this
   lag comes for the need to pre-parse the notes to render.  If this is
   indeed the case, than Python seemingly beats Emacs Lisp speed-wise.
   I do observe some lag in Python before playing a thousand of notes or
   so, but not when playing only a few.

On that speed thing, I currently use simple kludges to segregate within a
region about where to use relative octave instead of absolute.  There would
surely be a slow down for more traditional syntax analysis, excusable
maybe through some nicer rendering of artifacts, like time multipliers.
I'm also worried about Pymacs itself, which might impose its own slow
down through its communication protocol.  Yet, so far so good...

> It seems that the only way to communicate with an ALSA sequencer (ie,
> timidity here), is via ioctl() calls, which can not be done in Emacs Lisp
> -- or so it seems.

Using `ioctl()' could be done in native Python, without the need of
writing a separate C extension.  Your `mymidikbd.c' file illustrates
how to interface with the ALSA library, but not how to use `ioctl()'.
So, for my small Midi library at least (which is a separate project),
I might write a C extension adapted from your C code, integrating it in
the Python process instead of a running it as an external process.

For any Emacs LilyPond mode, the gain is not that evident.  Communicating
each note with an external `mymidikbd' process surely has overhead, but
so would have the communication between Python and Emacs for each user
keystroke.  On the other hand, given that the throttling factor is MIDI
real-time or user typing, the overhead might not be an issue in practice.
Overhead considerations are not a big issue for the choice of language.

> There is an interface in ALSA [...]

Thanks for sharing these informations.  I do not know much about ALSA.

> Being able to hear the notes when one type them is really valuable, so
> imho this is an important feature of an emacs lilypond editing mode.

Undoubtedly.  Another thing which makes your `lyqi' project so attractive,
is the maturity it acquired.  There is a lot of work in there already.

>  > The only thing, maybe, is for the case I want to add something else;
>  > I am then more comfortable with Python than Lisp.

> I don't mind using Python instead of emacs lisp.

The problem might be using both collaboratively.  Pymacs is a natural
solution for me, no doubt, but not necessarily appealing to any programmer.
But Pymacs is not perfect, and the communication between Emacs and Python
costs overhead, so I'm never fully sure it is a good direction to take.

But I just do not want writing massive quantity of Emacs Lisp as I used
to do.  For me, a bit of Emacs Lisp is quite OK, but not a lot.  So, I'm
often willing to trade overhead against development and maintenance ease.

>  > You also are the second person telling me good about EIEIO since
>  > yesterday (indirectly).  EIEIO seems to be an add-on for Emacs for
>  > something built in Python.

> [...] as emacs lisp in general when compared to Common Lisp, EIEIO is
> a bit frustrating. [off topic: However, it shows a property of lisp in
> general: the hability to add programming paradigms at need].

Python and Lisp, both used for extending other tools, are surely themselves
extensible.  I wonder.  Does EIEIO adds another layer of slowness?

I try not only to write less Emacs Lisp than before, but also simpler Emacs
Lisp, so avoiding most of extensions written as salvaging attempts.  Too
much salvaging leaves the impression of sinking!  Yet, Emacs is so useful
and so big, that its whole sinking might extend over my lifetime. :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard