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 <c_soren...@byu.edu> wrote: > > On 3/23/16 11:06 PM, "lilypond-devel-bounces+c_sorensen=byu....@gnu.org on > behalf of Daniel Birns" <lilypond-devel-bounces+c_sorensen=byu....@gnu.org > on behalf of daniel.bi...@icloud.com> 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 > _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
