lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Lobbying paper follow-up


From: Urs Liska
Subject: Lobbying paper follow-up
Date: Thu, 25 Apr 2013 02:08:21 +0200

Hi all,

trying to catch up on all the stuff written lately.
Obviously I somewhat lack the overview, so I try to do my best to do
everybody justice (knowing it won't work out ...)


###################
Structure/Outline of the paper

Am Montag, den 22.04.2013, 10:09 -0400 schrieb Carl Peterson:
> Begin with the current reality for most people. You mentioned in this
thread your 
> frustration with Finale. I had the same frustrations when I was using
it at university and I 
> know other people still do. Begin by describing that frustration.
Remind people of all the 
> things they dislike about Finale to prepare them for a better way. 
> 
That's a good idea, and I think it worked out quite well in my
presentation today. So I'll keep it for the written version.

Am Montag, den 22.04.2013, 10:28 +0200 schrieb Janek Warchoł:
> I think that starting with Markdown may be a good idea, because it's
> very simple.  Then LilyPond.
For my presentation I completely rearranged the outline. Which was quite
easy as I had a concrete audience in mind.
I started with a general overview of the text based approach (toggling
between text and music documents) and moved on to the concept of
versioning.
The first examples they saw on the screen were 
a) the comparisons of the file contents for minimal examples done with
Finale-Sibelius-Lilypond and
Word-OOo-LaTeX
b) a rendering of a very complex piano score with eight voices that
rendered near-perfect without any manual interventions.
This was presented after explaining that LilyPond can benefit from the
non-realtime approach and first create a good internal representation of
the musical structure.

All this seemed to work quite well, and I think it is also a good
concept for the 'paper' version.


###############
Various topics


Am Dienstag, den 23.04.2013, 10:26 +0200 schrieb Jan-Peter Voigt:
> "Add the missing pieces based on a printout" is not an option for
binary
> > formats.
> +1
> I would focus more on that. My file uses about 50kB ... that is not
so 
> much today and fits on any USB flash pen and is mailable. And
probably 
> this is caused of my inexpertise with finale!
> But how to recreate a damaged file?
> And how to use an old file ... I still have a lot of old Emagic 
> MicroLogic V2 files. They will not open in Logic 8, so I have a Logic
7 
> Installation, which opens the files, if I started the program in
rosetta 
> (PowerPC emulation on mac) ...
> In a text based file, you may still be able to adapt it manually.
> 
>
While this attracted some interest during my presentation, I'm not so
sure if that's rather an academic question. Do you know of someone
having actually recovered from a text file suffering from a disk crash -
and not having spent more work than starting again from scratch?

Am Montag, den 22.04.2013, 10:28 +0200 schrieb Janek Warchoł:
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).
> 
I included these points in my presentation and it seemed to be quite
convincing.


Am Montag, den 22.04.2013, 10:28 +0200 schrieb Janek Warchoł:
> While i'm very enthusiastic about git, it may be a better idea to
> advertise using mercurial here.  
Yes, you're right. The thing is : I don't know anything about it.
But from my experience in the presentation I think I will abstract this
out completely. I told the people what versioning is about and how it
works principally. 
As nobody expected a thorough introduction to actually working with it
they were quite satisified.
Talking about different versioning systems is actually out of scope.
Should be done at another place (but probably should be done)

Am Montag, den 22.04.2013, 10:09 -0400 schrieb Carl Peterson:
> In describing advantages of the plain-text format, I suggest more
"customer-focused" 
> advantages (or descriptions of the advantages) and fewer
programmer-oriented 
> descriptions. 
I'll try to do that as best as I can. From my presentation today I have
a better picture of the audience now.

Am Montag, den 22.04.2013, 10:09 -0400 schrieb Carl Peterson:
> For example, in my current project, a big advantage of Lilypond is
the 
> portability of lyrics. I can store my lyrics separately from the
music. This means that if I 
> want to reuse a tune for lyrics with the same meter, I don't have to
re-invent anything. 
> This is also great when it comes to internationalization. If I have a
German translation of 
> English lyrics, all I have to do is drop a reference to the German
lyrics. 
> 
That's a very good example for the advantages of variables and comments
(commenting out).

Am Montag, den 22.04.2013, 10:09 -0400 schrieb Carl Peterson:
> I'm not quite sure as to the right way to do this, but I suggest
leaving as much of the 
> technical "how-to" discussion as possible until the end of the essay.
While yes, there is a 
> stark reality of having to hand code most of the LilyPond file, unless
someone is already a >programmer of some sort, it seems there is a steep
"buy in" curve and throwing code in 
> (no matter how simple) gets an automatic "run away" reaction. If the
goal is to persuade 
> someone to use LP, have them so convinced of the advantages (perhaps
by doing a 
> point-by-point comparison to Finale) that the code doesn't seem like
much of a barrier. 
> 
By now I have come to the conclusion that it is a good idea to mostly
keep out code completely. It seems quite feasible to have this whole
paper as an abstract argumentation. Or at least have two distinct parts:
I. being abstract and 'code-free', II. diving in to some extent.



####################
Further thoughts

Am Montag, den 22.04.2013, 10:28 +0200 schrieb Janek Warchoł:
> BTW, i'm sure that all the details could be turned into a more
> in-depth, "let's get our feet wet" papers.
> 
Yes, I think I will boil it down to a 'pitch' paper, also based on the
feedback of today's discussion.
Then I (one) can reference more in-depth sections as you describe.
I think this even could be started with a larger coherent document in
mind. I.e. write independent articles on the different topics, but
having in mind they could become the chapters of a (smaller) book.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]