lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to develop Emacs mode?


From: David Kastrup
Subject: Re: How to develop Emacs mode?
Date: Thu, 17 Jun 2010 17:31:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> On 6/17/10 8:59 AM, "David Kastrup" <address@hidden> wrote:
>
>> 
>> 
>> Hi,
>> 
>> I have a question about developing Emacs input and major modes for
>> Lilypond.  What would be the right way to go forward for me?
>> 
>> I want to make use of current Emacs features (like semantic parsing and
>> similar).  I also want to create input methods for inputting on the
>> keyboard in chromatic button keyboard layout, but also in parallel for
>> inputting via midi (I already checked that make-serial-process can be
>> used for opening and accessing a midi device on GNU/Linux).
>
> Are you familiar with lyqi?
>
> <http://nicolas.sceaux.free.fr/lilypond/lyqi.html>

Not chromatic button accordion layout, and I should think that a regular
input method might be cleaner.  I think I checked it out at one time,
and the payback for the installation trouble seemed not convincing to
me.  In particular, French note names were not interesting to me.  I
should think that the canonical input method should be Dutch.

> and rumor?
>
> http://www.volny.cz/smilauer/rumor/rumor.html

Separate program, own timing, similar timing problems to midi2ly
(basically unusable), no sane treatment of enharmonic equalities.

A separate program is not necessary, the following works fine for
demonstrating getting at Midi data from /dev/midi1:

(make-serial-process :port "/dev/midi1" :speed nil
      :buffer "*lily-midi*"
      :coding 'binary
      :noquery t
      :filter (lambda (process string)
         (message (mapconcat (lambda(x) (format "%02x" x)) string " "))))

Not having to install and/or compile binaries definitely is going to
make this more attractive.

One point of using something midi-based (and also using a
single-keystroke input method) would be to record the key press and
release times in text properties.  When inserting bar lines afterwards,
the durations can be quantized and inserted bar-by-bar, making for a
much better hit rate.  I don't trust myself to input anything useful all
in batch mode.  But resynchronizing bar by bar, I have a chance to get
somewhere.  That's something I'll want integrated with my editor in an
interactive manner rather than as a batch process.

> I would guess that authors can be determined, and that they would be
> sympathetic.

Sounds good.  At some point of time I'll have to make the decision just
how much material is going to be worth reusing, and then I might get in
contact with them.

Thanks,

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]