[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Project - Emacs mode extensions for LilyPond
From: |
Nicolas Sceaux |
Subject: |
Re: Project - Emacs mode extensions for LilyPond |
Date: |
Thu, 31 Jul 2003 20:11:15 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) |
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
- Project - Emacs mode extensions for LilyPond, François Pinard, 2003/07/30
- Re: Project - Emacs mode extensions for LilyPond, Nicolas Sceaux, 2003/07/30
- Re: Project - Emacs mode extensions for LilyPond, Francois Pinard, 2003/07/30
- Re: Project - Emacs mode extensions for LilyPond, Nicolas Sceaux, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond, Aaron, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond, Francois Pinard, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond,
Nicolas Sceaux <=
- Re: Project - Emacs mode extensions for LilyPond, Francois Pinard, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond, Ferenc Wagner, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond, Nicolas Sceaux, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond, Ferenc Wagner, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond, Ferenc Wagner, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond, Aaron, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond, Francois Pinard, 2003/07/31
- Re: Project - Emacs mode extensions for LilyPond, Aaron, 2003/07/31
Message not available