Re: An idea for a systematic development of a large score.
Am 24.05.2013 23:17, schrieb Sarah k Alawami:
Ok. yeah I'm trying to create a lot less work for my self especially now
because if I get this job out of town I will be gone for 3 months and I want to
do this as a gift.
The variables and the systems idea will I think make it easier. why o why did
I not do this with the last assignment? lol! Ah well. I'm learning slowly and
this project I think will teach me a lot. lol!
thanks all. time to get cracking.
On May 24, 2013, at 12:11 PM, Wim van Dommelen m...@wimvd.nl wrote:
On 24 May 2013, at 03:21 , Sarah k Alawami wrote:
Actually I was thinking the variables for the piano since one of the sections
repeats a lot in the right hand. Will all of that still compile if I have the
files's variables like that or do I need to then create a veritable for the
foe itself?
Whatever makes it easier for you to write/read. You can have more variables in
one file or have a file (with all the variables in it) included in another
file, or have one variable used inside another one, for example
Sarah,
maybe one thought to memorize really thoroughly for this topic:
If you \include another file LilyPond will simply insert the content of
the included file at that place.
So if you have four variables in four files or one file doesn't make a
difference. The only thing that matters is the order in which you
include the files.
HTH
Urs
one = \relative c' { c4 d e c }
two = \relative c' { e4 f g2 }
three = \relative c' { g'8 a g f e4 c }
four = \relative c' { c4 g c2 }
piano = { \time 4/4 \one \one \two \two \three \three \four \four }
\score
{
\new Staff
\piano
}
etc. The important thing is to make easy understandable, but the big
advantage is to be able to do some of the parts, get these OK and build on it.
Regards,
Wim.
___
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: An idea for a systematic development of a large score.
On Fri, May 24, 2013 at 8:59 PM, Wim van Dommelen m...@wimvd.nl wrote: Sorry, hobo is just the Dutch name for oboe. typo Well, as long as you don't use the Dutch name fagot for bassoon... Christ van Willegen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
Christ van Willegen cvwille...@gmail.com writes: On Fri, May 24, 2013 at 8:59 PM, Wim van Dommelen m...@wimvd.nl wrote: Sorry, hobo is just the Dutch name for oboe. typo Well, as long as you don't use the Dutch name fagot for bassoon... An uncle of mine, not remembering the word for journey, once famously waved some American relatives goodbye using the words Have a good Fahrt!. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
Am 26.05.2013 15:12, schrieb David Kastrup: Christ van Willegen cvwille...@gmail.com writes: On Fri, May 24, 2013 at 8:59 PM, Wim van Dommelen m...@wimvd.nl wrote: Sorry, hobo is just the Dutch name for oboe. typo Well, as long as you don't use the Dutch name fagot for bassoon... An uncle of mine, not remembering the word for journey, once famously waved some American relatives goodbye using the words Have a good Fahrt!. When my son was 2 1/2 he was already an enthusiastic soccer player. Once he kicked too hard and sat on his bottom. His thrilled comment: Boah, jetzt bin ich umgefallen, weil ich so stark geschissen habe (sorry, untranslatable ...) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
on 2013-05-26 at 15:49 Urs Liska wrote: When my son was 2 1/2 he was already an enthusiastic soccer player. Once he kicked too hard and sat on his bottom. His thrilled comment: Boah, jetzt bin ich umgefallen, weil ich so stark geschissen habe (sorry, untranslatable ...) what can i say, if he manages to keep his talents when he grows up, he'll be one of the world's greatest comedians... (although perhaps not one the greatest football players...) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
luis jure l...@internet.com.uy schrieb: on 2013-05-26 at 15:49 Urs Liska wrote: When my son was 2 1/2 he was already an enthusiastic soccer player. Once he kicked too hard and sat on his bottom. His thrilled comment: Boah, jetzt bin ich umgefallen, weil ich so stark geschissen habe (sorry, untranslatable ...) what can i say, if he manages to keep his talents when he grows up, he'll be one of the world's greatest comedians... (although perhaps not one the greatest football players...) Too sad. I'm sure he'd prefer the latter if you asked him ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
Sorry, hobo is just the Dutch name for oboe. typo Regards, Wim. On 24 May 2013, at 00:51 , David Kastrup wrote: Wim van Dommelen m...@wimvd.nl writes: Yes, that is possible if I understand correctly what you want to do. For example you can make a set of files: - clarinet-1.ly, contains the variable with the notes and everything for clarinet 1 - hobo.ly, the variable with the notes for the hobo, etc. Is that a singer? Or is there indeed a language where this spelling is used for the instrument otherwise known as hautboy or oboe? -- David Kastrup ___ 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: An idea for a systematic development of a large score.
On 24 May 2013, at 03:21 , Sarah k Alawami wrote:
Actually I was thinking the variables for the piano since one of the
sections repeats a lot in the right hand. Will all of that still
compile if I have the files's variables like that or do I need to
then create a veritable for the foe itself?
Whatever makes it easier for you to write/read. You can have more
variables in one file or have a file (with all the variables in it)
included in another file, or have one variable used inside another
one, for example
one = \relative c' { c4 d e c }
two = \relative c' { e4 f g2 }
three = \relative c' { g'8 a g f e4 c }
four = \relative c' { c4 g c2 }
piano = { \time 4/4 \one \one \two \two \three \three \four \four }
\score
{
\new Staff
\piano
}
etc. The important thing is to make easy understandable, but the
big advantage is to be able to do some of the parts, get these OK and
build on it.
Regards,
Wim.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
Ok. yeah I'm trying to create a lot less work for my self especially now
because if I get this job out of town I will be gone for 3 months and I want to
do this as a gift.
The variables and the systems idea will I think make it easier. why o why did
I not do this with the last assignment? lol! Ah well. I'm learning slowly and
this project I think will teach me a lot. lol!
thanks all. time to get cracking.
On May 24, 2013, at 12:11 PM, Wim van Dommelen m...@wimvd.nl wrote:
On 24 May 2013, at 03:21 , Sarah k Alawami wrote:
Actually I was thinking the variables for the piano since one of the
sections repeats a lot in the right hand. Will all of that still compile if
I have the files's variables like that or do I need to then create a
veritable for the foe itself?
Whatever makes it easier for you to write/read. You can have more variables
in one file or have a file (with all the variables in it) included in another
file, or have one variable used inside another one, for example
one = \relative c' { c4 d e c }
two = \relative c' { e4 f g2 }
three = \relative c' { g'8 a g f e4 c }
four = \relative c' { c4 g c2 }
piano = { \time 4/4 \one \one \two \two \three \three \four \four }
\score
{
\new Staff
\piano
}
etc. The important thing is to make easy understandable, but the big
advantage is to be able to do some of the parts, get these OK and build on it.
Regards,
Wim.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
I was thinking of putting my variables in each file that way I can do a bit less less typing, at least in that file. will this still work in the end when I compile all files in to one score and parts for the choir and me and the pianist? Well, I won't need the score, how ever the person conducting it might. *smiles* Take care all. On May 21, 2013, at 1:17 PM, Ian Hulin i...@hulin.org.uk wrote: Hi wjm and list, On 17/05/13 02:26, wjm wrote: Greetings! After watching Sarah K Alawami's work on a score recently on this user-list, but not having the musical and compositional skills to make constructive remarks, and after reading the thread entitled 'stylesheet structure', it occurred to me that an approach might be found which might make the whole process a little less opaque. snip Here is a pointer to some of the templates referenced in the Learning Manual as Appendix A5: (development version documentation) http://www.lilypond.org/doc/v2.17/Documentation/learning/orchestral-templates (stable version documentation) http://www.lilypond.org/doc/v2.16/Documentation/learning/orchestral-templates If you want to invest a bit more time, there are a couple of packages which allow you to set up large score if you invest a bit of time in the learning curve, both of which I have used. One is Reinhold Kainhofer's orchestrallily, which is at http://reinhold.kainhofer.com/orchestrallily/index.html#The-Orchestrallily-Package There is a pointer to download the file at that address. Once downloaded, you may need to run it through convert-ly if running a version of LilyPond after V2.14. Reinhold has had to bow out of actively participating in the LilyPond lists, but I'm sure he'd be OK answering any queries from people using the package. The other possibility is Mark Witmer's ly-score package at github - see www.github/mwitmer/LyUtil#readme. Hope this is useful. Cheers, Ian Hulin ___ 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: An idea for a systematic development of a large score.
Hi Sarah, On 23 May 2013, at 19:46 , Sarah k Alawami wrote: I was thinking of putting my variables in each file each variable only *once* in a file, I presume that way I can do a bit less less typing, at least in that file. will this still work in the end when I compile all files in to one score and parts for the choir and me and the pianist? Well, I won't need the score, how ever the person conducting it might. *smiles* Yes, that is possible if I understand correctly what you want to do. For example you can make a set of files: - clarinet-1.ly, contains the variable with the notes and everything for clarinet 1 - clarinet-2.ly, contains the variable with the notes and everything for clarinet 2 - clarinet-part.ly, contains only the structure for the clarinets, includes the clarinet 1 and 2 files (so NO extra typing) and produces print and midi for it, so you can check and correct simply those parts. - hobo.ly, the variable with the notes for the hobo, etc. - piano.ly, similar for the piano, etc. - total-score.ly, uses all of the other include-files, ahs the structure of the ensemble and produces the total for the conductor Etc. Regards, Wim. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
Wim van Dommelen m...@wimvd.nl writes: Yes, that is possible if I understand correctly what you want to do. For example you can make a set of files: - clarinet-1.ly, contains the variable with the notes and everything for clarinet 1 - hobo.ly, the variable with the notes for the hobo, etc. Is that a singer? Or is there indeed a language where this spelling is used for the instrument otherwise known as hautboy or oboe? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
Actually I was thinking the variables for the piano since one of the sections repeats a lot in the right hand. Will all of that still compile if I have the files's variables like that or do I need to then create a veritable for the foe itself? On May 23, 2013, at 3:31 PM, Wim van Dommelen m...@wimvd.nl wrote: Hi Sarah, On 23 May 2013, at 19:46 , Sarah k Alawami wrote: I was thinking of putting my variables in each file each variable only *once* in a file, I presume that way I can do a bit less less typing, at least in that file. will this still work in the end when I compile all files in to one score and parts for the choir and me and the pianist? Well, I won't need the score, how ever the person conducting it might. *smiles* Yes, that is possible if I understand correctly what you want to do. For example you can make a set of files: - clarinet-1.ly, contains the variable with the notes and everything for clarinet 1 - clarinet-2.ly, contains the variable with the notes and everything for clarinet 2 - clarinet-part.ly, contains only the structure for the clarinets, includes the clarinet 1 and 2 files (so NO extra typing) and produces print and midi for it, so you can check and correct simply those parts. - hobo.ly, the variable with the notes for the hobo, etc. - piano.ly, similar for the piano, etc. - total-score.ly, uses all of the other include-files, ahs the structure of the ensemble and produces the total for the conductor Etc. Regards, Wim. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
Hi wjm and list, On 17/05/13 02:26, wjm wrote: Greetings! After watching Sarah K Alawami's work on a score recently on this user-list, but not having the musical and compositional skills to make constructive remarks, and after reading the thread entitled 'stylesheet structure', it occurred to me that an approach might be found which might make the whole process a little less opaque. snip Here is a pointer to some of the templates referenced in the Learning Manual as Appendix A5: (development version documentation) http://www.lilypond.org/doc/v2.17/Documentation/learning/orchestral-templates (stable version documentation) http://www.lilypond.org/doc/v2.16/Documentation/learning/orchestral-templates If you want to invest a bit more time, there are a couple of packages which allow you to set up large score if you invest a bit of time in the learning curve, both of which I have used. One is Reinhold Kainhofer's orchestrallily, which is at http://reinhold.kainhofer.com/orchestrallily/index.html#The-Orchestrallily-Package There is a pointer to download the file at that address. Once downloaded, you may need to run it through convert-ly if running a version of LilyPond after V2.14. Reinhold has had to bow out of actively participating in the LilyPond lists, but I'm sure he'd be OK answering any queries from people using the package. The other possibility is Mark Witmer's ly-score package at github - see www.github/mwitmer/LyUtil#readme. Hope this is useful. Cheers, Ian Hulin ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
I think this whole thread is very useful. Thanks for initiating it! And I totally agree about the value of this list for learners (and others). Of the many I subscribe to, it's always been the best, by quite a margin. t. On 05/17/2013 07:58 PM, wjm wrote: A bit of my LP background - - - Several years ago I was asked by a local church-choir director to prepare a couple of pieces for use by other church-groups. He knew that I had used computers for preparing teaching and publication graphics of one sort or another, and that I had done a little music 'engraving' using an early version of Finale. When he suggested this project I reviewed my use of, and degree of familiarity with, Finale and decided that there should be another option, which eventually led me to Lilypond. All of the use I've made of LP since has been transcribing from mainly hand-written scores of unison or SATB choral works. The first few years were an uphill struggle, notwithstanding the existence of the Tutorial and Notation Reference manuals, and a really useful resource has been the User-list :) . Making use of templates and other completed LP files, and adapting snippets etc., made my experience a lot less 'rocky' than it might otherwise have been. I make no apology for making use of the vast experience of subscribers to this list and am grateful that so many have provided solutions to problems I've encountered from time to time. It was with this in the back of my mind that I offered the 'schema' in my earlier post in the hope that it would make life a little easier for other users, particularly those who, like me, regard themselves as 'new users'. :) Thanks to all, Regards, Bill ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user -- ~~ Tom Cloyd, MS MA Cedar City / St. George, Utah, U.S.A: (435) 272-3332 t...@tomcloyd.com (email) TomCloyd.com (website) Sleightmind.com (mental health issues weblog) ~~ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
Greetings Jan, You wrote:- +++ After a lot of fiddling around I came up with this schema:- That reads much like http://git.savannah.gnu.org/cgit/lilypond.git/tree/mutopia/Coriolan?id=60fdc53305e8628dad96b4ebea177bc6ee8d95cd what are we missing? +++ I hadn't been there... and I guess what I've done might be seen as reinventing the wheel, but..., I would like to think, after having had a brief look at your link and its content, that what I've outlined doesn't require further knowledge of such things as 'makefiles', etc., which novice LP users might find somewhat off-putting. Further than that I can't comment, since my understanding of makefiles is zero! :) Thanks for your feedback, Regards Bill ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
I do all of my composing in Lilypond, and have completed numerous large ensemble projects of significant length. I'd estimate I've written around 20,000 lines of Lilypond and Scheme code in the last two years. My preferred file structure continues to evolve, but it is basically the following: Project folder: * project_score.ly * project_parts.ly * project.ly * project_lib.ily /home/me/.lily/: * macros.ily * orchestral_style.ily * macros/ It's pretty self-explanatory. I include \version and \language in every Lilypond file, without exception. I define all of my music variables in project.ly, including global. I prefer this to having a file for each instrument, because it makes keeping track of versions easier; I suppose if I used a version management system, that wouldn't be a problem, but at the moment I just put ascending numbers at the end of the file name :p. I use a standardized naming convention for variable names, quote names, and context names. I always define \global first, then I go in score order, say \fluteI, \fluteII, etc. I do not use music variables for motives or themes: I explicitly write all of my music from beginning to end, and I use \transpose and \transposition to write all instruments in concert pitch. At the end of project.ly, I \addQuote for \fluteI, \fluteII, all the way through the variables in score order. That allows me to use \cueDuring when I make instrumental parts. I make copious use of \tag and \removeWithTag, for example to include enharmonic key changes in transposing parts, for overrides that are only to be used in score or in parts, and to exclude nested contexts like chord symbols or divisi staves from \addQuote. In larger projects, editing project.ly can get cumbersome if each variable is 1,000 lines long; suppose I want to change a note in measure 67 in \fluteII and \violinI? To make editing easier, I break the variables up into \fluteIsectionA, \fluteIsectionB, etc. The project.ly file then starts with all of the sectionA variables in score order, then all the sectionB variables in score order, etc. In such projects, I use an additional file called project_form.ly, which \include's project.ly, and which defines the variables \fluteI, \fluteII, etc., using the sectional variables. I wouldn't recommend using this kind of scheme except in very large projects, because things get hairy when one instrument has a crescendo over the break between sections. It is better to write all of the music for each instrument in a single variable. I use \bookpart to keep the \score expressions for all of my instrumental parts in one file. This also has the advantage that I get a single PDF of all of the parts. I begin this file with a global \layout block, which allows me to easily apply overrides to all the parts at once. I have a multi-layered system for reusing snippets and style information. The most basic level is, of course, overrides in the project.ly, project_score.ly, or project_parts.ly files. The next layer is the project_lib.ily file, which includes the \header block for the project, the title and front-matter markup, a \layout block of project-specific but project-wide overrides, and any snippets or macros that I only want to use in this project. When I use a snippet from LSR for the first time, I almost always copy and paste it into a project_lib.ily file. Macros that I frequently redefine for different projects, like \mute (will it be mute or senza?) also go in project_lib.ily. Anything that I want to reuse between projects goes in the .lily folder, which I have added to my Lilypond path. macros.ily includes short snippets and miscellaneous macros, such as common \once\override's and a list of common markup expressions. It also \include's all of the files in the .lily/macros folder. The files in the macros folder are longer snippets or collections of snippets related to a common task, such as jazz notation. The other files in .lily are stylesheet files like orchestral_style.ily or chamber_style.ily, which contain \layout blocks with most of the overrides I use, custom contexts, etc. I am fairly conservative about adding or removing things from my stylesheets, since they each apply to many projects. Instead, I can contradict the stylesheet with overrides in project_lib.ily, as long as I \include project_lib.ily after I \include orchestral_style.ily. -- View this message in context: http://lilypond.1069038.n5.nabble.com/An-idea-for-a-systematic-development-of-a-large-score-tp146017p146032.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
I guess you all have looked at the scores by Nicolas Sceaux at http://nicolas.sceaux.free.fr/ already? They are very well structured. On 17 May 2013 09:18, Shevek s...@saultobin.com wrote: I do all of my composing in Lilypond, and have completed numerous large ensemble projects of significant length. I'd estimate I've written around 20,000 lines of Lilypond and Scheme code in the last two years. My preferred file structure continues to evolve, but it is basically the following: Project folder: * project_score.ly * project_parts.ly * project.ly * project_lib.ily /home/me/.lily/: * macros.ily * orchestral_style.ily * macros/ It's pretty self-explanatory. I include \version and \language in every Lilypond file, without exception. I define all of my music variables in project.ly, including global. I prefer this to having a file for each instrument, because it makes keeping track of versions easier; I suppose if I used a version management system, that wouldn't be a problem, but at the moment I just put ascending numbers at the end of the file name :p. I use a standardized naming convention for variable names, quote names, and context names. I always define \global first, then I go in score order, say \fluteI, \fluteII, etc. I do not use music variables for motives or themes: I explicitly write all of my music from beginning to end, and I use \transpose and \transposition to write all instruments in concert pitch. At the end of project.ly, I \addQuote for \fluteI, \fluteII, all the way through the variables in score order. That allows me to use \cueDuring when I make instrumental parts. I make copious use of \tag and \removeWithTag, for example to include enharmonic key changes in transposing parts, for overrides that are only to be used in score or in parts, and to exclude nested contexts like chord symbols or divisi staves from \addQuote. In larger projects, editing project.ly can get cumbersome if each variable is 1,000 lines long; suppose I want to change a note in measure 67 in \fluteII and \violinI? To make editing easier, I break the variables up into \fluteIsectionA, \fluteIsectionB, etc. The project.ly file then starts with all of the sectionA variables in score order, then all the sectionB variables in score order, etc. In such projects, I use an additional file called project_form.ly, which \include's project.ly, and which defines the variables \fluteI, \fluteII, etc., using the sectional variables. I wouldn't recommend using this kind of scheme except in very large projects, because things get hairy when one instrument has a crescendo over the break between sections. It is better to write all of the music for each instrument in a single variable. I use \bookpart to keep the \score expressions for all of my instrumental parts in one file. This also has the advantage that I get a single PDF of all of the parts. I begin this file with a global \layout block, which allows me to easily apply overrides to all the parts at once. I have a multi-layered system for reusing snippets and style information. The most basic level is, of course, overrides in the project.ly, project_score.ly, or project_parts.ly files. The next layer is the project_lib.ily file, which includes the \header block for the project, the title and front-matter markup, a \layout block of project-specific but project-wide overrides, and any snippets or macros that I only want to use in this project. When I use a snippet from LSR for the first time, I almost always copy and paste it into a project_lib.ily file. Macros that I frequently redefine for different projects, like \mute (will it be mute or senza?) also go in project_lib.ily. Anything that I want to reuse between projects goes in the .lily folder, which I have added to my Lilypond path. macros.ily includes short snippets and miscellaneous macros, such as common \once\override's and a list of common markup expressions. It also \include's all of the files in the .lily/macros folder. The files in the macros folder are longer snippets or collections of snippets related to a common task, such as jazz notation. The other files in .lily are stylesheet files like orchestral_style.ily or chamber_style.ily, which contain \layout blocks with most of the overrides I use, custom contexts, etc. I am fairly conservative about adding or removing things from my stylesheets, since they each apply to many projects. Instead, I can contradict the stylesheet with overrides in project_lib.ily, as long as I \include project_lib.ily after I \include orchestral_style.ily. -- View this message in context: http://lilypond.1069038.n5.nabble.com/An-idea-for-a-systematic-development-of-a-large-score-tp146017p146032.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org
Re: An idea for a systematic development of a large score.
On 17 May 2013, at 03:26 , wjm wrote: After a lot of fiddling around I came up with this schema:- I use a similar approach. This approach is well-facilitated in Frescobaldi, using the point- and-click correlation between the output pane and the relevant input file. (Frescobaldi calls up the relevant .ily file even if it is not loaded at the time - a very convenient feature). Whether this would work well for someone with severe visual impairment or other disability, I don't know. Difficult to say, they use other graphical oriented programs, so my guess is managing Frescobaldi is probably doable. Another and much greater problem is that I noticed several of the blind users do use a Mac, and installing Frescobaldi on a Mac is not easy. Regards, Wim. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
lol. try nigh impossible if you have absolutely no knowledge of the terminal. I tried frescoboldi in the windows environment and it sucked. I think for this arrangement for now I'll have alto2.ly, alto1.ly, soprano2ly, soprano 1-1.ly and soprano1.ly then the piano part.ly or what ever it will be. Hopefully I can then combine all the parts and stuff. This piece should when finished be sweet as it's been in my head for 3 years and I've always wanted to do this. Take care guys. On May 17, 2013, at 8:34 AM, Wim van Dommelen m...@wimvd.nl wrote: On 17 May 2013, at 03:26 , wjm wrote: After a lot of fiddling around I came up with this schema:- I use a similar approach. This approach is well-facilitated in Frescobaldi, using the point-and-click correlation between the output pane and the relevant input file. (Frescobaldi calls up the relevant .ily file even if it is not loaded at the time - a very convenient feature). Whether this would work well for someone with severe visual impairment or other disability, I don't know. Difficult to say, they use other graphical oriented programs, so my guess is managing Frescobaldi is probably doable. Another and much greater problem is that I noticed several of the blind users do use a Mac, and installing Frescobaldi on a Mac is not easy. Regards, Wim. ___ 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
An idea for a systematic development of a large score.
A bit of my LP background - - - Several years ago I was asked by a local church-choir director to prepare a couple of pieces for use by other church-groups. He knew that I had used computers for preparing teaching and publication graphics of one sort or another, and that I had done a little music 'engraving' using an early version of Finale. When he suggested this project I reviewed my use of, and degree of familiarity with, Finale and decided that there should be another option, which eventually led me to Lilypond. All of the use I've made of LP since has been transcribing from mainly hand-written scores of unison or SATB choral works. The first few years were an uphill struggle, notwithstanding the existence of the Tutorial and Notation Reference manuals, and a really useful resource has been the User-list :) . Making use of templates and other completed LP files, and adapting snippets etc., made my experience a lot less 'rocky' than it might otherwise have been. I make no apology for making use of the vast experience of subscribers to this list and am grateful that so many have provided solutions to problems I've encountered from time to time. It was with this in the back of my mind that I offered the 'schema' in my earlier post in the hope that it would make life a little easier for other users, particularly those who, like me, regard themselves as 'new users'. :) Thanks to all, Regards, Bill ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
Jan: When I click that link, I see this: http://lilypond.1069038.n5.nabble.com/file/n146067/Coriolan.jpg What am I supposed to see there? Are there examples or something? Thanks, Ben Jan Nieuwenhuizen wrote wjm writes: After a lot of fiddling around I came up with this schema:- That reads much like http://git.savannah.gnu.org/cgit/lilypond.git/tree/mutopia/Coriolan?id=60fdc53305e8628dad96b4ebea177bc6ee8d95cd what are we missing? Greetings, Jan -- Jan Nieuwenhuizen lt; janneke@ gt; | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-user mailing list lilypond-user@ https://lists.gnu.org/mailman/listinfo/lilypond-user - composer | sound designer -- View this message in context: http://lilypond.1069038.n5.nabble.com/An-idea-for-a-systematic-development-of-a-large-score-tp146017p146067.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
An idea for a systematic development of a large score.
Greetings!
After watching Sarah K Alawami's work on a score recently on this
user-list, but not having the musical and compositional skills to make
constructive remarks, and after reading the thread entitled 'stylesheet
structure', it occurred to me that an approach might be found which
might make the whole process a little less opaque.
After a lot of fiddling around I came up with this schema:-
Write separate files for each instrument, containing only its musical
elements, and name them 'instrument'.ily, signifiying that they are not
to be compiled directly by Lilypond.
Write separate files for each instrument, \includeing the relevant
.ily file, and with enough information to allow Lilypond to process it
correctly. (This would enable 'proofing' of each instrument for musical
correctness concerning octaves, barchecks, etc., without having to deal
with the complete score).
Write a separate file for the version, paper, header, sections, naming
it version-paper-header.ily
Write a separate file for the global constants; time, beat, key, etc.,
-structure, naming it global.ily
Write an overarching 'score' file \includeing all the relevant .ily
files, and containg any additional information for the final processing
by Lilypond, naming it 'musical-title'.ly
This approach is well-facilitated in Frescobaldi, using the
point-and-click correlation between the output pane and the relevant
input file. (Frescobaldi calls up the relevant .ily file even if it is
not loaded at the time - a very convenient feature).
Whether this would work well for someone with severe visual impairment
or other disability, I don't know.
Regards,
Bill
This is how a work might be structured:-
+
global.ily
version-paper-header.ily
+
bass.ily
bassoon.ily
cello.ily
clarinet.ily
drum.ily
flute.ily
horn.ily
oboe.ily
score.ily
trumpet.ily
viola.ily
violin-ii.ily
violin-i.ily
+
bass.ly
bassoon.ly
cello.ly
clarinet.ly
drum.ly
flute.ly
horn.ly
oboe.ly
trumpet.ly
viola.ly
violin-ii.ly
violin-i.ly
+
fullscore.ly
+
Example files are as follows:-
global.ily ---
==
global=
{\time 12/8
\tempo 4. = 100
\key g \major
}
==
version-paper.ily ---
==
\version 2.17.15
\header
{
%whatever is wanted from the full header definition as in the Lilypond
documentation...
}
#(set-global-staff-size 17)
\paper
{
indent = 30 % space for instrumentName
short-indent = 15 % space for shortInstrumentName
}
==
a music file ---
==
\include version-paper.ily
\include global.ily
\include bass.ily
\score {
{ \global \bassMusic }
\layout { }
}
==
the 'score' file ---
==
\score {
\new StaffGroup = StaffGroup_woodwinds
\new Staff = Staff_flute
{
\set Staff.instrumentName = #Flute
\global\fluteMusic
}
\new Staff = Staff_clarinet
{
\set Staff.instrumentName =
\markup { \concat { Clarinet in B \flat } }
\transposition bes
\global \transpose bes c' \clarinetMusic
}
\new Staff = Staff_bassoon
{
\set Staff.instrumentName = #Bassoon
\global \bassoonMusic
}
\new StaffGroup = StaffGroup_brass
\new Staff = Staff_hornI
{
\set Staff.instrumentName = #Horn in F
\transposition f
\transpose f c' \global \hornMusic
}
\new Staff = Staff_trumpet
{
\set Staff.instrumentName = #Trumpet in C
\global \trumpetMusic
}
\new RhythmicStaff = RhythmicStaff_percussion
\set RhythmicStaff.instrumentName = #Percussion
\global \percussionMusic
\new StaffGroup = StaffGroup_strings
\new StaffGroup = StaffGroup_violins
\new Staff = Staff_violinI
{
\set Staff.instrumentName = #Violin I
\global \violinIMusic
}
\new Staff = Staff_violinII
{
\set Staff.instrumentName = #Violin II
\global \violinIIMusic
}
\new Staff = Staff_viola
{
\set Staff.instrumentName = #Viola
\global \violaMusic
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: An idea for a systematic development of a large score.
does not sound like a bad idea. I'm gong to be working on an arrangement of oh
come equal and hope to get it done by November or so. it's a surprise for a
very special friend of mine who is let's say very fragile in health and I want
to give it to her choir. I'm thinking of writing all the parts including the
piano part f in separate files. As I don't use frescoboldi due to its
inaccessibility I have to use texshop and lily pond. Tha'ts fine. and I hope
this can work and be readable and singable by all members of this very special
choir.
Since Im not a pianist that [part will not be too easy but I can tinker a bit
and come up with something.
Thanks for the suggestion and I might start on this as soon as I finish my
proficiency and other tests coming up tomorrow.
This time I do want this score performed hopefully this year if she will let me.
If I can get it done before november that would be good.
Take care all and again thanks for the idea.
On May 16, 2013, at 6:26 PM, wjm mooney...@aim.com wrote:
Greetings!
After watching Sarah K Alawami's work on a score recently on this user-list,
but not having the musical and compositional skills to make constructive
remarks, and after reading the thread entitled 'stylesheet structure', it
occurred to me that an approach might be found which might make the whole
process a little less opaque.
After a lot of fiddling around I came up with this schema:-
Write separate files for each instrument, containing only its musical
elements, and name them 'instrument'.ily, signifiying that they are not to be
compiled directly by Lilypond.
Write separate files for each instrument, \includeing the relevant .ily
file, and with enough information to allow Lilypond to process it correctly.
(This would enable 'proofing' of each instrument for musical correctness
concerning octaves, barchecks, etc., without having to deal with the complete
score).
Write a separate file for the version, paper, header, sections, naming it
version-paper-header.ily
Write a separate file for the global constants; time, beat, key, etc.,
-structure, naming it global.ily
Write an overarching 'score' file \includeing all the relevant .ily files,
and containg any additional information for the final processing by Lilypond,
naming it 'musical-title'.ly
This approach is well-facilitated in Frescobaldi, using the point-and-click
correlation between the output pane and the relevant input file. (Frescobaldi
calls up the relevant .ily file even if it is not loaded at the time - a very
convenient feature).
Whether this would work well for someone with severe visual impairment or
other disability, I don't know.
Regards,
Bill
This is how a work might be structured:-
+
global.ily
version-paper-header.ily
+
bass.ily
bassoon.ily
cello.ily
clarinet.ily
drum.ily
flute.ily
horn.ily
oboe.ily
score.ily
trumpet.ily
viola.ily
violin-ii.ily
violin-i.ily
+
bass.ly
bassoon.ly
cello.ly
clarinet.ly
drum.ly
flute.ly
horn.ly
oboe.ly
trumpet.ly
viola.ly
violin-ii.ly
violin-i.ly
+
fullscore.ly
+
Example files are as follows:-
global.ily ---
==
global=
{\time 12/8
\tempo 4. = 100
\key g \major
}
==
version-paper.ily ---
==
\version 2.17.15
\header
{
%whatever is wanted from the full header definition as in the Lilypond
documentation...
}
#(set-global-staff-size 17)
\paper
{
indent = 30 % space for instrumentName
short-indent = 15 % space for shortInstrumentName
}
==
a music file ---
==
\include version-paper.ily
\include global.ily
\include bass.ily
\score {
{ \global \bassMusic }
\layout { }
}
==
the 'score' file ---
==
\score {
\new StaffGroup = StaffGroup_woodwinds
\new Staff = Staff_flute
{
\set Staff.instrumentName = #Flute
\global\fluteMusic
}
\new Staff = Staff_clarinet
{
\set Staff.instrumentName =
\markup { \concat { Clarinet in B \flat } }
\transposition bes
\global \transpose bes c' \clarinetMusic
}
\new Staff = Staff_bassoon
{
\set Staff.instrumentName = #Bassoon
\global \bassoonMusic
}
\new StaffGroup = StaffGroup_brass
\new Staff = Staff_hornI
{
\set Staff.instrumentName = #Horn in F
\transposition f
\transpose f c' \global \hornMusic
}
\new Staff = Staff_trumpet
{
\set Staff.instrumentName = #Trumpet in C
\global \trumpetMusic
}
\new RhythmicStaff = RhythmicStaff_percussion
\set RhythmicStaff.instrumentName = #Percussion
\global \percussionMusic
\new StaffGroup = StaffGroup_strings
\new StaffGroup =
Re: An idea for a systematic development of a large score.
This is somewhat the approach I'm taking with my Psalter project. each
selection/hymn/psalm setting has a lyric file and a tune file. Each contains
variables such as poet, scripture reference,copyright, etc. that are relevant
and unchanging with that file. This allows me to reuse tunes with other lyrics
that have the same meter.
Each pairing of tune and lyric is combined in a score file. Because I am
creating two completely different output formats (book and slide), the score
file builds each staff and lyric as variables and then calls a score-generating
scheme function.
I then have a main file that includes the score files I want to use in the
finished book. When I just want to work with a single song, I comment out all
the others.
My top-level files are the files for each format. Each one includes three
files. The first one is my global settings file, which has all my shorthand
variable declarations and some other things like that. The second is a format
settings file, which contains the paper block for the edition as well as the
score-producing function for that format. The third is the main file to tell it
which songs to set up.
Cheers,
Carl
Original Message
From: Sarah k Alawami marri...@gmail.com
Sent: Thu May 16 22:03:48 EDT 2013
To: Lilypond-User List lilypond-user@gnu.org
Subject: Re: An idea for a systematic development of a large score.
does not sound like a bad idea. I'm gong to be working on an arrangement of oh
come equal and hope to get it done by November or so. it's a surprise for a
very special friend of mine who is let's say very fragile in health and I want
to give it to her choir. I'm thinking of writing all the parts including the
piano part f in separate files. As I don't use frescoboldi due to its
inaccessibility I have to use texshop and lily pond. Tha'ts fine. and I hope
this can work and be readable and singable by all members of this very special
choir.
Since Im not a pianist that [part will not be too easy but I can tinker a bit
and come up with something.
Thanks for the suggestion and I might start on this as soon as I finish my
proficiency and other tests coming up tomorrow.
This time I do want this score performed hopefully this year if she will let me.
If I can get it done before november that would be good.
Take care all and again thanks for the idea.
On May 16, 2013, at 6:26 PM, wjm mooney...@aim.com wrote:
Greetings!
After watching Sarah K Alawami's work on a score recently on this user-list,
but not having the musical and compositional skills to make constructive
remarks, and after reading the thread entitled 'stylesheet structure', it
occurred to me that an approach might be found which might make the whole
process a little less opaque.
After a lot of fiddling around I came up with this schema:-
Write separate files for each instrument, containing only its musical
elements, and name them 'instrument'.ily, signifiying that they are not to be
compiled directly by Lilypond.
Write separate files for each instrument, \includeing the relevant .ily
file, and with enough information to allow Lilypond to process it correctly.
(This would enable 'proofing' of each instrument for musical correctness
concerning octaves, barchecks, etc., without having to deal with the complete
score).
Write a separate file for the version, paper, header, sections, naming it
version-paper-header.ily
Write a separate file for the global constants; time, beat, key, etc.,
-structure, naming it global.ily
Write an overarching 'score' file \includeing all the relevant .ily files,
and containg any additional information for the final processing by Lilypond,
naming it 'musical-title'.ly
This approach is well-facilitated in Frescobaldi, using the point-and-click
correlation between the output pane and the relevant input file. (Frescobaldi
calls up the relevant .ily file even if it is not loaded at the time - a very
convenient feature).
Whether this would work well for someone with severe visual impairment or
other disability, I don't know.
Regards,
Bill
This is how a work might be structured:-
+
global.ily
version-paper-header.ily
+
bass.ily
bassoon.ily
cello.ily
clarinet.ily
drum.ily
flute.ily
horn.ily
oboe.ily
score.ily
trumpet.ily
viola.ily
violin-ii.ily
violin-i.ily
+
bass.ly
bassoon.ly
cello.ly
clarinet.ly
drum.ly
flute.ly
horn.ly
oboe.ly
trumpet.ly
viola.ly
violin-ii.ly
violin-i.ly
+
fullscore.ly
+
Example files are as follows:-
global.ily ---
==
global=
{\time 12/8
\tempo 4. = 100
\key g \major
}
==
version-paper.ily ---
==
\version 2.17.15
\header
{
%whatever is wanted from the full header definition as in the Lilypond
documentation...
}
#(set-global-staff-size 17)
\paper
{
indent = 30 % space for instrumentName
Re: An idea for a systematic development of a large score.
wjm writes: After a lot of fiddling around I came up with this schema:- That reads much like http://git.savannah.gnu.org/cgit/lilypond.git/tree/mutopia/Coriolan?id=60fdc53305e8628dad96b4ebea177bc6ee8d95cd what are we missing? 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
