Re: midi articulation

[Daniel Birns]

Thanks for your kind note.

Of course, I completely understand the protectiveness. That’s how it must be. 
Before I do anything, I’d like to discuss my thoughts on the matter.

Inside vs. Outside
______________

OUTSIDE: The Unix idea is to have many small, testable apps that are designed 
to be able to work together. In this view, one should have an Engraver (aka 
lilypond) as a single app that doesn’t try to do anything else. In addition, 
the lilypond syntax becomes the key interface, and lilypond can be the Engraver 
as well as the Validator. Midi should be a separate app that reads the same 
source and generates midi. 

Of course, there are other ways to layer this, in the unix model. Perhaps there 
should be a parser which generates an internal format, and then lilypond could 
read that, and the midi generator could also read the internal format. 

Perhaps lilypond already has a suitable internal-format, post-parsed format 
that would be more suitable for a midi-generator.

INSIDE: Generating midi out to be a great deal easier in lilypond because it 
has already parsed everything, ought to know, at any point in time, all the 
information necessary to generate better midi output. Currently, it’s missing 
many things, like note-durations, and so on. I wonder why that is? I’m 
suspecting there’s a fundamental reason, and that it’s because the information 
is split up among all the various engravers?

Midi is a big subject, and keeping midi generation inside lilypond may generate 
fears, probably well-founded, of increasing size and complexity.

Midi Sounds
__________

I’m no midi expert, but I’ve used it over the years. My impression is that 
tools like Apple Logic, Sibelius, and so on, provide their own sounds, which 
are unrelated, in particular, to midi, which only gives a slight clue to the 
desired sound. To give a reasonable midi result, I believe we must go that 
route: provide a sound library, and a player. A user would then be able to 
write a lilypond score, and get a reasonable audio playback of that score. We 
could generate midi as we have always done, but the midi would have much better 
articulation and dynamics than it currently does. 

I’m certain I’m not the first to think about all this…

-d

> On Mar 24, 2016, at 4:37 PM, Carl Sorensen <address@hidden> wrote:
> 
> On 3/23/16 11:06 PM, "address@hidden on
> behalf of Daniel Birns" <address@hidden
> on behalf of address@hidden> wrote:
> 
>> Hi developers,
>> 
>> We¹ve been having a discussion about midi. I could say a lot about this,
>> but I¹m sure some developers have thought a great deal about this, and
>> probably for many years, so I don¹t want to second-guess.
>> 
>> As I report in the following thread, I¹m a software developer, mostly
>> experienced in C++, and have thought maybe I could assist in such a
>> project, but naturally I would first want to know if a) there¹s any
>> interest in outside developers contributing to the midi output quality
>> and b) what has gone before.
> 
> 
> We're always open to having new developers come and contribute to LilyPond.
> 
> The original team was (as has been mentioned) heavily focused on creating
> printed scores, so midi output was just included for "proof-listening",
> and generating high-quality midi was not a concern.
> 
> A few years in to the development, articulate.ly was developed to help in
> automatic generation of robotic music, IIRC.
> 
> You're not alone in wishing we had better midi output; users have
> requested it multiple times.
> 
> If you're willing to jump in and develop better output, we'd love to have
> you do so.
> 
> From time to time, you may find us protective of the code base.  But we
> are open to different ways of doing things when a developer is willing to
> invest time and show that the new way is sane.  SO if we complain about
> some of your initial attempts, please don't think we're trying to shut you
> out.  I promise you, we're not.
> 
> I think that you could get some history by searching the issues list for
> midi.
> 
> I hope you'll join us!
> 
> Thanks,
> 
> Carl
>