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. _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
