Re: Project - Emacs mode extensions for LilyPond

[Nicolas Sceaux]

31 Jul 2003 09:05:41 -0400, Francois Pinard a dit : 

 > [...] 
 > 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?

I think I'm missing the problem, but as I don't use relative octave
myself, you must be right.

 > 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.

That's a lack in the parser and in the developper's mind. As I don't
use many chords, I thought that would not be a big deal. laziness... 
That's a todo thing!  

 > 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. [...]

You're right, that definitively annoying. When typing, the duration
should always be short.

 > 4) Even after byte-compilation, there is a small but notable time lag
 >    between a request for playing a small region (a few lines)
 > [speed considerations]

Speed was not my first concern at the time I wrote that. However in a
not-too-fast station it can become an issue. IMHO speed is more
critical when typing notes, than when requesting a playback: notes
should be written and heard with a minimum latency. On my machine,
it's ~OK, but I may try on a slower machine.
About play back on region, the algorithm is of course perfectible: We
don't have to parse a whole region before playing the first
note. That might solve the problem. Here, as in many other places, the
code is more a prototype.

 >> 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()'.

No of course, ALSA lib source code tells that. I have noted somewhere
the relevant places. (but where is this piece of paper...)

 > [...]

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

I would not say that. I have made a first draft during a week when I
was half blind, and this version at the beginning of my summer
holidays, roughly tested. It's far from mature. I would call it a
prototype. 

One place where lyqi is not good, is the parser part. I always feel
like reinventing the wheel in such occasions. I lack reading some
documentation on that subject. I tried to make it easily extensible,
but I fear it is not.

 > [...]
 > 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.

That's reasonnable!

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

Certainly it does. However, I have not read its source code, but we
can expect it's implemented with lots of macros. So an important part
of the work may well be done at byte-compile-time.

 > 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. :-)

It's precisely for development and maintenance ease that I choosed to
use EIEIO, being otherwise reluctant to make the package depends on
extra libs.

[if this conversation does not interest other people, maybe we should
go on privately?]

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