Am Montag, den 22.04.2013, 10:28 +0200 schrieb Janek Warchoł: > Hi, > > 2013/4/22 Urs Liska <li...@ursliska.de>: > > I'm in a hurry to prepare the material for the oral presentation. > > Good luck! If a recording will be available, i'd gladly watch it. No, surely not in that context. > > > I will leave out as much of the technical details as possible and focus > > on an endorsement of what can be done (and not how it is to be done). > > And I'll probably start with LilyPond right away. For the main part of > > the target group this will be the most natural link to get into > > discussion. From using versioning it's then a more natural way to extend > > to also using LaTeX. > > +1 > I think that starting with Markdown may be a good idea, because it's > very simple. Then LilyPond. I actually think now starting with LilyPond is the best I can do. Because 'notation' is something we need and actually do, while with Markdown I would first have to convince them that they need such a thing at all.
> BTW, i'm sure that all the details could be turned into a more > in-depth, "let's get our feet wet" papers. Good idea. I'll keep it in mind - will make me feel much more comfortable when 'deleting' stuff from the draft ;-) > > > [...] MusicXML [...] > > indeed. > ;) I'd actually say it is crucial to have that in order to get LilyPond a foot in the publishing world. We can't expect publishing houses to easily switch their well-tested workflows. And it's hard to convince editors or organizations preparing editions to switch to a toolchain they can't use for delivery. With the option to export the final result of an edition to a mainstream format there is a chance to get editors interested. And if editors would be interested using it at some scale there is a *slight* chance they could propagate it to publishers. One thing which might be important in that respect would be to develop some kind of 'coding standard'. I think in our projected ideas we should really go for that and present a 'representative' code base that - is consistent in its coding style - proves being well maintainable - is well documented - is very compatible with versioning This would be very good to have as 'promotional material' > > some more thoughts: > > It may be a good idea to explain why plain-text approach isn't > widespread yet, because people will probably think "there must be a > trick here; if it was really so brilliant everyone would use it > already". > > While i'm very enthusiastic about git, it may be a better idea to > advertise using mercurial here. I've read a bit about mercurial, and > it seems to be quite similar to git indeed (one thing that i missed is > git's powerful rebase, but people new to vcs would probably have huge > problems with such advanced tools). One big advantage is that > mercurial is natively cross-platform, while git was created with Linux > in mind. As a small addition, i've found a nice simple gui called > easymercurial, which seems to be really great for beginners. I > haven't found anything similar for git. Anyway, it should be possible > to write this part of the article in a way that fits both mercurial > and git. > > As for plain text advantages, i've found some more: > - your content is safer: even if the program/computer crashes, your > data won't become corrupted. > - greater availability: you can write your content in a smartphone (i > don't imagine Finale on a touchscreen), on your friends' computer, in > an internet cafe - and compile it at home > - smaller filesize and easy compressability make it perfect for big databases > - plain text is possible to recover from a hard disk crash or partial > file corruption. In case of binary files recovery is quite impossible > (i've experienced this myself). Thanks! Urs > > Man, am i excited! > > best, > Janek > > _______________________________________________ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
