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 _______________________________________________ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
