Paralellizing Lilypond [was: Re: Sibelius Software UK office shuts down]
On 07/08/12 00:01, Han-Wen Nienhuys wrote: On Mon, Aug 6, 2012 at 6:53 PM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: I think you're focusing on the wrong kind of architecture. I'm talking about the architecture of computers that people can buy in the shops today. While cute, a 192-way ARM server is useless in realistic scenarios. See eg. http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/pt-BR/us/pubs/archive/36448.pdf - aka. Let's use 9 pregnant women, we'd have a baby within the month. Yes, good point. Re the hardware, I agree that it's not the current off-the-shelf package, but it _is_ clearly a direction that hardware is taking into the future. It seems wise to anticipate that in planning the future architecture of Lilypond. Regarding parallelism, actually my real concern here isn't so much doing things in parallel _per se_ so much as as Lilypond effectively breaking up its work into smaller units, which might be dealt with in parallel or sequentially. Any speed boost is nice, but not essential compared to scalability (more on that in a moment). Unless you have a embarrassingly parallel problem to begin with (which music typesetting is not), lots of parallelism only buys you synchronization overhead, both lock contention at run-time, and the overhead of having to write race-condition-free parallel code. Note that lilypond is embarassingly parallel at the file level, so for the regression test, we already distribute the files on as many CPUs as we have available. Yes, but the problem that you have there is that it requires the user to separate out the projects manually using some kind of build system like Make. I don't see why in principle Lilypond shouldn't be able to work out those independent jobs itself -- essentially any elements separated by a page break can be handled as a separate job, and there must be other further optimizations available. For example, if you've got a 100-page full orchestral score, is it really appropriate to do a global optimization of the whole thing? How mutually dependent, really, are the first and last pages? Isn't it possible to break the work up into manageable smaller units even in the case that it's 100 pages of continuous music? It's not just about how many cores you can use, in fact that's probably a minor issue compared to: -- Largest possible memory consumption and/or calculation size. Is it capped or does it scale in an unlimited way with score size? -- Scale of rebuild process relative to size of change made. Your worst-case scenario here is probably still going to be a full rebuild, but can you minimize the _expected_ rebuild size? I remember well trying to build Valentin's opera, and building even one part of it took a huge amount of both time and memory. I don't want to think about the difficulty of _editing_ that score. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Paralellizing Lilypond [was: Re: Sibelius Software UK office shuts down]
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: For example, if you've got a 100-page full orchestral score, is it really appropriate to do a global optimization of the whole thing? Sure. How mutually dependent, really, are the first and last pages? Not much, usually. And that's what linear programming is usually going to arrive at. Isn't it possible to break the work up into manageable smaller units even in the case that it's 100 pages of continuous music? Linear programming breaks up the work into manageable smaller units. The units are not separate bunches of pages but rather independent breakpoint sequences. It's not just about how many cores you can use, in fact that's probably a minor issue compared to: -- Largest possible memory consumption and/or calculation size. Is it capped or does it scale in an unlimited way with score size? Scales with score size. It would be challenging to create output on-the-fly, namely whenever all optimum breakpoint sequences share common starting sequences, and it would depend on the absence of forward-references (like page references and stuff). -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Parallelizing Lilypond [was: Re: Sibelius Software UK office shuts down]
On 10/08/12 11:56, David Kastrup wrote: Isn't it possible to break the work up into manageable smaller units even in the case that it's 100 pages of continuous music? Linear programming breaks up the work into manageable smaller units. The units are not separate bunches of pages but rather independent breakpoint sequences. ... but if I understand right, that doesn't put a cap on overall memory consumption during the process? (I.e. the peak amount of memory that will be used at any one time?) It's not just about how many cores you can use, in fact that's probably a minor issue compared to: -- Largest possible memory consumption and/or calculation size. Is it capped or does it scale in an unlimited way with score size? Scales with score size. It would be challenging to create output on-the-fly, namely whenever all optimum breakpoint sequences share common starting sequences, and it would depend on the absence of forward-references (like page references and stuff). So what do you think about the potential of an algorithm going something like this: (1) Read in enough bars of music to take up a little over 2 pages [you can presumably do a rough estimate of the width and height of bars and staff systems on the fly]. (2) Engrave that music. Keep the first page written. (3) If the music is completely engraved, keep the second page as well, and stop. Otherwise, rewind to the start of the second page and return to step (1), reading and engraving from this new start point. So basically you're doing: engrave pp. 1 2, keep page 1; engrave pp. 2 3, keep page 2; engrave pp. 3 4, keep page 3; You could generalize this to engraving N+1 pages (N = 1) at a time and keeping the first N pages written. That should keep a firm cap on calculation size and memory consumption, as you'd only ever be engraving N+1 pages at a time. It would probably be slower for small scores, but would make it possible to build scores of any size with a constant memory footprint. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Parallelizing Lilypond [was: Re: Sibelius Software UK office shuts down]
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: So what do you think about the potential of an algorithm going something like this: (1) Read in enough bars of music to take up a little over 2 pages [you can presumably do a rough estimate of the width and height of bars and staff systems on the fly]. (2) Engrave that music. Keep the first page written. (3) If the music is completely engraved, keep the second page as well, and stop. Otherwise, rewind to the start of the second page and return to step (1), reading and engraving from this new start point. So basically you're doing: engrave pp. 1 2, keep page 1; engrave pp. 2 3, keep page 2; engrave pp. 3 4, keep page 3; You could generalize this to engraving N+1 pages (N = 1) at a time and keeping the first N pages written. That should keep a firm cap on calculation size and memory consumption, as you'd only ever be engraving N+1 pages at a time. It would probably be slower for small scores, but would make it possible to build scores of any size with a constant memory footprint. I think we have enough real problems without inventing artificial challenges. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Parallelizing Lilypond [was: Re: Sibelius Software UK office shuts down]
On 10/08/12 12:48, David Kastrup wrote: I think we have enough real problems without inventing artificial challenges. I accept that there are bigger short-term concerns -- but my experience trying to build the score of Valentin's opera is that being able to cap maximum memory consumption or calculation size isn't something artificial. It's a real challenge to Lilypond's usability. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Hi, this thread has gone in (at least) 2 entirely different directions. The original thread was about Subject as illustration of the (dis)advantages of commercial vs. open sources software like Lilypond. the other thread was about multithreading in lilypond processing. Maybe it's time to rename that thread? -- MT ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Johan Vromans jvrom...@squirrel.nl writes: David Kastrup d...@gnu.org writes: That makes my copyright red flags go up. Can you check back with Kirill and possible other authors under which conditions you are allowed to share? The plug-in and the postprocessor are both GPL. We'll likely also have to check the conditions for distributing Sibelius plugins in general to see whether they can be matched to basic free software distribution, in which case pointing at those tools would be fine. A Sibelius plug-in is a just script written in a JavaScript/Basic/Pascal-like language. It doesn't contain anything Sibelius-related (e.g. modules, headers, or other code). That sounds like we could at least link to it. Since it requires proprietary software for running, I don't think it makes sense to host or even maintain it as part of LilyPond, but pointing to it should not be a problem. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 7 August 2012 01:59, Neil Thornock neilthorn...@gmail.com wrote: Sibelius was good for us. Many of my students came to music because of software like Sibelius. A precious few came to LilyPond because of the music. That's a very good point. The learning curve of Lilypond is steep, whereas poking at note positions on a visible stave lowers the bar immensely. In this respect Sibelius has done a great service to the world of music by providing a working example of such a tool long before the open-source world caught up with musescore. However, it comes at a cost, which Sibelius users are now paying: dependence on a commercial entity for the integrity of the tools you use. In that respect, Sibelius, like Word, is a trap. I think we ought to be fighting to save Sibelius as much as anything. The ideal solution for Sibelius *users* would be for Avid to open-source their product: to stop being Netscape and start being Mozilla Foundation, which has a far more solid business model than Netscape ever did, but that requires a change of vision at the top level of Avid, as well as the mental flexibility to understand and harness the open source model effectively as well as a way to monetize it. In Netscape's case, the snowball that started the avalanche was Frank Hecker's internal report Netscape's Source Code as Netscape's Product, currently available in an updated form as Setting Up Shop: The Business of Open-Source Software at http://hecker.org/writings/setting-up-shop Sacking the key Sibelius software developers who have spent years gaining an understanding of how it works, and outsourcing its maintenance to the cheapest offer seems like a valid economic decision - or it would be if programmers could be swapped and changed like the spare parts in a car. In reality giving the maintenance of a complex program to those who do not know it is a recipe for a software disaster and corporate suicide. If they do that, Sibelius users would be wise to keep a copy of the last Sibelius installer file that was released by the last team of developers. M ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 08/08/12 12:21, martinwguy wrote: That's a very good point. The learning curve of Lilypond is steep, whereas poking at note positions on a visible stave lowers the bar immensely. In this respect Sibelius has done a great service to the world of music by providing a working example of such a tool long before the open-source world caught up with musescore. Finale was the original pioneer[*], but Sibelius made a great advance in usability, and also was (and is) superior in terms of beautiful engraving. Unfortunately that came at a cost in its own right -- I remember well that earlier versions of Sibelius were _very_ good at engraving conventional music, but if you wanted to step into more customized territory, it was not pleasant. Finale was (and probably still is) much better if you wanted to define custom notations. But you're right, the main benefit of a tool like this is to minimize the gap between making a change and being able to see and hear the result. [* Technically, SCORE is the music notation pioneer, and in some ways still sets the standard in terms of computer engraving quality. Unfortunately it's not really kept up to date in terms of being available for modern operating systems. It's also in many ways more a precursor of Lilypond given that its model was ASCII text data entry: http://www.ccarh.org/courses/253/handout/scoreinput/ http://www.winscore.info/index.html The Windows-oriented version seems to have been in Beta for a long time, and it's not really clear to me where it's going, although it does seem to still have a small but dedicated community.] The ideal solution for Sibelius *users* would be for Avid to open-source their product: to stop being Netscape and start being Mozilla Foundation, which has a far more solid business model than Netscape ever did, but that requires a change of vision at the top level of Avid, as well as the mental flexibility to understand and harness the open source model effectively as well as a way to monetize it. But Avid's motivation was not the benefit of their users, or even the profitability of the business model. Sibelius alone was a very profitable piece of software -- Norman Lebrecht cites a turnover of about $18 million, which surely translates into a very large profit margin. The reason for cutting the development team was to try and divert more of that turnover to profit, to cover profit shortfalls from other areas of Avid's business. If you're talking Sibelius alone, it would be very difficult to make a _business_ case for open-sourcing it, given how successful it was in terms of proprietary sales. And if Avid is not willing to sell Sibelius back to the original owners, for money, how much less willing are they going to be to open source it? In Netscape's case, the snowball that started the avalanche was Frank Hecker's internal report Netscape's Source Code as Netscape's Product, currently available in an updated form as Setting Up Shop: The Business of Open-Source Software at http://hecker.org/writings/setting-up-shop I rather think that SCORE is the software that ought to consider an open source model. It was the original pioneer, but has fallen by the wayside due to lack of maintenance. The WinScore development seems to be rather stagnant, and in any case a modern graphical version would need to target a wider range of platforms and operating systems. It's unlikely there's a lot of money in that software now, and open-sourcing it could be the shot in the arm that it needs to recapture a wider user community. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 08/08/12 12:21, martinwguy wrote: That's a very good point. The learning curve of Lilypond is steep, whereas poking at note positions on a visible stave lowers the bar immensely. In this respect Sibelius has done a great service to the world of music by providing a working example of such a tool long before the open-source world caught up with musescore. Finale was the original pioneer[*], but Sibelius made a great advance in usability, and also was (and is) superior in terms of beautiful engraving. Unfortunately that came at a cost in its own right -- I remember well that earlier versions of Sibelius were _very_ good at engraving conventional music, but if you wanted to step into more customized territory, it was not pleasant. Finale was (and probably still is) much better if you wanted to define custom notations. But you're right, the main benefit of a tool like this is to minimize the gap between making a change and being able to see and hear the result. It is also omitting the need to learn the note names and stuff. For the step between a WYSIWYG text editor and basic text input, you at least have a keyboard with letter names written on all the keys, and the letters look similar to the letters on screen and are entered in sequence. With music, you first need to learn the note names before you can even type them into LilyPond. A Midi keyboard, while not being notation and thus not necessarily perfectly useful for singers or non-keyboard players, at least has a more direct connection to music. But we all know how much Midi input for LilyPond sucks: nobody really uses that. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 8 August 2012 15:02, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 08/08/12 12:21, martinwguy wrote: And if Avid is not willing to sell Sibelius back to the original owners, for money, how much less willing are they going to be to open source it? Well, you know what the name Avid suggests? ;-) But that doesn't necessarily mean that they would profit less or more from taking the OS step. However, it might require an enlightening dream in the copyright owners :) In the meantime, our strategy as lilypond etc users, as well as for the Sibelius community, seems to be to interpret their compressed file formats and implement a better free alternative, the same as OpenOffice/LibreOffice have. And hope for the best... :) M ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Graham Percival writes: Getting an actual LilyPond score requires calculating line breaks and there's no way to get rid of the overhead. Sure there is. Compile each bar individually with the default spacing (i.e. whatever you get if your entire score is one bar and you use ragged-right=##t). Indeed. There are several approaches here that I'm looking into and I'm [intermittently and slowly] working at; see Schikkers-List http://news.lilynet.net/?The-LilyPond-Report-22lang=en The idea is to have a native GTK frontend used for user input and rendering initially, and to look into rendering onto HTML later. Greetings, Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Han-Wen Nienhuys writes: Architecturally it is very difficult. Rather than making lilypond much more complicated to do incremental rendering, why not invert the problem: have your editor control line breaks, and use lilypond to render just one line of music at a time. This is exactly what Schikkers-List v0.0.3 does, as an obvious and simple extention to the Ikebana prototype. I'm now working on a new data structure which detaches rendering action from the internal music structure. That should enable using different threads in the GUI for managing GUI updates and talking to the lilypond server. Which in turn will enable using parallel lilypond processes to do bits of rendering. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Jan Nieuwenhuizen jann...@gnu.org writes: Han-Wen Nienhuys writes: Architecturally it is very difficult. Rather than making lilypond much more complicated to do incremental rendering, why not invert the problem: have your editor control line breaks, and use lilypond to render just one line of music at a time. This is exactly what Schikkers-List v0.0.3 does, as an obvious and simple extention to the Ikebana prototype. I'm now working on a new data structure which detaches rendering action from the internal music structure. That should enable using different threads in the GUI for managing GUI updates and talking to the lilypond server. Which in turn will enable using parallel lilypond processes to do bits of rendering. I'll point at an old paper of mine here regarding various WYSIWYG techniques in the LaTeX editing world: URL:http://www.tug.org/TUGboat/tb23-1/kastrup.pdf. It would probably be reasonably straightforward to get a preview-latex-like operation for LilyPond-book which certainly would make writing LilyPond documentation quite more pleasant (and shortcut the horrible turnaround times for documentation compiles). In contrast to the original preview-latex problem, LilyPond-book snippets are independent and well-defined (rather than arbitrary document elements). But LilyPond-book is a special case with highlighted, interspersed music snippets. Good for musicological documents and articles about LilyPond, but not a main editor for LilyPond. Since the main problem in that article is to deal with the I can't read this, even though I (probably) can write it aspect of LaTeX which is pretty much the same problem space for LilyPond, it might be useful to go idea-fishing. I think that the mock-up approach used by LyX would usually already make most people happy (page layout control not being required on a permanent basis). At any rate, I think that an efficient workflow should try avoiding the need for more than a single editing window. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Tue, Aug 7, 2012 at 9:52 AM, David Kastrup d...@gnu.org wrote: Since the main problem in that article is to deal with the I can't read this, even though I (probably) can write it aspect of LaTeX which is pretty much the same problem space for LilyPond, it might be useful to go idea-fishing. I think that the mock-up approach used by LyX would usually already make most people happy (page layout control not being required on a permanent basis). At any rate, I think that an efficient workflow should try avoiding the need for more than a single editing window. I agree, at least partly. LyX-like approach of giving a rough-but-human-readable preview - represented by Denemo in Lilypod world - appeals to me strongly. There are only two things that prevent me from using Denemo. First one is lack of source preservation (i.e. Denemo requires Lily files to be organized in a particular way. This means that i cannot structure my source as i wish, and also there are problems with Lily files not made by Denemo). The second problem is tweaking output, for example modifying shape of a slur. It doesn't make sense to do this in the rough preview. I think the best solution to this problem would be to improve point-and-click-based functions of editors like Frescobaldi. Wilbert said that it should be possible to move objects around in Frescobaldi's pdf view: for example, to grab a dynamic like this one http://news.lilynet.net/local/cache-vignettes/L405xH213/flat-dot_figure-13920.png with a mouse, move it in pdf view and have Frescobaldi insert appropriate offset override to the source. Of course, such an override might influence spacing or something, and this influence would be visible only after recompiling. But then, this feature would be used mainly for small touchups. Bottom line: i believe in a threefold editor, consisting of: - source view for setting up the structure and advanced hacking - rough preview for easy note entry - pdf view for final point-and-click touchups. How do you like it? Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Han-Wen Nienhuys hanw...@gmail.com writes: It would be nice if someone from the sibelius team came out and gave some hints about how the .sib format is structured. We could be of help by rescuing the years of work many users have stashed away as .sib files. (I had a brief look at the file format years ago; the problem is that they run some sort of compression scheme over their data) FWIW: Kirill Sidorov wrote a plug-in for Sibelius that exports the current score in some XML format. An additional tool (written in Ruby) postprocesses the XML and produces very useful LilyPond source. I use it often to convert Sibelius scores to LP. Unfortunately, Kirill has had to change priorities but I can share my (slightly enhanced) version of the tools. -- Johan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Johan Vromans jvrom...@squirrel.nl writes: Han-Wen Nienhuys hanw...@gmail.com writes: It would be nice if someone from the sibelius team came out and gave some hints about how the .sib format is structured. We could be of help by rescuing the years of work many users have stashed away as .sib files. (I had a brief look at the file format years ago; the problem is that they run some sort of compression scheme over their data) FWIW: Kirill Sidorov wrote a plug-in for Sibelius that exports the current score in some XML format. An additional tool (written in Ruby) postprocesses the XML and produces very useful LilyPond source. I use it often to convert Sibelius scores to LP. Unfortunately, Kirill has had to change priorities but I can share my (slightly enhanced) version of the tools. That makes my copyright red flags go up. Can you check back with Kirill and possible other authors under which conditions you are allowed to share? We'll likely also have to check the conditions for distributing Sibelius plugins in general to see whether they can be matched to basic free software distribution, in which case pointing at those tools would be fine. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Mon, Aug 6, 2012 at 5:04 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: (I had a brief look at the file format years ago; the problem is that they run some sort of compression scheme over their data) What I'd do in cases like this is: - Create a 'score' with only a middle C1 in it - Same with a C2 - Same with a D1 - Same with a B1 - Other staff symbol - Other key - Look at the binary differences - Play around with the numbers - See if Sib can re-import it after change Then, re-itererate for 2 notes... Takes a long time, but may help. If there are a _lot_ of binary changes between a C1 and a C2, then it's probably some encrypted/compressed format... Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
- Original Message - From: Han-Wen Nienhuys hanw...@gmail.com To: Joseph Rushton Wakeling joseph.wakel...@webdrake.net Cc: m...@apollinemike.com; Lilypond-User lilypond-user@gnu.org Sent: Monday, August 06, 2012 4:04 AM Subject: Re: Sibelius Software UK office shuts down It would be nice if someone from the sibelius team came out and gave some hints about how the .sib format is structured. We could be of help by rescuing the years of work many users have stashed away as .sib files. (I had a brief look at the file format years ago; the problem is that they run some sort of compression scheme over their data) V7 includes MusicXML export, so it's fairly trivial to export a file from Sibelius and import it into another program. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 06/08/12 04:04, Han-Wen Nienhuys wrote: It is easy to see how these events could help lilypond long-term, but it's also easy for any response from us to be interpreted negatively. Let the Sibelius users have their personal moment of pain/mourning; if they need open-source music notation, they will certainly be able to find us without our help. I was not actually thinking primarily of bombarding mourning Sibelius users with publicity, which would clearly be unwelcome (neither piece of software supplies, yet, what Sibelius supplies). Rather, I was thinking of LP and MuseScore approaching educational institutions and possibly also senior former members of Sibelius UK to try and develop something around the combination of (i) the spending that would otherwise have gone on Sibelius licence fees, (ii) the increasing drive for open source software in education, (iii) the drive for computer science education. The opportunity here isn't primarily to get people using some particular piece of software but rather to get people to buy into a new way of funding and developing the cutting edge of music notation technology. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 06/08/12 04:10, Han-Wen Nienhuys wrote: Architecturally it is very difficult. Rather than making lilypond much more complicated to do incremental rendering, why not invert the problem: have your editor control line breaks, and use lilypond to render just one line of music at a time. Why is it not preferable for this to happen internally within Lilypond -- to have Lilypond determine the line and page breaks, store that data in an .aux file or similar, and re-render only individual lines or pages as needed? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
m...@mikesolomon.org wrote: On 5 août 2012, at 12:37, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 02/08/12 17:51, Graham Percival wrote: In short: if there is a concerted effort to create a quick render output, I would be absolutely shocked if it wasn't at least 10 times faster than the current output. (1) How paralellized is the current code -- and if not much or at all, what do you think the scope is for doing so? E.g. once basic pagination is in place, could all other elements be engraved in separate per-page threads? Likewise, any parts of a score separated by an explicit page break could be engraved by separate threads. LilyPond currently only works on a single thread and the code base is definitely not optimized for parallel processing. GCC may do this automatically when compiling LilyPond (I'm not sure how GCC works). There are many places where parallel processing could be implemented in LilyPond - outputting broken lines and pages, as you suggest above, is one of them. (2) Are there any statistics on compile time vs. input file size? It doesn't necessarily help Lilypond to be blazingly fast on a 2-page, 4-part choral score if it's horrendously slow in a 100-page full-orchestra operatic score. I recall that Valentin's opera was a nightmare to render both in terms of time and of memory used along the way. In 2.15 we did some profiling on this a while back and sped this up considerably (there was a bottleneck in the code) but we haven't done any speed-up here since then. I think LilyPond line breaking is O(n log n), although someone more into CS than I would have to confirm this. (3) The real speed issue is not so much from-scratch compile times but recompile times -- how long _should_ it take to re-render the score if e.g. I add a single staccato dot to one note? One idea for LilyPond that has been kicked around for a while is that of .aux files. LaTeX uses these and they help speed up compilation on second passes (they also make it more accurate). The problem is that LilyPond currently has no API - it would take a few months of a few developers time to nail down a core API so that .aux files could be used predictably and without the creation of too many exceptions. This is a high priority of mine but it is a bit too big for me these days and I've got my hands full w/ skyline work :-( Cheers, MS Sibelius' publicity always used to make much of the fact that if Wagner had wanted to add a new bar at the start of the entire Ring Cycle, using Sibelius it would have taken no more than 1 second. That kind of speed-of-tweaking may be worth more than speed of first compile -- ideally, you'd be able to type stuff into the editor in e.g. Frescobaldi, and see the score change in front of your eyes. ___ 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 Just here to post my thoughts: Are there any potential changes to syntax that could speed up rendering, or is the syntax arbitrarily decided and separate to the grunt work? WRT (1): Someone in this thread suggested using individual threads to render a bar at a time. The end result would be messy, but what if one or two threads were dedicated to running 'behind' the main threads to clean up and knit together output? The number of clean-up threads would need to be determined either dynamically during compile or statically before each release comes out depending on projected workloads of each thread with respect to theorised usage scenarios. I reckon, bearing in mind my complete lack of knowledge about the Lilypond back end and programming in general, that even though there'd be a ton of overhead, it'd be worth it - hardly anybody runs single-thread systems nowadays. Bearing in mind, that any threading, in my opinion, should be aimed at providing speed increases to large renders - 20-30s, at least; on shorter renders any speed increases would be hard to notice, whereas in large renders even increases of 5-10% would be huge over the whole process of putting a score into Lilypond. And even having two threads would give much greater boosts than that. -- View this message in context: http://old.nabble.com/Sibelius-Software-UK-office-shuts-down-tp34245636p34260307.html Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 2012-08-06 04:04, Han-Wen Nienhuys wrote: It is worth reminding that by providing high-quality notation tools for free, both Musescore and LilyPond have been a contributing factor in both Sibelius' and Finale (see http://www.makemusic.com/Pressroom/Default.aspx?pid=555) current problems It is easy to see how these events could help lilypond long-term, but it's also easy for any response from us to be interpreted negatively. Let the Sibelius users have their personal moment of pain/mourning; if they need open-source music notation, they will certainly be able to find us without our help. I agree. As with other software, some Sibelius users may feel happier paying inaccessible developers and their managers, directors, shareholders, etc, for closed-source software which stores their work in non-human-readable, undocumented binary formats. The rest can easily find the LilyPond software, website, manuals, snippets and mailing lists. It would be nice if someone from the sibelius team came out and gave some hints about how the .sib format is structured. We could be of help by rescuing the years of work many users have stashed away as .sib files. That may be a while off yet. According to Wikipedia A Facebook pressure group has been formed to protest against the closure of the London office. A website dedicated to encouraging Avid to sell Sibelius to ensure its continued development is now live. The latter claims that Avid intends to offshore further coding work to Ukraine. (I had a brief look at the file format years ago; the problem is that they run some sort of compression scheme over their data) Was the compression recognisable? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
It is easy to see how these events could help lilypond long-term, but it's also easy for any response from us to be interpreted negatively. Let the Sibelius users have their personal moment of pain/mourning; if they need open-source music notation, they will certainly be able to find us without our help. From my perspective, the loss of Sibelius is bad for *everyone* with a stake in music. I never used Sibelius; I never liked it. But many did, and many found their first creative voice through the software. I don't think its retraction will leave a void that will simply be filled by something else. It's a possible sign that music -- the type many of us are involved in -- is losing in the greater culture war. It's not LilyPond vs Sibelius vs Finale but rather Quality Music vs Cheap Entertainment. We're losing. -- Neil Thornock, D.M. The recent premiere of ...and a bunch of other stuff: http://www.youtube.com/watch?v=LQtvPet3k8c Assistant Professor of Music Composition/Theory Brigham Young University ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
George_ wrote: WRT (1): Someone in this thread suggested using individual threads to render a bar at a time. The end result would be messy, but what if one or two threads were dedicated to running 'behind' the main threads to clean up and knit together output? Multithreading works well when there are natural subdivisions of the work. It's really hard to come up with a natural subdivision for Lilypond. Bars are not particularly fundamental to Lilypond music. Bar lines are just another thing that get engraved. Plus, Lilypond does not require that all staves in a system have the same bar structure. Dividing into systems would be convenient, but you don't really know where the next system starts until you're done with the current one. Having done quite a lot of threaded programming, when I think of the job Lilypond is doing, I don't see any natural breakdown. It's a very sequential process. Now, it might be possible to have one thread producing an internal representation of the score -- kind of an intermediate language -- and have another thread sucking on that representation and blowing PDF or EPS or MIDI or whatever. Even that would only be possible if the internal representation did not change fundamentally after it was created. When I see status messages that say, for example fitting music onto 4 or 5 pages, that leads me to believe that there is global optimization going on that might go back and move things on earlier pages. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Tim Roberts t...@probo.com writes: George_ wrote: WRT (1): Someone in this thread suggested using individual threads to render a bar at a time. The end result would be messy, but what if one or two threads were dedicated to running 'behind' the main threads to clean up and knit together output? Multithreading works well when there are natural subdivisions of the work. It's really hard to come up with a natural subdivision for Lilypond. Bars are not particularly fundamental to Lilypond music. Bar lines are just another thing that get engraved. Plus, Lilypond does not require that all staves in a system have the same bar structure. Dividing into systems would be convenient, but you don't really know where the next system starts until you're done with the current one. Uh, no? AFAIK, LilyPond uses linear programming, and that requires combing through a currently active set of optima and generating the next set. That is at its heart a parallel operation. Having done quite a lot of threaded programming, when I think of the job Lilypond is doing, I don't see any natural breakdown. It's a very sequential process. Hm. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Sun, Aug 5, 2012 at 8:10 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: On Thu, Aug 2, 2012 at 1:18 PM, Lucas Gonze lucas.go...@gmail.com wrote: Is it architecturally possible to make a significant amount of overhead go away? Are incremental compiles plausible? Architecturally it is very difficult. Rather than making lilypond much more complicated to do incremental rendering, why not invert the problem: have your editor control line breaks, and use lilypond to render just one line of music at a time. This is an excellent idea. It would also help expose the semantics of the piece to the front end code. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Tim Roberts wrote:
George_ wrote:
WRT (1): Someone in this thread suggested using individual threads to
render
a bar at a time. The end result would be messy, but what if one or two
threads were dedicated to running 'behind' the main threads to clean up
and
knit together output?
Multithreading works well when there are natural subdivisions of the
work. It's really hard to come up with a natural subdivision for
Lilypond. Bars are not particularly fundamental to Lilypond music. Bar
lines are just another thing that get engraved. Plus, Lilypond does not
require that all staves in a system have the same bar structure.
Dividing into systems would be convenient, but you don't really know
where the next system starts until you're done with the current one.
Having done quite a lot of threaded programming, when I think of the job
Lilypond is doing, I don't see any natural breakdown. It's a very
sequential process.
Now, it might be possible to have one thread producing an internal
representation of the score -- kind of an intermediate language -- and
have another thread sucking on that representation and blowing PDF or
EPS or MIDI or whatever. Even that would only be possible if the
internal representation did not change fundamentally after it was
created. When I see status messages that say, for example fitting
music onto 4 or 5 pages, that leads me to believe that there is global
optimization going on that might go back and move things on earlier
pages.
--
Tim Roberts, t...@probo.com
Providenza Boekelheide, Inc.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Well, what if we divide the work using \bookpart {} or \score {}? Each
bookpart is separated by a page break, so it seems unlikely that there would
be cross-dependencies. I don't know how widespread usage of the syntax is,
but this is what I meant when I asked if there were any syntax changes that
could be used to implement multithreading.
--
View this message in context:
http://old.nabble.com/Sibelius-Software-UK-office-shuts-down-tp34245636p34262504.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
David Kastrup d...@gnu.org writes: That makes my copyright red flags go up. Can you check back with Kirill and possible other authors under which conditions you are allowed to share? The plug-in and the postprocessor are both GPL. We'll likely also have to check the conditions for distributing Sibelius plugins in general to see whether they can be matched to basic free software distribution, in which case pointing at those tools would be fine. A Sibelius plug-in is a just script written in a JavaScript/Basic/Pascal-like language. It doesn't contain anything Sibelius-related (e.g. modules, headers, or other code). -- Johan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Mon, Aug 6, 2012 at 4:42 AM, Christ van Willegen cvwille...@gmail.com wrote: On Mon, Aug 6, 2012 at 5:04 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: (I had a brief look at the file format years ago; the problem is that they run some sort of compression scheme over their data) What I'd do in cases like this is: - Create a 'score' with only a middle C1 in it - Same with a C2 - Same with a D1 - Same with a B1 - Other staff symbol - Other key - Look at the binary differences - Play around with the numbers - See if Sib can re-import it after change Then, re-itererate for 2 notes... Takes a long time, but may help. If there are a _lot_ of binary changes between a C1 and a C2, then it's probably some encrypted/compressed format... You can simply run a .sib file through gzip. If it does not compress (and it really doesn't) the file is already compressed. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Mon, Aug 6, 2012 at 2:57 PM, David Kastrup d...@gnu.org wrote: Tim Roberts t...@probo.com writes: George_ wrote: WRT (1): Someone in this thread suggested using individual threads to render a bar at a time. The end result would be messy, but what if one or two threads were dedicated to running 'behind' the main threads to clean up and knit together output? Multithreading works well when there are natural subdivisions of the work. It's really hard to come up with a natural subdivision for Lilypond. Bars are not particularly fundamental to Lilypond music. Bar lines are just another thing that get engraved. Plus, Lilypond does not require that all staves in a system have the same bar structure. Dividing into systems would be convenient, but you don't really know where the next system starts until you're done with the current one. Uh, no? AFAIK, LilyPond uses linear programming, and that requires combing through a currently active set of optima and generating the next set. That is at its heart a parallel operation. The problem is that to get at the input data for linear programming, it has to run a lot of callbacks, many of which have side effects, eg. due to caching. If you do that multithreaded, you have to properly serialize all side-effects, which I think is intractable, since the data structures were never setup to be thread safe. Also, going MT will give you a max 8x speedup (assuming perfect parallelization on an 8 core machine). That is not going to bring down processing costs to interactive rates. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Date: Mon, 6 Aug 2012 07:24:06 -0600 From: Neil Thornock neilthorn...@gmail.com To: han...@xs4all.nl Cc: m...@apollinemike.com m...@apollinemike.com, Lilypond-User lilypond-user@gnu.org Subject: Re: Sibelius Software UK office shuts down Message-ID: caca7e6nnx3wiuiw9jfyiivik_dgomtptayqwt5jlojpaem6...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 It is easy to see how these events could help lilypond long-term, but it's also easy for any response from us to be interpreted negatively. Let the Sibelius users have their personal moment of pain/mourning; if they need open-source music notation, they will certainly be able to find us without our help. From my perspective, the loss of Sibelius is bad for *everyone* with a stake in music. I never used Sibelius; I never liked it. But many did, and many found their first creative voice through the software. I don't think its retraction will leave a void that will simply be filled by something else. It's a possible sign that music -- the type many of us are involved in -- is losing in the greater culture war. It's not LilyPond vs Sibelius vs Finale but rather Quality Music vs Cheap Entertainment. Uncompromising artistic discipline certainly has its pedagogical usefulness, but when Orwellian concepts begin to creep in-- like a vague war apparently dragging on for decades yet with heroes in perpetual danger of defeat-- maybe it's time to come out of the woodshed. We're losing. War is Peace. :) -Jonathan -- Neil Thornock, D.M. The recent premiere of ...and a bunch of other stuff: http://www.youtube.com/watch?v=LQtvPet3k8c Assistant Professor of Music Composition/Theory Brigham Young University -- ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user End of lilypond-user Digest, Vol 117, Issue 20 ** ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 06/08/12 20:26, Han-Wen Nienhuys wrote: Also, going MT will give you a max 8x speedup (assuming perfect parallelization on an 8 core machine). That is not going to bring down processing costs to interactive rates. I think you're focusing on the wrong kind of architecture. _This_ is the kind of setup that you should be aiming to exploit the multithreaded possibilities of: http://www.zdnet.com/boston-virdis-192-core-server-consumes-only-300-watts-of-datacenter-power-701654/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Mon, Aug 6, 2012 at 6:53 PM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 06/08/12 20:26, Han-Wen Nienhuys wrote: Also, going MT will give you a max 8x speedup (assuming perfect parallelization on an 8 core machine). That is not going to bring down processing costs to interactive rates. I think you're focusing on the wrong kind of architecture. I'm talking about the architecture of computers that people can buy in the shops today. While cute, a 192-way ARM server is useless in realistic scenarios. See eg. http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/pt-BR/us/pubs/archive/36448.pdf - aka. Let's use 9 pregnant women, we'd have a baby within the month. Unless you have a embarrassingly parallel problem to begin with (which music typesetting is not), lots of parallelism only buys you synchronization overhead, both lock contention at run-time, and the overhead of having to write race-condition-free parallel code. Note that lilypond is embarassingly parallel at the file level, so for the regression test, we already distribute the files on as many CPUs as we have available. _This_ is the kind of setup that you should be aiming to exploit the multithreaded possibilities of: http://www.zdnet.com/boston-virdis-192-core-server-consumes-only-300-watts-of-datacenter-power-701654/ -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
It's a possible sign that music -- the type many of us are involved in -- is losing in the greater culture war. It's not LilyPond vs Sibelius vs Finale but rather Quality Music vs Cheap Entertainment. Uncompromising artistic discipline certainly has its pedagogical usefulness, but when Orwellian concepts begin to creep in-- like a vague war apparently dragging on for decades yet with heroes in perpetual danger of defeat-- maybe it's time to come out of the woodshed. No, that's not what I mean... Orchestras are going bankrupt, record labels are going out of business, bands have much less chance of making income now than before... Beatles were one of the top iTunes downloads 2 years ago. How is a musician of today with a vision -- of any type -- supposed to make it these days (unless holed up in a woodshed at some university, heaven forbid)? Cheap entertainment is ruining the industry, with streaming, downloading, piracy galore, etc. Unfortunately, the cheap is forced on many musicians now, since the $2 required for quality productions just isn't worth it. Sibelius was good for us. Many of my students came to music because of software like Sibelius. A precious few came to LilyPond because of the music. This opportunism is a bit mis-guided. I think we ought to be fighting to save Sibelius as much as anything. We're losing. War is Peace. :) -Jonathan -- Neil Thornock, D.M. The recent premiere of ...and a bunch of other stuff: http://www.youtube.com/watch?v=LQtvPet3k8c Assistant Professor of Music Composition/Theory Brigham Young University -- ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user End of lilypond-user Digest, Vol 117, Issue 20 ** ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user -- Neil Thornock, D.M. The recent premiere of ...and a bunch of other stuff: http://www.youtube.com/watch?v=LQtvPet3k8c Assistant Professor of Music Composition/Theory Brigham Young University ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Han-Wen Nienhuys-5 wrote: On Mon, Aug 6, 2012 at 6:53 PM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 06/08/12 20:26, Han-Wen Nienhuys wrote: Also, going MT will give you a max 8x speedup (assuming perfect parallelization on an 8 core machine). That is not going to bring down processing costs to interactive rates. I think you're focusing on the wrong kind of architecture. I'm talking about the architecture of computers that people can buy in the shops today. While cute, a 192-way ARM server is useless in realistic scenarios. See eg. http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/pt-BR/us/pubs/archive/36448.pdf - aka. Let's use 9 pregnant women, we'd have a baby within the month. Unless you have a embarrassingly parallel problem to begin with (which music typesetting is not), lots of parallelism only buys you synchronization overhead, both lock contention at run-time, and the overhead of having to write race-condition-free parallel code. Note that lilypond is embarassingly parallel at the file level, so for the regression test, we already distribute the files on as many CPUs as we have available. _This_ is the kind of setup that you should be aiming to exploit the multithreaded possibilities of: http://www.zdnet.com/boston-virdis-192-core-server-consumes-only-300-watts-of-datacenter-power-701654/ -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user The reason this is important is because while IPC goes up incrementally and relatively slowly (IPC has done little more than double between 2005 [P4 660] and now [i7 3930X]) and clock speed is relatively stagnant (it's unlikely we'll ever get 8GHz stock x86 CPUs the way Intel predicted), core count is the only real way to dramatically improve performance - over a similar period, core count has gone up six-fold (in high-end parts), and it's set to continue. I agree, talking about a typesetting program running on a 192-core ARM server is a bit silly, but then, so is saying that an 8-fold increase in speed won't make the process instantaneous, then implying that for this reason we shouldn't look for ways to make it work. -- View this message in context: http://old.nabble.com/Sibelius-Software-UK-office-shuts-down-tp34245636p34264057.html Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Mon, Aug 6, 2012 at 9:56 PM, George_ georgexu...@gmail.com wrote: The reason this is important is because while IPC goes up incrementally and relatively slowly (IPC has done little more than double between 2005 [P4 660] and now [i7 3930X]) and clock speed is relatively stagnant (it's unlikely we'll ever get 8GHz stock x86 CPUs the way Intel predicted), core count is the only real way to dramatically improve performance - over a similar period, core count has gone up six-fold (in high-end parts), and it's set to continue. I agree, talking about a typesetting program running on a 192-core ARM server is a bit silly, but then, so is saying that an 8-fold increase in speed won't make the process instantaneous, then implying that for this reason we shouldn't look for ways to make it work. I'm trying to explain that the constant factor (namely 8-fold) comes at a tremendous cost. Writing multithreaded code without getting stuck in race-conditions and deadlocks is extremely difficult and time consuming, and lilypond already has a shortage of developers without taking on parallelism. In the context of the original remark (making lilypond more suited as a rendering engine), multithreading is simply a stupid way to spend programmer resources. If you're writing a GUI using Lily as a renderer, have the GUI manage the data structures (and possibly, the parallelism), so LilyPond can suffice to stay simple and single-threaded, -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Han-Wen Nienhuys-5 wrote: On Mon, Aug 6, 2012 at 9:56 PM, George_ georgexu...@gmail.com wrote: The reason this is important is because while IPC goes up incrementally and relatively slowly (IPC has done little more than double between 2005 [P4 660] and now [i7 3930X]) and clock speed is relatively stagnant (it's unlikely we'll ever get 8GHz stock x86 CPUs the way Intel predicted), core count is the only real way to dramatically improve performance - over a similar period, core count has gone up six-fold (in high-end parts), and it's set to continue. I agree, talking about a typesetting program running on a 192-core ARM server is a bit silly, but then, so is saying that an 8-fold increase in speed won't make the process instantaneous, then implying that for this reason we shouldn't look for ways to make it work. I'm trying to explain that the constant factor (namely 8-fold) comes at a tremendous cost. Writing multithreaded code without getting stuck in race-conditions and deadlocks is extremely difficult and time consuming, and lilypond already has a shortage of developers without taking on parallelism. In the context of the original remark (making lilypond more suited as a rendering engine), multithreading is simply a stupid way to spend programmer resources. If you're writing a GUI using Lily as a renderer, have the GUI manage the data structures (and possibly, the parallelism), so LilyPond can suffice to stay simple and single-threaded, -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user Where does the GUI come from? -- View this message in context: http://old.nabble.com/Sibelius-Software-UK-office-shuts-down-tp34245636p34264410.html Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Tue, Aug 7, 2012 at 1:50 AM, George_ georgexu...@gmail.com wrote: I'm trying to explain that the constant factor (namely 8-fold) comes at a tremendous cost. Writing multithreaded code without getting stuck in race-conditions and deadlocks is extremely difficult and time consuming, and lilypond already has a shortage of developers without taking on parallelism. In the context of the original remark (making lilypond more suited as a rendering engine), multithreading is simply a stupid way to spend programmer resources. If you're writing a GUI using Lily as a renderer, have the GUI manage the data structures (and possibly, the parallelism), so LilyPond can suffice to stay simple and single-threaded, Where does the GUI come from? See Lucas Gonzo's mail earlier in the thread, -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Han-Wen Nienhuys-5 wrote: On Tue, Aug 7, 2012 at 1:50 AM, George_ georgexu...@gmail.com wrote: I'm trying to explain that the constant factor (namely 8-fold) comes at a tremendous cost. Writing multithreaded code without getting stuck in race-conditions and deadlocks is extremely difficult and time consuming, and lilypond already has a shortage of developers without taking on parallelism. In the context of the original remark (making lilypond more suited as a rendering engine), multithreading is simply a stupid way to spend programmer resources. If you're writing a GUI using Lily as a renderer, have the GUI manage the data structures (and possibly, the parallelism), so LilyPond can suffice to stay simple and single-threaded, Where does the GUI come from? See Lucas Gonzo's mail earlier in the thread, -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user This one here? http://old.nabble.com/Re%3A-Sibelius-Software-UK-office-shuts-down-p34246393.html The reason I ask is, how will such a GUI compare in terms of features, compatibility, and speed, to others already available, as well as to things like LilyPondTool for jEdit? -- View this message in context: http://old.nabble.com/Sibelius-Software-UK-office-shuts-down-tp34245636p34264481.html Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 02/08/12 17:51, Graham Percival wrote: In short: if there is a concerted effort to create a quick render output, I would be absolutely shocked if it wasn't at least 10 times faster than the current output. (1) How paralellized is the current code -- and if not much or at all, what do you think the scope is for doing so? E.g. once basic pagination is in place, could all other elements be engraved in separate per-page threads? Likewise, any parts of a score separated by an explicit page break could be engraved by separate threads. (2) Are there any statistics on compile time vs. input file size? It doesn't necessarily help Lilypond to be blazingly fast on a 2-page, 4-part choral score if it's horrendously slow in a 100-page full-orchestra operatic score. I recall that Valentin's opera was a nightmare to render both in terms of time and of memory used along the way. (3) The real speed issue is not so much from-scratch compile times but recompile times -- how long _should_ it take to re-render the score if e.g. I add a single staccato dot to one note? Sibelius' publicity always used to make much of the fact that if Wagner had wanted to add a new bar at the start of the entire Ring Cycle, using Sibelius it would have taken no more than 1 second. That kind of speed-of-tweaking may be worth more than speed of first compile -- ideally, you'd be able to type stuff into the editor in e.g. Frescobaldi, and see the score change in front of your eyes. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 5 août 2012, at 12:37, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 02/08/12 17:51, Graham Percival wrote: In short: if there is a concerted effort to create a quick render output, I would be absolutely shocked if it wasn't at least 10 times faster than the current output. (1) How paralellized is the current code -- and if not much or at all, what do you think the scope is for doing so? E.g. once basic pagination is in place, could all other elements be engraved in separate per-page threads? Likewise, any parts of a score separated by an explicit page break could be engraved by separate threads. LilyPond currently only works on a single thread and the code base is definitely not optimized for parallel processing. GCC may do this automatically when compiling LilyPond (I'm not sure how GCC works). There are many places where parallel processing could be implemented in LilyPond - outputting broken lines and pages, as you suggest above, is one of them. (2) Are there any statistics on compile time vs. input file size? It doesn't necessarily help Lilypond to be blazingly fast on a 2-page, 4-part choral score if it's horrendously slow in a 100-page full-orchestra operatic score. I recall that Valentin's opera was a nightmare to render both in terms of time and of memory used along the way. In 2.15 we did some profiling on this a while back and sped this up considerably (there was a bottleneck in the code) but we haven't done any speed-up here since then. I think LilyPond line breaking is O(n log n), although someone more into CS than I would have to confirm this. (3) The real speed issue is not so much from-scratch compile times but recompile times -- how long _should_ it take to re-render the score if e.g. I add a single staccato dot to one note? One idea for LilyPond that has been kicked around for a while is that of .aux files. LaTeX uses these and they help speed up compilation on second passes (they also make it more accurate). The problem is that LilyPond currently has no API - it would take a few months of a few developers time to nail down a core API so that .aux files could be used predictably and without the creation of too many exceptions. This is a high priority of mine but it is a bit too big for me these days and I've got my hands full w/ skyline work :-( Cheers, MS Sibelius' publicity always used to make much of the fact that if Wagner had wanted to add a new bar at the start of the entire Ring Cycle, using Sibelius it would have taken no more than 1 second. That kind of speed-of-tweaking may be worth more than speed of first compile -- ideally, you'd be able to type stuff into the editor in e.g. Frescobaldi, and see the score change in front of your eyes. ___ 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
Re: Sibelius Software UK office shuts down
m...@mikesolomon.org m...@mikesolomon.org writes: On 5 août 2012, at 12:37, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 02/08/12 17:51, Graham Percival wrote: In short: if there is a concerted effort to create a quick render output, I would be absolutely shocked if it wasn't at least 10 times faster than the current output. (1) How paralellized is the current code -- and if not much or at all, what do you think the scope is for doing so? E.g. once basic pagination is in place, could all other elements be engraved in separate per-page threads? Likewise, any parts of a score separated by an explicit page break could be engraved by separate threads. LilyPond currently only works on a single thread and the code base is definitely not optimized for parallel processing. What's up with lilypond -djob-count=4 ... ? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Thu, Aug 2, 2012 at 11:02 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 02/08/12 14:49, m...@apollinemike.com wrote: If you guys can get a Google Grant for your LilyPond non-profit in the Netherlands, now would be a fantastic time to run ads on Google getting Sibelius users to check out LilyPond. It's sad that it takes an event like this to generate interest in open source software, but at the same time, it'd be a huge waste of money and time if these people tried to somehow revive Sibelius. If somehow this turn of events resulted in a spike in LilyPond users, that'd be a great boon to the community. To be honest, I think this is a point where Lilypond and MuseScore people ought to get together and plan a collective response. It is worth reminding that by providing high-quality notation tools for free, both Musescore and LilyPond have been a contributing factor in both Sibelius' and Finale (see http://www.makemusic.com/Pressroom/Default.aspx?pid=555) current problems It is easy to see how these events could help lilypond long-term, but it's also easy for any response from us to be interpreted negatively. Let the Sibelius users have their personal moment of pain/mourning; if they need open-source music notation, they will certainly be able to find us without our help. On a practical level, it's likely that many Sibelius users will just not want to switch to a tool like Lilypond -- the whole point of Sibelius is a graphical score editor. MuseScore is a more natural home for them, and is probably the only free tool they'd consider. But at the same time, Sibelius is also about beautiful engraving, so there _are_ some who can surely be attracted by LP; MuseScore doesn't (yet) have a level of beauty equivalent to either Sibelius or Lilypond. It would be nice if someone from the sibelius team came out and gave some hints about how the .sib format is structured. We could be of help by rescuing the years of work many users have stashed away as .sib files. (I had a brief look at the file format years ago; the problem is that they run some sort of compression scheme over their data) -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Thu, Aug 2, 2012 at 1:18 PM, Lucas Gonze lucas.go...@gmail.com wrote: On Thu, Aug 2, 2012 at 8:04 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: More generally than that, I think the reason to discuss is to _discover_ the areas where you can cooperate. There are obvious areas of interaction -- e.g. enabling Lilypond output for MuseScore and ensuring that it gets updated effectively in response to Lilypond syntax changes. I have considered using Lilypond as a back end for front end hacking, but the compile time from .ly to .svg is way too high. Is it architecturally possible to make a significant amount of overhead go away? Are incremental compiles plausible? Architecturally it is very difficult. Rather than making lilypond much more complicated to do incremental rendering, why not invert the problem: have your editor control line breaks, and use lilypond to render just one line of music at a time. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Not so small that you cant do enough money with it. Sib and finale has grown as sequencers and interesting enough for many midi-ists, specially for hobbyists. I am sure a big part of the market of sib (definitely easier than finale and with a big music-library) was not engraving and not so professional. Francois 2012/8/2, Lucas Gonze lucas.go...@gmail.com: The market for music notation tools is very small! That's a major obstacle. On Thu, Aug 2, 2012 at 9:43 AM, Francois Planiol alicuota...@gmail.com wrote: If this is faster (depends, entering notes and lyrics without tuning the output is in lilypond faster) so Sibelius is victim of the same capitalism it serves. No cry. But if Sib-programmers are smart, they would go startup... Francois 2012/8/2, Lucas Gonze lucas.go...@gmail.com: I'm an ex-Sibelius user. Even though I know Lilypond syntax pretty well I still find that it would be much faster to use Sibelius. On Thu, Aug 2, 2012 at 9:27 AM, Francois Planiol alicuota...@gmail.com wrote: I know quite a bunch of of Sibelius users and their argumentation, mostly are writing arrangements or compositions directly in the computer. They just want to click the glyphes on a pentagrama directly. I suppose a part them would not mind if Lily takes the hand over spacing and other decisions, but these would only be conviced with a pentagrama-frontend and a directly accessible midi-playback. They think they have no time to learn a new method of writing music... and want one installer for all the stuff. On the other side, Sibelius will still work a while... Francois 2012/8/2, Lucas Gonze lucas.go...@gmail.com: On Thu, Aug 2, 2012 at 8:04 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: More generally than that, I think the reason to discuss is to _discover_ the areas where you can cooperate. There are obvious areas of interaction -- e.g. enabling Lilypond output for MuseScore and ensuring that it gets updated effectively in response to Lilypond syntax changes. I have considered using Lilypond as a back end for front end hacking, but the compile time from .ly to .svg is way too high. Is it architecturally possible to make a significant amount of overhead go away? Are incremental compiles plausible? ___ 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
Re: Sibelius Software UK office shuts down
As has already been mentioned in this discussion, the UK education market is HUGE. All high schools are pretty much expected to provide access to decent music technology, and Sibelius has a near-universal presence on computers in music classrooms. On 08:24, Fri 03 Aug 2012, Francois Planiol wrote: Date: Fri, 3 Aug 2012 08:24:29 -0500 From: Francois Planiol alicuota...@gmail.com Subject: Re: Sibelius Software UK office shuts down To: Lucas Gonze lucas.go...@gmail.com, lilypond-user@gnu.org List-Id: LilyPond user discussion lilypond-user.gnu.org Not so small that you cant do enough money with it. Sib and finale has grown as sequencers and interesting enough for many midi-ists, specially for hobbyists. I am sure a big part of the market of sib (definitely easier than finale and with a big music-library) was not engraving and not so professional. Francois 2012/8/2, Lucas Gonze lucas.go...@gmail.com: The market for music notation tools is very small! That's a major obstacle. On Thu, Aug 2, 2012 at 9:43 AM, Francois Planiol alicuota...@gmail.com wrote: If this is faster (depends, entering notes and lyrics without tuning the output is in lilypond faster) so Sibelius is victim of the same capitalism it serves. No cry. But if Sib-programmers are smart, they would go startup... Francois 2012/8/2, Lucas Gonze lucas.go...@gmail.com: I'm an ex-Sibelius user. Even though I know Lilypond syntax pretty well I still find that it would be much faster to use Sibelius. On Thu, Aug 2, 2012 at 9:27 AM, Francois Planiol alicuota...@gmail.com wrote: I know quite a bunch of of Sibelius users and their argumentation, mostly are writing arrangements or compositions directly in the computer. They just want to click the glyphes on a pentagrama directly. I suppose a part them would not mind if Lily takes the hand over spacing and other decisions, but these would only be conviced with a pentagrama-frontend and a directly accessible midi-playback. They think they have no time to learn a new method of writing music... and want one installer for all the stuff. On the other side, Sibelius will still work a while... Francois 2012/8/2, Lucas Gonze lucas.go...@gmail.com: On Thu, Aug 2, 2012 at 8:04 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: More generally than that, I think the reason to discuss is to _discover_ the areas where you can cooperate. There are obvious areas of interaction -- e.g. enabling Lilypond output for MuseScore and ensuring that it gets updated effectively in response to Lilypond syntax changes. I have considered using Lilypond as a back end for front end hacking, but the compile time from .ly to .svg is way too high. Is it architecturally possible to make a significant amount of overhead go away? Are incremental compiles plausible? ___ 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 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 2 août 2012, at 16:14, Graham Percival wrote: On Thu, Aug 02, 2012 at 03:02:34PM +0100, Joseph Rushton Wakeling wrote: On 02/08/12 14:49, m...@apollinemike.com wrote: If you guys can get a Google Grant for your LilyPond non-profit in the Netherlands, now would be a fantastic time to run ads on Google getting Sibelius users to check out LilyPond. It's sad that it takes an event like this to generate interest in open source software, but at the same time, it'd be a huge waste of money and time if these people tried to somehow revive Sibelius. Wouldn't a google grant be better put towards making lilypond better? Like, having a stable release or fixing graphical collisions? Google Grants are only good for advertising on Google - they don't give the money directly, but they give credit for Google Ads. Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 2 août 2012, at 16:02, Joseph Rushton Wakeling wrote: On 02/08/12 14:49, m...@apollinemike.com wrote: If you guys can get a Google Grant for your LilyPond non-profit in the Netherlands, now would be a fantastic time to run ads on Google getting Sibelius users to check out LilyPond. It's sad that it takes an event like this to generate interest in open source software, but at the same time, it'd be a huge waste of money and time if these people tried to somehow revive Sibelius. If somehow this turn of events resulted in a spike in LilyPond users, that'd be a great boon to the community. To be honest, I think this is a point where Lilypond and MuseScore people ought to get together and plan a collective response. On a practical level, it's likely that many Sibelius users will just not want to switch to a tool like Lilypond -- the whole point of Sibelius is a graphical score editor. It'd be great if someone who knows Sibelius created a from Sibelius to LilyPond in 10 easy steps type article where they walked through the creation of a simple score in both programs. I am convinced that the majority of those who use a graphic interface don't actually do it because they have some sort of intrinsic preference but rather because they are not used to other alternatives. It took the lower half of my screen breaking for me to abandon Finale and start using LilyPond, so I know how much one's way of working can change based on the possibilities that are available to them. It may also be worth it to contact Avid. As crazy as this sounds, they may actually appreciate LilyPond stepping in and saying Hey, we have a great piece of software that we're proud of that will spare you a lot of headaches in terms of support and complaining. I'll look into it... Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 02/08/12 15:14, Graham Percival wrote: Well, they have the email address of our development mailing list. ... and presumably you have theirs. Why not be the ones to initiate the discussion? I've heard this work together more idea a few times, but I have no clue what that would entail. What could LilyPond do to make GUI front-ends easier to write, better for users, etc? At _this point_, I think the best thing to do would simply be to say, Let's talk about ways in which we can cooperate to promote free software for music and reach out to the abandoned Sibelius community. More generally than that, I think the reason to discuss is to _discover_ the areas where you can cooperate. There are obvious areas of interaction -- e.g. enabling Lilypond output for MuseScore and ensuring that it gets updated effectively in response to Lilypond syntax changes. But you won't know until you start talking what the real points of shared interest could be. Friendly social context, both online and preferably also offline, is unlikely to be anything other than stimulating. Even if no actual development overlap takes place, there are still other potential areas of cooperation -- infrastructure, project management, fundraising, organizing events and demonstrations -- to make it worthwhile. What else could we do to work together? (be it with musescore, denemo, laborejo, elysium, etc) Start the conversation first, based around a shared interest in providing high-quality free software for music notation. Then you'll find out. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 02/08/12 15:26, m...@apollinemike.com wrote: It may also be worth it to contact Avid. As crazy as this sounds, they may actually appreciate LilyPond stepping in and saying Hey, we have a great piece of software that we're proud of that will spare you a lot of headaches in terms of support and complaining. I'll look into it... What did you have in mind here? As far as I can see, Avid's goal is simply to maximize the amount of Sibelius' revenues that go straight into company coffers. They are still going to want to try and maintain purchases and use of Sibelius, they just don't want to spend the money on an expensive expert development team. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
What else could we do to work together? (be it with musescore, denemo, laborejo, elysium, etc) - Graham For my part: nothing. Laborejo is created for Lilypond, not just a notation tool with an exporter. I can adapt to any Lilypond changes very fast and Laborejo users, in the future because there are none currently, do not need to worry as well. So working together is not needed for my development model. Once Laborejo is in a stable state I am going to ask for a Link in the easier editing section. Everything else will come either automatically because I will have created a good software or it will not and then it is justified. Nils ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 02/08/12 16:04, Joseph Rushton Wakeling wrote: Even if no actual development overlap takes place, there are still other potential areas of cooperation -- infrastructure, project management, fundraising, organizing events and demonstrations -- to make it worthwhile. Just to give some background to this remark: * Sibelius is very widely used across British schools and music colleges. That's a substantial amount of money being spent by these institutions on music notation software; it made sense in many ways, as Sibelius was a prime example of British innovation and they were helping to support both British jobs and an important British brand. Now, that's clearly no longer the case and they are unlikely to be happy if their software of choice is no longer being adequately supported. In principle, that money could be redirected towards the development of free software that they can rely on not to be undermined by a cynical owner. * At the same time, the last year has seen a growing stress on computer science in schools. This is greatly centred around encouraging engagement with open source software -- see e.g. the Raspberry Pi, and the Next Gen report on ICT in British education: http://www.raspberrypi.org/ http://www.nesta.org.uk/publications/assets/features/next_gen * Both MuseScore and Lilypond can be positioned in this educational context and can use it as a source of both engagement and development funding. I stress these two software packages for a simple reason: so far as I can see, MuseScore is the most sophisticated WYSIWYG score editor out there, and Lilypond is easily the most advanced in terms of musical sophistication and notational beauty. They also seem to me to have the healthiest development and user communities. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Thu, Aug 2, 2012 at 5:15 PM, Nils l...@nilsgey.de wrote: What else could we do to work together? (be it with musescore, denemo, laborejo, elysium, etc) - Graham For my part: nothing. Laborejo is created for Lilypond, not just a notation tool with an exporter. I can adapt to any Lilypond changes very fast and Laborejo users, in the future because there are none currently, do not need to worry as well. So working together is not needed for my development model. Once Laborejo is in a stable state I am going to ask for a Link in the easier editing section. Everything else will come either automatically because I will have created a good software or it will not and then it is justified. Nils ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user There was a discussion similar in the FInale forums some days ago, as some investor has offered to but makemusic. One of the comments was roughly I would prefer to write by hand than to use Lilypond... On the bright side, at my uni we decided to do all our publications in Lilypond after I demonstrated how a finale project could be migrated using musicxml - and have it typeset really better with just two clicks. Rodolfo ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Thu, Aug 2, 2012 at 8:04 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: More generally than that, I think the reason to discuss is to _discover_ the areas where you can cooperate. There are obvious areas of interaction -- e.g. enabling Lilypond output for MuseScore and ensuring that it gets updated effectively in response to Lilypond syntax changes. I have considered using Lilypond as a back end for front end hacking, but the compile time from .ly to .svg is way too high. Is it architecturally possible to make a significant amount of overhead go away? Are incremental compiles plausible? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On 2 août 2012, at 18:18, Lucas Gonze wrote: On Thu, Aug 2, 2012 at 8:04 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: More generally than that, I think the reason to discuss is to _discover_ the areas where you can cooperate. There are obvious areas of interaction -- e.g. enabling Lilypond output for MuseScore and ensuring that it gets updated effectively in response to Lilypond syntax changes. I have considered using Lilypond as a back end for front end hacking, but the compile time from .ly to .svg is way too high. Is it architecturally possible to make a significant amount of overhead go away? Are incremental compiles plausible? It is very difficult. It's better to use a front-end editor that shows some sorta mock-up of the score and that only compiles the nice LilyPond version from time to time (if this exists). Getting an actual LilyPond score requires calculating line breaks and there's no way to get rid of the overhead. That said, we optimize all the time: I believe that for larger scores w/ many staves, the current development version is faster than 2.14. As for the svg, significant improvement can be made in the speed of LilyPond's svg export - contributions are certainly welcome in this area. The backend is very well written but it is all in Scheme and can be quite slow as it does not make reference to an external font file but rather draws out every glyph. Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Thu, Aug 2, 2012 at 9:22 AM, m...@apollinemike.com m...@apollinemike.com wrote: It is very difficult. It's better to use a front-end editor that shows some sorta mock-up of the score and that only compiles the nice LilyPond version from time to time (if this exists). Getting an actual LilyPond score requires calculating line breaks and there's no way to get rid of the overhead. That said, we optimize all the time: I believe that for larger scores w/ many staves, the current development version is faster than 2.14. As for the svg, significant improvement can be made in the speed of LilyPond's svg export - contributions are certainly welcome in this area. The backend is very well written but it is all in Scheme and can be quite slow as it does not make reference to an external font file but rather draws out every glyph. It wouldn't make sense to have completely separate codebases for quick-and-dirty and slow-and-pretty. IMO this is the blocker. Lilypond's C could be converted to Javascript using Emscripten. Is there any hope of that working with the Scheme? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
On Thu, Aug 02, 2012 at 06:22:49PM +0200, m...@apollinemike.com wrote: On 2 août 2012, at 18:18, Lucas Gonze wrote: Is it architecturally possible to make a significant amount of overhead go away? Are incremental compiles plausible? It is very difficult. It's better to use a front-end editor that shows some sorta mock-up of the score and that only compiles the nice LilyPond version from time to time (if this exists). Getting an actual LilyPond score requires calculating line breaks and there's no way to get rid of the overhead. Sure there is. Compile each bar individually with the default spacing (i.e. whatever you get if your entire score is one bar and you use ragged-right=##t). The concatenate bars until the sum is larger than the allowable line-width, at which point you put the bar on the next line. It'll be completely ugly (ragged score lines? even finale doesn't do that!), but it eliminates the overhead of line breaks. Then the question is what trade-offs of speed for beauty you want to make. I mean, a slightly less invasive/drastic speed-up would be to have the user hard-code 4 bars per line. That's also ugly, but not as bad as the previous option. In short: if there is a concerted effort to create a quick render output, I would be absolutely shocked if it wasn't at least 10 times faster than the current output. Kill line breaks, draw slurs as rectangles, place noteheads on a strict timing grid instead of optical spacing... there's a lot of beautiful things that lilypond does which uses CPU resources. As for the svg, significant improvement can be made in the speed of LilyPond's svg export - contributions are certainly welcome in this area. The backend is very well written but it is all in Scheme The compiled scheme in guile 2.0 could help here. So if anybody feels like picking up the porting-to-guile2.0 work... - Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sibelius Software UK office shuts down
Lucas Gonze lucas.go...@gmail.com writes: On Thu, Aug 2, 2012 at 9:22 AM, m...@apollinemike.com m...@apollinemike.com wrote: It is very difficult. It's better to use a front-end editor that shows some sorta mock-up of the score and that only compiles the nice LilyPond version from time to time (if this exists). Getting an actual LilyPond score requires calculating line breaks and there's no way to get rid of the overhead. That said, we optimize all the time: I believe that for larger scores w/ many staves, the current development version is faster than 2.14. As for the svg, significant improvement can be made in the speed of LilyPond's svg export - contributions are certainly welcome in this area. The backend is very well written but it is all in Scheme and can be quite slow as it does not make reference to an external font file but rather draws out every glyph. It wouldn't make sense to have completely separate codebases for quick-and-dirty and slow-and-pretty. It is what LyX does with regard to LaTeX typesetting. The counterthesis, in a way, is TeXmacs, but it does not use TeX for typesetting, it only employs its algorithms. IMO this is the blocker. It is quite hard to turn a whole program into something matching the requirements of a GUI workflow. The mockup route will certainly deliver results quite faster. It is conceivable to combine it with a lazy update/preview scheme running in the background, but for interactive response you'll want something faster. Lilypond's C could be converted to Javascript using Emscripten. Is there any hope of that working with the Scheme? That reminds me of a man bringing a fried chicken to the vet and asking whether there is anything he can do. No, LilyPond C++ is not idiomatic C but a rather low-level intertwinement with Scheme. It is not really susceptible to machine translation by other paths. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
