Re: [PATCH] Notes (and possible fixes) for several small problems with MIDI output (issue #1661 among others)

[Heikki Tauriainen]

David Kastrup wrote:
> Heikki Tauriainen <address@hidden> writes:
>
> > 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 see.

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

Well, since the first two issues seem to be essentially caused by the
variance in the ordering in which Audio_items occurring at the same time
are fed to various worker classes (Midi_walker and Staff_performer in this
case), I could imagine that -- if there is some higher-level layer of code
which handles this generic process in both cases (taking the events from
some common Audio_item stream) -- the prioritization of events occurring
at the same time would probably be better handled in this layer instead of
fixing the event ordering separately in every low-level layer whose
correctness depends on a sub-ordering of simultaneous events.

As I wrote, I didn't really have a good picture about the interaction of
the various parts of the code to have known where to look for the
implementation of this generic process (if there is such a layer), so
I focused on the low-level modules instead just to see if I could make
things work.  I fully understand that it wasn't probably the best
approach.

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

I also suspect that this is more of a design issue (what kind of
interfaces to offer for user-level MIDI programming, whether the added
interfaces fit well with the old behavior, and if not, whether the
default behavior should be changed) than an implementation issue (as to
how much code is actually needed to implement support for these
interfaces).  Before starting to plan a new design, it is obviously
critical to first have a good understanding of the overall architecture.
I don't really consider myself knowledgeable enough at this point to be
able to contribute to such a design process in any useful way expect for
possibly sharing my experiences (and some misconceptions and surprises
I've had as a user) with the current behavior.

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

Thanks for the information.  Maybe I'll have a look at this part of the
code to see whether I could learn more about these interactions.

--
Heikki Tauriainen