Re: [Fwd: Re: confused about transposing]
David Rogers wrote: On 2004/01/28, William R. Brohinsky wrote: ...(a very comprehensive answer to the transposition question)... But, wouldn't he have to transpose DOWN a tone, when moving from a Bflat-notated instrument to a C-notated one? So - \transpose c bes, ? Absolutely right, David. Sorry, Chip. After all that very nice (and actually correct) verbiage about moving the music 'up' when going from concert to Bb, I blew going 'back down' when going from Bb back to concert. (actually, down by a ninth, from notated Bb tenor sax to bass-clef trombone). Thanks for the correction! raybro ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
[Fwd: Re: confused about transposing]
--- Begin Message --- Chip, The important thing to understand about the \transpose function is that the two note names following the \transpose represent the interval of transposition. To transpose from music written in C to music appropriate for a Bb instrument, you must end up with music in the key of D. This infers that the music must 'move up' by a whole tone, because the Bb instrument is essentially 'playing a whole tone flat': when you finger C on a Bb instrument, a concert Bb comes out. By recognizing that the music must go up one whole tone, you can say \transpose c d \transpose bes c \transpose f g etc. Any of those \transpose intervals will move the music from its current key up to the next key by a whole tone. This works regardless of the original key. For \transpose ees f the following will happen: \key c major becomes d major and all notes are moved up one whole tone \key f major becomes g major and all notes are moved up one whole tone etc. Likewise, the manual example, \transpose c g' moves the key up by a fifth, and each note up by a fifth, so the example music (in D) is moved to G. Note that notation of two notes separated by a fifth requires adding the ' to ensure that it goes up (rather than down a fourth). The answer to your specific question is dependent on information I don't have, so here's my guesses: either your chart was originally in Lilypond, and you successfully used the \transpose function to move it from something (and I'd guess it was C?) to Bb for tenor sax; or your original chart was transposed from whatever key it was originally in to a lilypond score which is now \key bes major; or your charts are all on paper, and you just want to enter the notes from the Bb sax part, and then use \transpose to shift it to bass clef. That's assuming, in all cases, that you're talking tenor/bass trombone, moving to bass clef rather than tenor, and not that you're aiming at an alto trombone in alto clef :) Case 1: The chart was originally in lilypond in C, and has been \transpose c d to make the Bb part. I'm assuming also that this Bb part is in treble clef, and that the trombone will be reading bass clef, non-transposing. (By the way, if it's someone who plays bari treble-clef parts, especially on valve trombone, he/she may be quite prepared to read the tenor sax part as it stands.) Also, there are two more possibilities that are important here: a) you wrote the part using relative notation or b) you wrote the part using absolute notation (ie, each note is marked to indicate absolute pitch). For case 1a, remove the \transpose function with it's two note names. Change the note that indicates the relative reference so it is an octave lower (ie, c' to c or c to c,). Change the clef to bass instead of treble or which ever of it's aliases you might have used. For case 2a, change the \transpose from whatever it is to c c, and change the clef from treble to bass. Case 2: The chart was originally on paper, and was transposed to Bb when entered, so that there is no standing \transpose function. In this case, add \transpose bes c, and change the clef to bass. Case 3: all current charts are on paper, and you want to make a lilypond version. Again, two sub-cases: a) you have the original C part and b) you don't. Case 3a: when entering the notes, use relative notation and make the relative statement relative an octave lower than normal. Ie, if the first note in the chart is c' (middle C) then notate it 'c', with the relative reference c, Case 3b: when entering the notes, use a \transpose bes c,(note this , is not a comma in the sentence structure, but a c,) and a relative reference appropriate to a trumpet (ie, if the first note is c'', make your relative for c'', then notate the first note as just c). Any of these _ought_ to work properly. If they don't, though, I apologize, and you get to analyze why it didn't, and adjust properly. Please, if you have to do that, write the list and tell us? raybro chip wrote: I have a chart I have transcribed for tenor sax. Now I would like to transpose it to trombone, bass clef. I read the little bit in the manual about transposing on page 87 but am confused by the pics - the sample code shows \transpose c g' \transpose c f' but the pics show a staff transposed into A and G, from D. I would expect to see the samples transposed into g and f, I guess. Anyway, I need some tips on going from Bb Tenor to Trombone. Thanks, Chip ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user --- End Message --- ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: Searc
As neuro's post shows, croma and croche are current names for what we in the US call 'eighth-notes'. If you consider the shape of the note (black head, stem, one flag), the previous name of this note was 'fusa'. This name comes from common renaissance usage where the note shape was used rarely. In modern transcriptions, the fusa is often reduced to a sixteenth or 32nd (double- or triple-croche). By these reductions, the croche (now) would be equivalent to the minim or semi-minim, the former appearing like a modern half-note (blanche) or quarter-note (noire). So by shape: . |/ croche (croma in italian) = fusa . | noire (nera, it) = semi-minim o | blanche (bianca, it) = minim o ronde (semibreve, it) = semibreve By transcription of 1/2: . . |/ fusa = | noire . o | semi-minim = | blanche I hope this answers your question! raybro LOUPI wrote: > > Hi! > > I came on your site and I think that maybe you could give me the > information I need. > > About the musical note "la croche". She was called "croma" but before > "croma", what was its name. > > Thank you![Image] > > Louise Pivot > > Excuse my English!!! > > -- > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > > --- > ___ > Lilypond-user mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/lilypond-user ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: no rests in tablature?
In tab, timing is remoted from the indications of notes: the timing is relegated to the stems above the letters. Each stem indicates how long it will be before the next stem (or implicit stem, since tabs often leave off repeated time-value stems). There is no indication of when a note is supposed to be held or released. While it might be nice to have that ability, using rests in the lines of the tab staff is not a nice way to do it. Rests are sometimes notated by stems that have no letters under them, and this is generally a better solution anyway, since the timing-attention of the player is focused above the staff, while the translate-letters-to-fret-closings attention is focused in the lines of the staff. To be forthright, if your music is complex to the point where you need to indicate rests, you probably should be using regular music notation, which affords considerably more control over note-length and release indications. For everything you gain in the world, you lose something. raybro Karl Berry wrote: > > > In lilypond 1.6.6 (and earlier), it seems that rests are not output in > > tablature. It would be nice to do this; > > Please do not add that. DaveA > > Dare I ask why not? Why is it bad to output rests? > > In any case, it could be an option, so that the rests could be output or > not, depending on the needs at hand. > > ___ > Lilypond-user mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/lilypond-user ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: tablature notation tautology
Before this becomes something other than the trivial pursuit that it is, let's lay it to rest once and for all. Tablature is notation. Every dictionary and encyclopaedia I can access, physical and online agrees. Music notation on staves with noteheads, in fact, can be considered a kind of tabliture, in fact. However, music notation is simply a system for indicating how to play music. Any system. Tablatures, successive fingering diagrams, staff-and-notehead-and-flag/stem, the lot. While tablatures are not _limited_ to plucked instruments, the statement is utterly accurate that David Raleigh Arnold wrote: > > "Tablature notation is used for notating music for plucked string instruments. It >notates pitches not by using note heads, but by indicating on which string and fret a note must be played." > Although the statement can be taken to be exclusive or absolute, it is not either. > Seemingly a minor matter, but troublesome, producing wrong thinking, and leading to >mistakes already. Tablature is not notation. The claim 'tablature is not notation' is the actual inaccurate statement, leading to wrong thinking. (Notation is not notation because it uses 'notes': notes are called notes because they were a form of notation that became common and wanted a name for the entities. Notes can also be jotted letters on a pad, informative marginal entries, or many other things: are these things all music?) Moreover, the real question is whether the definition proffered originally meets the description of the tablature that Lilypond is currently capable of making. It does. If we're going to get tautological about tablature in a manner that is effective where lilypond is concerned, it might be more useful to consider how we're going to be differentiating harmonica tablature from German organ tablature from wind instrument graphic fingering representations from line-and-number tabs like Lily does now. Unless the mechanism for notating (and perhaps the mechanism by which the objects are selected and placed?) is uniform, this is where differentiating and delineating will be of importance. raybro ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: Different time signatures
This is one that was solved for me a short time ago. There may be a
newer fix, but you don't say which version of lilypond you're using.
This one is good for 1.6.0 and on:
In the paper block, add the following:
\translator{ \ScoreContext
\remove "Timing_engraver" }
\translator { \StaffContext
\consists "Timing_engraver"}
The first line removes the timing engraver from the score context level,
the second reinserts it at the staff context level. The result is that
each staff is considered separately from each other for time signatures
and such, rather than as a score.
The only shortcoming of this approach is that you are now responsible
for all coordination of barlines between the staves. In other words, you
have to explicetly tell lilypond what kind of bar lines to use for each
part when you want something different from the standard
single-thin-barline. This is always going to affect the final barline
(at the least), so it makes a good example: for each staff, you will
have to explicetly specify the final barline with
\property Staff.whichBar = "|."
rather than being able to put \bar "|." in one of the staves, and having
Lilypond apply that to all the staves.
I hope this helps you as much as it helped me!
raybro
Dmitry Rutsky wrote:
>
> How can I get different time signatures on different staffs? Why example I am
> sending doesn't work?
>
> --- Dmitry Rutsky
>
>
>Name: different_time_signatures.ly
>different_time_signatures.lyType: Plain Text (text/plain)
>Encoding: base64
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: Timing_engraver and \remove - \consists in general
Uhhhn.
I was doing fairly well, between your response and Laura's and Rune's of
starting to understand this all. Now I've gone braindead again. Perhaps
it's driving 9 hours that did it, but this change leaves me with a bunch
of questions I'd like to get cleared up before I post the source for
odhecaton47.ly:
Is this new code effective in 1.6.0, or should I have upgraded by now,
or is it in CVS only at this point?
What's actually happening here?
That having been asked, I do want to stress that I'm overjoyed at the
help I've been getting on what is obviously a rare situation, very
important to my project, but probably insignificant in the larger
Lilypond world: I appreciate this beyond my ability to verbalize it!
Thank you all!
raybro
Han-Wen Nienhuys wrote:
>
> [EMAIL PROTECTED] writes:
> > > I can't get a final barline to appear.
> >
> > The manual says (under "Bar Lines"):
> >
> > The command \bar bartype is a short cut for doing
> > \property Score.whichBar = bartype
>
> I have changed this: now the shortcut, both for \time and \bar is to
> set \property Timing.X, and Timing is aliased to Score. The new
> poly-metric.ly thus reads:
>
> \score {
>
> \notes
> <
> \context Staff = SA
> {
> \time 4/4
> c1 c1 c1
> \bar "|."
> }
> \context Staff= SB {
> \time 3/4
> c2. c2. c2. c2.
> \bar "|."
> }
>
> >
>
> \paper{
> \translator{ \ScoreContext
> \remove "Timing_engraver" }
> \translator{ \StaffContext
> \consists "Timing_engraver"
> \alias Timing
> }
> }
> }
>
> --
>
> Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.cs.uu.nl/~hanwen
>
> ___
> Lilypond-user mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/lilypond-user
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: Timing_engraver and \remove - \consists in general
This worked perfectly! Thank you both! When I get back from NY, I'll post this piece's source and resulting .ps on my site, and if anyone wants to make use of it or any part of it for documenting polyrhythmic scores, you have my blessings! raybro Laura Conrad (and Han-Wen) wrote: > > >>>>> "raybro" == William R Brohinsky writes: > > raybro> I can't get a final barline to appear. > > Use: > > \property Staff.whichBar = "|." > > instead of \bar "|." > > \bar is a shorthand for the score bar engraver, which you've removed. > > -- > Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) > (617) 661-8097 fax: (801) 365-6574 > 233 Broadway, Cambridge, MA 02139 > > ___ > Lilypond-user mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/lilypond-user ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: Timing_engraver and \remove - \consists in general
I really appreciate the help, Han-wen! Thank you! This was exactly what I needed, the code fragment was enough to get the entire piece formatted correctly, except for one minor problem... I can't get a final barline to appear. The attachment is an abbrevement of my code, showing the first nine and last nine breves of the music I'm transcribing. This clearly shows that the barring solution works perfectly. Originally, for the final barline, I had one \bar "|." in the cantus part. (This has worked well in the other 32 pieces I've transcribed so far). Since it came after the scheme code and in the same block, I thought maybe it wanted to be 'outside' those blocks, so I moved it to the \global block (which is otherwise unused in this transcription, but usually holds the time signatures, separated by blocks, so that I can experiment with triplas via either time signatures or via triplet-markings with a minimum of misery). The skip is right, because adding an extra three breves adds three/one extra empty measures in all the parts, but still with just a single thin barline at the end. Changing to other barline types and reducing the \skip value still leaves nothing in the entire piece but thin barlines. My guess is that something that has been turned off needs to be turned back on? Although I'd love to understand why this doesn't work like this, and how it wants to be treated, I'll be perfectly happy for a quick-and-dirty fix, and try to understand it later. This is the only poly-time-signature piece in Odhecaton. This will be handy later, though, because I do intend to have at some of the better of the mensural canons... Some of us are gluttons for punishment! Han-Wen Nienhuys wrote: > > Also -- this is pretty nonstandard stuff, I wonder if this should be > in the regular manual at all. I can't say if it should be in the manual, but it should be _somewhere_. Maybe this deserves to be in the tips and tricks, under the 'quicksand and rabid aardvarks: tread with caution' heading? 8^) raybro pt3.ly Description: application/unknown-content-type-ly_auto_file
Timing_engraver and \remove - \consists in general
Heyla!
I'm still struggling with some apparently fundamental, basic concepts.
The internals for Timing_engraver says that "In order to create
polyrhythmic music, this engraver should be removed from Score and
placed in Staff."
After considerable searching about the tutorial, manual, internals docs,
regression tests and 'test' dir in Doc/lilypond-etc, I decided this
probably meant that I needed to have \translators in the \paper{}
section, one of which removed Timing_engraver from \ScoreContext, and
another that consist-s it into \StaffContext. Hoping and praying that
this might work, I tried this (with a lot of unnecessary stuff
excluded):
cantus=\notes\relative g' {
\key g \dorian
\time 2/2
[note list with barchecks on whole-note boundaries]
}
tenor=\notes\relative c' {
\key g \dorian
\time 3/1
[note list with barchecks on dotted-breve boundaries]
}
bassus=\notes\relative c {
\key g \minor %ok, it's really not, but it gets 2 flats
\time 2/2
[notes list, like cantus, on wholenote boundaries]
}
\score
{
\context ChoirStaff <
\context Staff="cantus" <
\notes{\clef "G2"}
\cantus
>
\context Staff="tenor" <
\notes{\clef "G2_8")
\tenor
>
\context Staff="bassus" <
\notes{\clef "F"}
\bassus
>
\paper{
\translator{ \ThreadContext
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"
}
\translator( \ScoreContext
\remove "Timing_engraver" }
\translator{ \StaffContext
\consists "Timing_engraver"}
}
The layout may seem a bit overcomplicated, but in actuality, lends
itself well to a project involving 96 pieces in 3, 4 or 5 parts which
have all sorts of individual needs, with an eventual hope of printing
scores and parts in modern, original, and possibly even ancient
clef/notation formats.
OK. The output from Lilypond 1.6.0 is beautiful, no question. But all
three parts have C for a time signature (if I comment out the
ScoreContext and StaffContext \translator blocks, it is C-slash for all
three parts) and all three parts are barred appropriately for C (or
C-slash). The tenor part's 3/1 is utterly ignored (and 6/2 is also if I
substitute that).
My questions:
1) The internals and manual and tutorial make it appear that the only
place that \translators are used to \remove or \consist engravers is in
the \paper() block. Is this so? Should I be making an individual
\translator block for each voice within it's \notes() block to \consists
"Timing_engraver"?
2) the documentation really doesn't give any help to the novice (which I
am still and may be forever) about syntax where \remove and \consists
are concerned: are the engravers enclosed in quote marks, properly?
3) Is there some other approach I should be taking, like setting the
barNonAuto property, and then manually \bar | where they should fall? If
I do this and use the Completion_heads_engraver, will a dotted
whole-note be drawn as a whole-note with a tied halfnote of the same
pitch, or as a dotted whole? Can I control Completion_heads_engraver on
a line-by-line basis?
4) What other questions should I be asking, but haven't the brains to
think of? 8^)
raybro
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Installation report on cygwin+lilypond 8/25-26/02
I downloaded the entire install yesterday and today (49.2K dialup) and installed it this evening. The results, in a nutshell? Everything worked fine. However. I did have a few bugaboo's, and am too tired to research the entire email record of the lists, so consider this raw input: ly2dvi -p produces different output from ly2dvi -P at the postscript level: ly2dvi -P produces .dvi files that lack certain features that appear in the .ps output. I believe this is fairly well-known, and relates to the fact that some features in the PS file are actually put into the .dvi file as postscript meta-commands, and thus are considered beneath notice by the dvi drivers. Specifically, beams on eighths and smaller notes were missing, and brackets for triplets. (the 3's with the cute curlies at the top were there, though.) Barlines, stems and dots didn't seem to have gone missing at all, though. What did surprise me is that the text (title, composer, etc) were properly displayed in xdvi! The .ps files have everything from a -P compile of a lilypond input. ly2dvi -p produces .dvi files that are identical to those produced with -P. But the ps. files are missing features that were missing only in .dvi files before...and also are missing text like title and composer! The pdf files produced are identical to the .ps files as well, so they lack features like text. Also, I noticed that the brackets for triplets appeared in the .ps and .pdf files after a -p, but the cute 3's were missing. AND it is really hard to get some form of ghost view running in cygwin. Even where someone had claimed to have made the port, or gave specific directions for bringing ghostview.1.5 into cygwin, I was unsuccesful. This worried me until I got the best FreeBSD guy I know working on it. He got further than I did (I bogged in the make file produced by xmkmf, he got to where he was trying to figure out why SMlib.a wouldn't link), but after 3 hours still didn't have a working native cygwin ghostview. I ended up getting the windows-native gsview and ghostscript to match it (duplicating all the ghostscript that came in the cygwin package, of course), and now I can view ps files again. It's worth mentioning that I did the install by running the setup program (whatever was current on sunday), clicking once to get INSTALL as the choice all through the tree, downloading all to my hard disk (about 170MB) and then running setup again to install it all. I also noticed I was getting complaints about old3/2, so I assume that this has either been changed or gone totally out of style. Is there something that clearly demarks when things (like backslashes, certain properties, etc) went out of style or what replaced them? raybro ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: tab
David Raleigh Arnold wrote: > Thanks much. The scholarly poster is right that there are > historical instances of putting the first string at the > bottom, but English renaissance lute tablature and all > modern tabs have the first string at the top so the > low notes will be on the bottom. *No one alive* is really > used to the upside down systems. > > Of course the lute isn't around much any more, largely > on account of tab. > I suspect I may be 'the scholarly poster', and regret that my post went to Mr. Arnold alone, a byproduct of the way my mailer chooses the to whom for a reply. Here is the text of my post: [begin quote] It is worth noting that a single approach to tab is a Bad Thing(TM) regardless of _which_ approach it is. Those of us who use tab a lot know that there are many different ways of tabbing even for a single instrument. Specifically, the lute: Modern tab notation, especially in ASCII form, tends to use numbers in the spaces between lines. The spaces, therefore, represent the strings. In general, they are high-string to top space. This is quite easy to do with ASCII, although tiresome to try to read. French tab uses letters, laid on lines which represented strings. The highest pitched string is on the top space. a is an open string, b is the first fret. This was popular amongst the English Lutenist Songwriter's school as well, so most lutenists who were exposed to tab via that literature will want to see it. Spanish tab uses numbers, usually laid over the line rather but also in spaces. The highest pitched string is on the bottom of the tab staff. These latter two standards alone (and I think something that has persisted for a few hundred years probably deserves the honor of being called a standard, certainly, if modern notation, a mere baby, does) lead to an immense number of systems: Letters or numbers as fret indicators; top pitch on top or bottom line; fret indicators on the lines or in spaces between the lines; whether to have lines encompassing highest and lowest strings if they are on spaces... Now add timing (which much modern tab does not, making it almost useless unless the person reading the tab already knows the music entabbed, ie, useless for newly-composed music). Because of the difficulty of notating long periods, most tab that notates time at all does it with duration-indicators that are divide-by-2, 4 or 8 of how the music might 'normally' be notated. Thus contemporary scores exist in keyboard notation with minims (look like diamond-shaped half-notes) and in lute tab with single-flag stems, a 4:1 time-notation difference. Whole notes floating over a tab staff ... well... look silly. An additional difficulty is how to deal with 'extra strings'. If the strings aren't fingered, they are traditionally notated by a single character or set of characters under the bottom string's area. In french tab, the general tendency was to treat the seventh string and even the eighth as if it were just another fingerable string. (ie, 'a' for the open string on a line of its own). More strings were treated a bit differently, often by a/ a// a/// or a\ a\\ a\\\ notations in the space below the staff. When the lute grew more strings (in the baroque period) numbers were used, usually starting with 4. This can get quite out of hand, by the way, especially since the counting of 'diapasons', the extra courses, can start at the seventh or the tenth or... well, anywhere. Now, the tendency might be to say, "Lily is for notating modern stuff", and dis the entire subject. As a counter to this, I note that Lily is perfectly good for notating Bach's concertos, cantatas, overatures and sonatas... even the violin partitas. But it cannot properly notate the lute versions. It is my belief that a system within lilypond for sensibly making tab notation is possible. However, I have to admit that my years of FORTH, various basics, and C have not prepared me for C++ and the incessant object oriented paradigm. So if someone who is able to read lily's internals and code, and who wants to have some fun implementing tab so that it is as versatile and functional as tab has been for centuries, I'd love to collaborate. raybro [end quote] While it is easy to wave a hand and dis the lute and all tab systems other than banjo and guitar, it is the aim of Lilypond to typeset beautiful music notation, and anything that makes that goal easier should be appropriate to consider. The claim that nobody alive reads spanish notation is erroneous, at least from a few moments ago when I checked my pulse. More importantly, it addresses the question of whether printing and presenting early music is appropriate in any form. Can it be that we should only print renaissance music in score or piano-reduction form? Perhaps it is desirable that all music only be published in one or the other of those forms. On the other hand, Lilypond _does_ have fonts and clefs for printing white mensural notation and neumes, and now
Re: transposing
Simon Bailey wrote: > > On Mon, 2002-07-29 at 22:18, Rune Zedeler wrote: > > > i know this may seem like a weird question but is there a way to > > > transpose and generate "lily-input" output? > > > > Why would you need that? > > one of the projects i'm currently working on is rearranging a march from > the american civil war for a modern marching band. the thing is -- the > original version is written mainly for e-flat instruments -- a modern > band (here in austria at least) has almost only b-flat instruments > written in treble (tranposed to b-flat) and bass (natural in c) clef. This really isn't a lily problem, since lily tends not to concern itself with generating output (other than in the case of midy2ly). However, it's not an intractible problem. The easiest thing to do would be to program a module for the editor you use. I'm currently not using linux for lily, so my tendency is to look at windows solutions. Notepad is a total loss. Word has VBA now, which is good: you could write the module in VBA, bind it to a keycombo, highlight the music to transpose, do the keycombo, insert the current key (don't make the poor program try to fingure that out) and the key to transpose to. Since you are only looking to transpose Eb parts to Bb, you could make a simpler program with just that one change. It'd only need a two dimensional text array, with element [0,0]= "C" and [0,1] = "G", [1,0] = "D", [1,1]="A". Do this logically: first for the major scale (mostlikely notes to see), then after that, chromatics properly named. Then chromatics that wouldn't be properly named, just for good luck. Have the module look at each note entry, separate the note name from the number, look up the number in the [0,*] array, print out the same index from the [1,*] array, stick the duration number on the end, and do it again. For all transposing cases, you'd want to have a 2D array with more than 2 1D arrays: one for each possible key. Then, it'd be a matter of locating the proper first index for the from- and to- keys, and then the solution is identical to the previous paragraph. It should be possible to do this in Emacs Lisp. It is certainly easy to do in C, if there's a good interface in emacs for running external programs on highlighted text. I just don't know emacs well enough to begin there. An external C program could certainly be written (or god forbid, C++, Perl, REXX, Python, whatever) that parses the Lily code, finds music, determines the key that music is notated in (maybe by the nearest preceding \key command?) finds out what interval to transpose by, and has at it. If all the rest of this seems gobbletygookish to you, I'll take a crack at that, since I have been able to write programs in unix with some modicum of success. raybro ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
re: lilypond 1.5.62
I downloaded the exp version, which installed without comment (that I could tell: some of those post-install scripts put up a dos-like window for a few seconds, wrote something in a few miliseconds and disappeared!) This is on windows XP, with all of microsoft's updates installed to date. When I ran lilypond from the icon on the desktop, I got the congratulations MOTD with all the web addresses. Everything looked fine. When I ran ly2dvi -P odhecaton1.ly I got an mbox with the white x on red background saying lilypond.exe - Entry Point Not Found (in the titlebar) X The procedure entry point posix_regcomp could not be located in the dynamic link library cygwin1.dll I installed on E:\cygwin. In E:\cygwin\bin, cygwin1.dll bears the date 11/14/2001. One possibility, I could suppose, could be from the download: I started from the html server, and partway through a texmf download I fell offline. When I restarted, the html server couldn't be used, so I told it to use the ftp server. I now have two directories under cyginst, with all sorts of escaped characters in them, one for each server. However, when I ran setup to install from the local directories, I got no complaints, and it installed from both lilypond and the texmf tars, stuff that spans both directories. I can't quote the lilypond version or any of that because cygwin kinda doesn't work without being able to access the specified posix_regcomp function, but the install was supposed to be 1.5.62jcn. Thanks for any illumination! raybro ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: Transcribing audio to manuscript
Stephen, I have to admit to some confusion as to what you mean by transcribing audio to notation. Are you talking about line-by-line transcription of parts, or reduction to piano staff, done by listening to a recording? Or are you assisting someone who 'composes' music but doesn't know how to notate? (NB: if this is the case, get them to record it!) I also had no formal education in piano reduction. I was a guitarist first, though, and I attempt to 'hear' most music I'm notating with my left hand. What this actually means is that I try to feel my hand playing the music. With guitar parts, this is amazingly easy; I've even been able, in a supermarket, to tell a friend that the guitarist in the muzak was capo'd up five, and what chord he was playing. The friend had perfect pitch and verified that I was calling it right. With other instruments and such, it helps to find the key. And like most guitarists who spend a lot of time accompanying other people, I can transpose very easily, so it isn't hard to go that way when I have to notate in a key that is different from 'the original'. Anyway, if I have your meaning right, there is nothing that beats having a strong familiarity with a 'fixed pitch' instrument, be it keyboard or fretted, so that you have a strong mind-hand relationship between notation and physical location on the instrument, and between location/string and pitch sound. And having the source recorded so that you can go back and relisten, too. For celerity, it is very useful to drill. Get scores for symphonies that you have on recordings, and aren't terribly familiar with. (terrible familiarity doesn't hurt, really, but the idea is to take stuff you don't know 'to paper', rather than learn the symphonies). Or, if you know someone who is a very accurate reader, get them a sight-singing book, have them sing each example/exercise, and notate it. Start with them telling you key and signatures, eventually work to where you can identify anything by ear, including original key, and then to where you can notate to any key despite the original key. (No, IMHO and experience, skipping the identify-key step doesn't make the latter step easier!) And finally, for the benefit of improving transposition ability, take up recorder. Start with soprano, then learn alto as a whole, separate instrument. (I. e., don't look at an e, and say, oh, F recorders are a fifth lower, so I'd want a in soprano fingering, to get the e on an alto! That defeats the whole purpose!) Then, get a D voice flute and a G alto (or just force yourself to learn the soprano with d as the putative lowest note, and the alto with g as the lowest note.) You'd be amazed how this will help, far more than the banned Bb and Eb instruments ever do, where all the music is written so that you play whatever you're holding as if C is the fundamental note of its scale! You can do this with violin, really, as well (the transposition drills), but its usually more mechanical, and requires a fret-attitude: transposition by a fourth up requires playing on the violin in fourth position, but pretending you are in first position, sort of thing. Guitarists used to barring will do this naturally. I was saved from it by recorders, shawms, and viols, though, as described above. I gotta go: if I've missed your point, please elaborate! raybro Stephen Allsopp wrote: > > Since I first got lilypond going, I've been learning how to use it by transcribing >audio into .ly files. This takes me back to my early music studies, except that then >I had to do it by hand! > > Those musical studies are a long way behind now, though, and - while I'm pleased to >have the ability to be able to do this at all - I'm conscious of the fact that I'm >probably not doing it in the best/most efficient way: on the other hand, never having >been formally shown how to do this (as a string player, I was spared having to learn >piano staff notation, etc., etc), reducing to piano score, for example, becomes quite >a tricky task. > > Do others on the list do similar stuff, and does anyone have any tips on how to make >the task quicker, easier and/or more accurate? Or pointers to books/web pages on the >subject? > > I'm aware that this isn't _strictly_ a lilypond issue, but this is about as suitable >a forum as I think I'm likely to find... > > -- > Stephen Allsopp [EMAIL PROTECTED] > > End of message reached. For your comfort and convenience, we recommend > that you stop reading now. > > ___ > Lilypond-user mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/lilypond-user ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: cleverer stem direction
For what it's worth, when I took music theory, we were advised (and this
is in consonance with numerous music copy tutorial books, I can quote
references for some if needed) to keep stems in one direction when
passing through the middle line of the staff.
Thus, for a scale starting on the bottom line and going to the top, the
middle line stem would be up, because the previous notes' stems had been
going up. Coming back down, the stem would be down, because previous
stems had been down. In this case, Mr. Martelli's case would be
satisfied, as well as those cases where c b a calls for the stem
reversal at a, not b, and c b a b c has the b with stem down first and
then up.
raybro
Laurent Martelli wrote:
>
> \relative c'' { c b c } gives stem up, down and up. I would rather
> have all stems down in such a case. Would it be possible tohave lily
> do that ? The rule would be : if a `b' is between 2 `c' or `d' or `e'
> in the same bar, the stem direction of the b should be the same as the
> previous and next notes.
>
> --
> Laurent Martelli
> [EMAIL PROTECTED] http://www.bearteam.org/~laurent/
>
> ___
> Lilypond-user mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/lilypond-user
___
Lilypond-user mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond user manual in ps
Mats Bengtsson wrote: > > You really shouldn't send these question to me privately, > if you keep them on the list, you'll reach Jan and Han-Wen > who do the bulk of the job and also others who have the same > questions could see the followups. You may quote my answers > below on the list if you wish. My apologies, to Mats and the list. I had intended this to go to the list, and for some reason, my mailer chose Mats name instead of the list address earlier when I asked about the user manual. I'll be more careful in the future. My original has two >'s, Mats' kind responses have one: > > > OK, a slew of ignorant questions, then: > > > > This is the third version of the manual that I've downloaded from > > otherwise identical pages, one 330K, one 339K and this one is 328K. Is > > there any way to tell sites apart? > > Sure, at the bottom of each page you'll find a line with: > This page was built from LilyPond-1.5.3 by ... > > > Why are there so many sites, how are they found, and again, how do you > > associate them with different versions of Lilypond? > > I don't know which ones you've found. The only official ones > I know of are www.lilypond.org for the development versions > and the one at gnu.org for the stable. > I found three: one at http://www.lilypond.org/development/Documentation/out-www/index.html#users, labelled 1.5.3 at the bottom, one at http://www.cs.uu.nl/~hanwen/lilypond-local/ marked LilyPond-1.5.7.hwn1 and the one Mats directed me to that had the `working' lilypond.ps: http://www.cs.uu.nl/~hanwen/lilypond-local/ labelled 1.4.4. Now that I see that, it makes more sense of things. However, the setup.exe that I've downloaded a few times in the past couple of weeks (especially since the mention that 1.4.7 was being considered stable) was from http://www.lilypond.org/development/Documentation/windows/out-www/installing.html which is also labelled 1.5.3, and the latest version of lilypond which it offers for installation is 1.4.5-1. (I hadn't noticed the 1.5.3 label before Mats mentioned it, so while it had been an interesting thing to me that 1.4.7 might be stable, 1.4.5-1 was the latest I could get.) > > How do I get into the 1.5 versions? I am running 1.4.5 right now, which > > is all the setup.exe gets. It would be nice to be at least into the > > versions that put barlines at the end of staves, and maybe even > > paradisical to be working completely within cygwin's python, without the > > windows dependencies. > > I think 1.4.5 is worse than 1.4.4 because of the offset at the > end of each stave. I hope Jan will build a Windows version of > 1.4.7, the latest stable version. At the moment I don't recommend > the 1.5.x series. The only main difference is the handling of > grace notes and that's still too buggy to be really useful. > Don't you get the new Python version now if you run setup.exe? > As said above, the new Python version doesn't appear in the list of possible downloads from running setup.exe. I can only get a response from http://lilypond.org's address, that says that I have 'nothing to download'. If I click on Exp it says the same thing, while prev offers lilypond 1.4.5-jcn1 (along with earlier editions of ash, bash, cygwin, fileutils, gs, gsview, less, sh-utils and tar). So the only lilypond versions available that I can see are 1.4.5-1 and 1.4.5jcn-1. > > Is there a place this information is available without combing through > > 8megs of old messages? some lists I'm on have a monthly mailing that give > > basic information-I'd be glad to do that, but I am (obviously) no expert on > > what that info should be, nor what is the latest and most accurate info to be > > posting. > > The really difficult thing is to know what information is interesting. > The FAQ list and the other parts of the so-called wikiwiki is one > answer to your question. There, anybody can add questions and > answers and you can do a full text search. > > I agree completely that it sometimes is a hard job just to > keep up with the Lilypond news. > > /Mats ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
lilypond user manual in ps
I have downloaded lilypond.ps.gz in the past ( a few months ago ) and had no problem looking at it in gsview[32], but in the last 2 weeks I've downloaded it twice, and gotten something that can't be viewed at all. As a check, I ran it through acrobat 4.0 distiller, and got the following, which matches the complaint from gsview32: Start Time: Monday, August 27, 2001 at 9:59 AM Destination: C:\cygwin\home\raybro\lilypond.pdf Source: lilypond.ps %%[ Error: undefined; OffendingCommand: set_tex_dimen ]%% Stack: (lilypondpaperblotdiameter) /lilypondpaperblotdiameter %[ Flushing: rest of job (to end-of-file) will be ignored ]%% %%[ Warning: PostScript error. No PDF file produced. ] %% Distill Time: 0 seconds (00:00:00) End of Job Is this something new, or has the rest of the ps world moved out from under what should still be a perfectly readable file? raybro ___ Lilypond-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-user
