lilypond-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Notes (and possible fixes) for several small problems with M


From: David Kastrup
Subject: Re: [PATCH] Notes (and possible fixes) for several small problems with MIDI output (issue #1661 among others)
Date: Tue, 17 Jul 2012 15:56:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Heikki Tauriainen <address@hidden> writes:

> I consider myself just a LilyPond user who occasionally lurks on the
> mailing lists (but who also happens to a coder, and hardly at all a
> musician).  Since there appears to be only infrequent discussion on
> open issues related to MIDI output and their possible workarounds on
> the mailing lists -- I guess simply because the vast majority of
> people use LilyPond mainly for music typesetting --

It's more like "the code is undocumented, inaccessible from Scheme, and
the only one who knows how it works and what it does is Jan".

> I thought that I'd have the best chance of getting rid of some minor
> annoyances in LilyPond's MIDI output if I tried to analyze the
> problems and fix them myself.  Unfortunately, I'm only learning and
> guessing things about the inner workings of LilyPond mostly as I try
> to read and understand the source code, and I'm sure this lack of
> familiarity with the organization of the code is reflected (badly) in
> the quality of the patches -- for example, I wouldn't be at all
> surprised if some of my patches to the C++ code could be implemented
> in a much more elegant way with just a few lines of Scheme in some
> appropriate place :-)

For the MIDI code?  Unlikely.

> Anyway, I decided to share my observations and patches in case they
> might still be of help to improve the behavior of this excellent
> application.

If you can be interested in working on the MIDI code, I am sure nobody
would object.  It would be nice to open MIDI more to user-level
programming.  However, that would require looking more into the Guile
side of things and design useful interfaces harmonizing with the rest:
not exactly a task put at the feet of someone just starting to get
acquainted with the code.

Usually, the order of looking at music events is established by the
order of performers (check ly/performer-init.ly) and by the particular
hooks they use for getting information (listening to events, waiting for
start/end of time step and so on).

It is quite conceivable that juggling with those areas can bring the
order of MIDI events into shape already.

-- 
David Kastrup




reply via email to

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