Re: Request for feedback on 'lobbying' paper

[Urs Liska]

Am Montag, den 22.04.2013, 10:28 +0200 schrieb Janek Warchoł:
> Hi,
> 
> 2013/4/22 Urs Liska <address@hidden>:
> > 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user