I nominated my musical compositions for consideration for the various local Baker artist awards and grants (of Baltimore) by adding a page on their site just now.
Please consider looking! As you know, comments are love (there, as ever). :-)
Copyright (c) 2013 Mark D. Blackwell.
Showing posts with label LilyPond. Show all posts
Showing posts with label LilyPond. Show all posts
Wednesday, January 16, 2013
Saturday, January 12, 2013
SATB sheet music from Mutopia
I have prepared a selection (twenty-nine numbers) of SATB sheet music, starting from Mutopia's search filter in the vocal category.
All have lyrics in English, Latin, or Spanish (and some French, German, and Italian) in the staff (as opposed to being separately printed).
They are not filtered for quality, nor for content type (such as religious).
They are engraved using the beautiful Lilypond, as everything is on Mutupia.
Copyright (c) 2013 Mark D. Blackwell.
All have lyrics in English, Latin, or Spanish (and some French, German, and Italian) in the staff (as opposed to being separately printed).
They are not filtered for quality, nor for content type (such as religious).
They are engraved using the beautiful Lilypond, as everything is on Mutupia.
- Abendruhe—W. A. Mozart (1756–1791)
- Al mormorar de' liquidi cristalli, madrigale a 6 voci—G. Gastoldi (1556–1622)
- Alas! and did my savior bleed?—J. K. Banks (1987–)
- All my heart this night rejoices—C. E. Horsley (1822–1876)
- Ave Maria—P. Benoit (1834–1901)
- Beatus vir—C. Monteverdi (1567–1643)
- Caligaverunt—J. Naujalis (1869–1934)
- Come again—J. Dowland (1563–1626)
- Dies irae—W. A. Mozart (1756–1791)
- Dolcissima mia vita—C. Gesualdo (1566–1613)
- El grillo—J. des Prés (c.1440–1521)
- Es ist ein ros’ entsprungen (Anonymous)
- Fairest isle—H. Purcell (1658–1695)
- Glory to god in the highest—G. B. Pergolesi (1710–1736)
- Magnificat—P. Benoit (1834–1901)
- Musiche per la maddalena—C. Monteverdi (1567–1643)
- O how amiable are thy dwellings—T. Weelkes (1576–1623)
- O nata lux de lumine—T. Tallis (1510–1585)
- Popule meus—J. Naujalis (1869–1934)
- Receive the body of Christ—D. Johnson (?–)
- Sestina—C. Monteverdi (1567–1643)
- Sibylla samia—O. de Lassus (1530 or 1532–1594)
- Silver swan, the—O. Gibbons (1583–1625)
- T'amo mia vita—C. Monteverdi (1567–1643)
- Tantum ergo sacramentum—F. J. Haydn (1732–1809)
- Tantum ergo—F. Schubert (1797–1828)
- To hope—S. Magnenat (1980–)
- Trust and obey—D. B. Towner (1833–1896)
- Unquiet thoughts—J. Dowland (1563–1626)
Copyright (c) 2013 Mark D. Blackwell.
Labels:
beauty,
choral music,
engrave,
hymn,
Latin,
LilyPond,
mozart,
music,
mutopia,
religion,
SATB,
select,
sheet music,
song,
tonal music
Monday, November 14, 2011
Text-label your measures in LilyPond with YAML
Some music (especially some choral music) is somewhat irregular of measure length. Naturally with this kind of music, while entering (and editing, following one's musical sense), often measures will join or split. Then half of the measure numbers are thrown off. This is especially true of early music, and recent music whose source documents were prepared somewhat in a free way.
Often, given multiple voice parts (or instruments), each, for various purposes, necessitates several source files in parallel (if working in LilyPond): such as for adjustments to piano or organ reductions. Many features not yet done (completely and automatically) well by LilyPond necessitate these additional parallel files.
Whenever information is parallel, it requires careful synchronizing of all the measures (and measure lengths). What a bother!
Obviously, if humans are checking and synchronizing something (with difficulty), this is a good opportunity for computers to do the work instead. In that situation, I wrote a computer program allowing measures to be labeled by (text) strings, instead of (only) by measure numbers.
The program fills each measure (completely) with spacer rests (unless told otherwise). This eases synchronization, because you need only include measures with actual content.
The program uses YAML as its data entry format. YAML's noise (the extra characters you enter) is very spare. It seems cleanest for entering LilyPond source (it interferes only minimally) yet allows measures to be labeled easily by text strings.
Available on my GitHub (and written in Ruby), the program is called, 'yaml2lilypond'. Recently, I successfully used it to engrave (typset) a large work--and it helped a lot!
Copyright (c) 2011 Mark D. Blackwell.
Often, given multiple voice parts (or instruments), each, for various purposes, necessitates several source files in parallel (if working in LilyPond): such as for adjustments to piano or organ reductions. Many features not yet done (completely and automatically) well by LilyPond necessitate these additional parallel files.
Whenever information is parallel, it requires careful synchronizing of all the measures (and measure lengths). What a bother!
Obviously, if humans are checking and synchronizing something (with difficulty), this is a good opportunity for computers to do the work instead. In that situation, I wrote a computer program allowing measures to be labeled by (text) strings, instead of (only) by measure numbers.
The program fills each measure (completely) with spacer rests (unless told otherwise). This eases synchronization, because you need only include measures with actual content.
The program uses YAML as its data entry format. YAML's noise (the extra characters you enter) is very spare. It seems cleanest for entering LilyPond source (it interferes only minimally) yet allows measures to be labeled easily by text strings.
Available on my GitHub (and written in Ruby), the program is called, 'yaml2lilypond'. Recently, I successfully used it to engrave (typset) a large work--and it helped a lot!
Copyright (c) 2011 Mark D. Blackwell.
Labels:
compose,
computer,
data entry,
efficient,
github,
LilyPond,
measure,
music,
notation,
programming,
ruby,
sheet music,
text label,
yaml,
yaml2lilypond
Wednesday, August 24, 2011
Cygwin, Git Bash and native Windows apps, howto
I use Debian and Windows XP — the latter sometimes on a netbook, but principally on a fast desktop computer (it has a nice monitor). On Debian, I develop software in the normal way. But, when I'm on Windows, I have to resort to a variety of techniques.
On a fast desktop computer, I use many native Windows apps (e.g. 7-Zip instead of Tar with compression; in the Windows way). I use Cygwin apps where a good native Windows version is lacking.
For example, previously I ran Cygwin's LilyPond till I noticed the niceness of the Windows version.
But mostly on Cygwin I enjoy the Bash command line interface and its filesystem.
My desktop's Git is through Cygwin, but the netbook has msysGit (with its own version of Bash). (Msysgit is also known as Git Bash.)
Within msysGit, so far, Bash's symbolic links aren't good — if you make one, it actually copies the whole folder!
I could try alternatives (suggested on MinGW's MSYS page) such as Interix (also known as Microsoft's SFU or SUA).
Paths
In order to maintain only one copy on the desktop of things like SSH keys (used by Git) I followed instructions to move my Cygwin user home directory to the same place as my Windows user home directory — which worked just fine! (Additionally, I set LANG to en_US.UTF-8, as suggested.)
Now, this command works just fine for me:
ruby app/hello.rb
I seem to recall that, for a while, it gave me an error, 'no such file'. Perhaps when I cleaned and upgraded my Cygwin installation (including my .bash* files) and then did a couple of reboots, the problem went away. (Don't you hate that?)
Cygwin can run both Cygwin apps, and native Windows apps. For speed and maintainability reasons, it's good to minimize the programs installed into Cygwin, doing so only if no native Windows version will succeed there (or can conveniently be run outside it). For example, my RubyGems installation is a native Windows one.
In Cygwin, the command, 'rake' (e.g.) might give you:
No such file or directory -- /cygdrive/c/progra/ruby/1.8.7-p352/bin/rake (LoadError)
even though it is found by, 'which rake':
/cygdrive/c/progra/ruby/1.8.7-p352/bin/rake
The solution (in Cygwin) is to type, 'rake.bat' (gem.bat, irb.bat, pik.bat, etc.).
If desired, you can alias rake, gem, irb and pik as with Robert Wahler's Stack Overflow answer, but just on the command line — it doesn't normally work in Bash scripts. (E.g., 'alias rake=rake.bat' — to reverse it: 'unalias rake'.)
If you are having problems with native Windows programs still not finding files in Cygwin, you might want to look at one aspect of Cygwin filesystems (some sources say) which requires special handling.
The documentation says passing filesystem paths (in Cygwin Bash) to native Windows apps (such as Ruby) is done (although sometimes I need to) in one of two ways:
One is to use native 'Win32' paths — two examples follow, for which I made a Ruby test program ('app/hello.rb' containing only, 'p __FILE__'). They require at least one, escaped backslash:
In (Cygwin's) current directory (using native Win32 paths):
ruby '.\hello.rb'
ruby .\\hello.rb
Or in 'app', relative to the current directory:
ruby 'app\hello.rb'
ruby app\\hello.rb
The other is to use cygpath:
In the current directory (add, '-a' for the full path):
ruby "`cygpath -m hello.rb`"
Or in the relative directory, 'app' (recently, with one long path, I had to do it this way):
ruby "`cygpath -m app/hello.rb`"
Permissions
Developing with both msysGit and Cygwin normally generates Unix permissions problems. Their Gits flip-flop the permission bits between '100777' (Cygwin) and '100644' (msysGit) on most files! Those with certain typically-executable extensions like .exe and .bat alternate between '100777' (Cygwin) and '100755' (msysGit).
To avoid most of this problem, you can mount your Cygwin user home directory in a way close to the msysGit method:
/cygdrive/c/Documents\040and\040Settings/[user name] /home/[user name] ntfs binary,noacl,bind 0 0
'noacl' tells Cygwin not to use the Access Control Lists found in Microsoft's NT tree. (BTW, as of Cygwin 1.7.9-1, 'posix=1' and 'nouser' are ignored here.)
The exception is that Cygwin will look for '#!' at the beginning of files to set the executable bit; msysGit, as mentioned above, will look at extensions like .exe and .bat.
In a development project, it might be useful to set write- and execute-permissions (at least the 'user' bits). If you want to manipulate permission bits further in your repository, you can tell msysGit (or even Cygwin Git) to ignore permission bit differences. Then you can set (see Jakub Narębski's answer) the (user?) execute bits:
git update-index --chmod=+x [file paths]
and reset them:
git update-index --chmod=-x [file paths]
before you do, 'git commit'.
(Tested with Ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mingw32], Cygwin 1.7.9-1.)
BTW, to see what Cygwin version you are running:
cygcheck -c cygwin
References
file modes - Cygwin
NT Security - Cygwin
file modes - msysGit
discussion
Copyright (c) 2011, 2015 Mark D. Blackwell.
On a fast desktop computer, I use many native Windows apps (e.g. 7-Zip instead of Tar with compression; in the Windows way). I use Cygwin apps where a good native Windows version is lacking.
For example, previously I ran Cygwin's LilyPond till I noticed the niceness of the Windows version.
But mostly on Cygwin I enjoy the Bash command line interface and its filesystem.
My desktop's Git is through Cygwin, but the netbook has msysGit (with its own version of Bash). (Msysgit is also known as Git Bash.)
Within msysGit, so far, Bash's symbolic links aren't good — if you make one, it actually copies the whole folder!
I could try alternatives (suggested on MinGW's MSYS page) such as Interix (also known as Microsoft's SFU or SUA).
Paths
In order to maintain only one copy on the desktop of things like SSH keys (used by Git) I followed instructions to move my Cygwin user home directory to the same place as my Windows user home directory — which worked just fine! (Additionally, I set LANG to en_US.UTF-8, as suggested.)
Now, this command works just fine for me:
ruby app/hello.rb
I seem to recall that, for a while, it gave me an error, 'no such file'. Perhaps when I cleaned and upgraded my Cygwin installation (including my .bash* files) and then did a couple of reboots, the problem went away. (Don't you hate that?)
Cygwin can run both Cygwin apps, and native Windows apps. For speed and maintainability reasons, it's good to minimize the programs installed into Cygwin, doing so only if no native Windows version will succeed there (or can conveniently be run outside it). For example, my RubyGems installation is a native Windows one.
In Cygwin, the command, 'rake' (e.g.) might give you:
No such file or directory -- /cygdrive/c/progra/ruby/1.8.7-p352/bin/rake (LoadError)
even though it is found by, 'which rake':
/cygdrive/c/progra/ruby/1.8.7-p352/bin/rake
The solution (in Cygwin) is to type, 'rake.bat' (gem.bat, irb.bat, pik.bat, etc.).
If desired, you can alias rake, gem, irb and pik as with Robert Wahler's Stack Overflow answer, but just on the command line — it doesn't normally work in Bash scripts. (E.g., 'alias rake=rake.bat' — to reverse it: 'unalias rake'.)
If you are having problems with native Windows programs still not finding files in Cygwin, you might want to look at one aspect of Cygwin filesystems (some sources say) which requires special handling.
The documentation says passing filesystem paths (in Cygwin Bash) to native Windows apps (such as Ruby) is done (although sometimes I need to) in one of two ways:
One is to use native 'Win32' paths — two examples follow, for which I made a Ruby test program ('app/hello.rb' containing only, 'p __FILE__'). They require at least one, escaped backslash:
In (Cygwin's) current directory (using native Win32 paths):
ruby '.\hello.rb'
ruby .\\hello.rb
Or in 'app', relative to the current directory:
ruby 'app\hello.rb'
ruby app\\hello.rb
The other is to use cygpath:
In the current directory (add, '-a' for the full path):
ruby "`cygpath -m hello.rb`"
Or in the relative directory, 'app' (recently, with one long path, I had to do it this way):
ruby "`cygpath -m app/hello.rb`"
Permissions
Developing with both msysGit and Cygwin normally generates Unix permissions problems. Their Gits flip-flop the permission bits between '100777' (Cygwin) and '100644' (msysGit) on most files! Those with certain typically-executable extensions like .exe and .bat alternate between '100777' (Cygwin) and '100755' (msysGit).
To avoid most of this problem, you can mount your Cygwin user home directory in a way close to the msysGit method:
/cygdrive/c/Documents\040and\040Settings/[user name] /home/[user name] ntfs binary,noacl,bind 0 0
'noacl' tells Cygwin not to use the Access Control Lists found in Microsoft's NT tree. (BTW, as of Cygwin 1.7.9-1, 'posix=1' and 'nouser' are ignored here.)
The exception is that Cygwin will look for '#!' at the beginning of files to set the executable bit; msysGit, as mentioned above, will look at extensions like .exe and .bat.
In a development project, it might be useful to set write- and execute-permissions (at least the 'user' bits). If you want to manipulate permission bits further in your repository, you can tell msysGit (or even Cygwin Git) to ignore permission bit differences. Then you can set (see Jakub Narębski's answer) the (user?) execute bits:
git update-index --chmod=+x [file paths]
and reset them:
git update-index --chmod=-x [file paths]
before you do, 'git commit'.
(Tested with Ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mingw32], Cygwin 1.7.9-1.)
BTW, to see what Cygwin version you are running:
cygcheck -c cygwin
References
file modes - Cygwin
NT Security - Cygwin
file modes - msysGit
discussion
Copyright (c) 2011, 2015 Mark D. Blackwell.
Subscribe to:
Comments (Atom)