Re: check-translation not working
Le samedi 11 août 2007 à 13:21 +0300, Till Rettig a écrit : Hi, another problem is that check-translation script is not working for me. It throws following message: [EMAIL PROTECTED]:~/Documents/Lilypond/compile/Documentation$ make ISOLANG=de check-translation find de/user/ -maxdepth 1 -name '*.*te??' | xargs /usr/bin/python ../buildscripts/check_translation.py ../buildscripts de/index.html.in ../buildscripts/check_translation.py:26: DeprecationWarning: raising a string exception is deprecated raise translated + ': no GIT committish: hash found' Traceback (most recent call last): File ../buildscripts/check_translation.py, line 88, in module main () File ../buildscripts/check_translation.py, line 85, in main do_file (i, langdefs) File ../buildscripts/check_translation.py, line 47, in do_file check_file (original, translated) File ../buildscripts/check_translation.py, line 26, in check_file raise translated + ': no GIT committish: hash found' de/index.html.in: no GIT committish: hash found make: *** [check-translation] Fehler 123 I guess this is about python version 2.5, No, the line saying de/index.html.in: no GIT committish: hash found is the meaningful error message (I admit it's a bit hidden by other less meaningful lines, I'm going to fix this). The first lines of de/index.html.in are html !-- Translation of GIT committish: FILL-IN-HEAD-COMMITTISH so you have the answer ;-) Update de/index.html.in manually by checking it entirely against the original in English, then fill in HEAD committish. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problems with compiling the documentation
Le samedi 11 août 2007 à 13:14 +0300, Till Rettig a écrit : Hello everybody, I just tried to compile the documentation from git master branch. First it gave an error about a missing epsf.tex file that collated-files.tely in input/manual/out-www needed. I found that my version of texlive had only installed xepsf.tex. So I linked it to the name epsf.tex and everything was fine. Would it be possible to let search for both versions of the file? It seems xepsf.tex if compatible. Which Texlive version do you have? I have Texlive 2007 on my box, and it includes epsf.tex. Maybe you need to upgrade to 2007 or rerun Texlive setup to install the package providing epsf.tex. Then compilation stopped at buildscripts/post-www.py whith following message: /usr/bin/python ./buildscripts/www_post.py LilyPond 2.11.29 ./buildscripts ./out-www offline Traceback (most recent call last): File ./buildscripts/www_post.py, line 14, in module package_name, package_version, buildscript_dir, localedir, outdir, targets = sys.argv[1:] ValueError: need more than 5 values to unpack Argument localedir is obviously missing in www_post invocation, which is quite strange. GNUmakefile.in from Git HEAD contains $(PYTHON) $(buildscript-dir)/www_post.py $(PACKAGE_NAME) $(TOPLEVEL_VERSION) $(buildscript-dir) $(top-build-dir)/Documentation/po/$(outdir) $(outdir) $(WEB_TARGETS) Please check you have the same command line in GNUmakefile. If it's OK, then there might be a problem with $(top-build-dir); in the case you have moved the source and build tree, make sure you have rerun configure. Please report any succesful or unsuccesful experience, so you can start updating the docs ;-) I saw the change making the amount of values six was introduced in February, and I have successfully compiled with that, so is it about my python? I have 2.5 installed (with Ubuntu 7.04) but also 2.4 available. Should it explicitly call 2.4 and that would make the mistake disappear? I use Fedora 7, which comes with Python 2.5, and build the docs almost every day, so Python version is certainly not a problem. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Punctuation after @ref
Le samedi 18 août 2007 à 19:11 +0200, Werner LEMBERG a écrit :
@ref{...} must *always* be followed by punctuation.
Werner, can you tell what the real rule is?
See below the snippet from the texinfo manual. I haven't yet checked
how to handle languages other than English.
Thanks for the explanation, and sorry for not reading Texinfo manual.
This rule can also apply to French and (I suppose) to other European
languages, although it sometimes sounds too heavy with too much commas.
Well, punctuation after @ref is not an issue for translated docs until
Info has i18n support*, as we currently don't generate Info files of
translated docs.
* see Texinfo TODO list to see what I mean, I also plan to send precise
i18n-related feature requests when they become clear in my mind.
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update to LSR example
Hello Mats, 2007/8/16, Mats Bengtsson [EMAIL PROTECTED]: I'd like to replace the existing LSR example entitled Feathered beams with the following more extensive example. Thank you very much Mats; I've modified the existing snippet: http://lsr.dsi.unimi.it/LSR/Item?id=239 I clearly remember that Graham has mentioned the recommended procedures for updating existing examples, but I cannot find that email for the moment, so I post it here hoping that Graham or Cameron or whoever has the access rights to do the change. Whoever meaning myself, I guess :) In such a case, what I recommend is to post your snippet as a whole new snippet, and specify Feathered beams [corrected] or whatever in the Subject field. Since new snippets are automatically marked as non-approved, it's easy then for me to track it, modify or rename it, delete the deprecated snippet if necessary, and eventually approve the new corrected snippet. By the way, feel free to Cc me whatever LSR-related discussion or mail you find (I'm tuned on -user, -devel and bug-, but I do miss things). Best Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[Fwd: Git User's Survey 2007]
-- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ---BeginMessage--- Hi all, We would like to ask you a few questions about your use of the GIT version control system. This survey is mainly to understand who is using GIT, how and why. The results will be discussed on the git mailing list and published to the GIT wiki at http://git.or.cz/gitwiki/GitSurvey2007 We'll close the survey in three weeks starting from 20 August 2007, on 10 September 2007. Please devote a few minutes of your time to fill this simple questionnaire, it will help a lot the git community to understand your needs, what you like of GIT, and of course what you don't like of it. The survey can be found here: http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9 http://tinyurl.com/26774s -- Jakub Narebski ---End Message--- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: installation error with current git
Le dimanche 05 août 2007 à 07:25 +0200, Werner LEMBERG a écrit : I believe this is due to the reorganization of the info files; in file `/usr/local/share/info/dir' I see the following entries now: LilyPond * abc2ly: (lilypond/lilypond-program)Invoking abc2ly. Importing ABC. * convert-ly: (lilypond/lilypond-program)Invoking convert-ly. Older LilyPond versions. * etf2ly: (lilypond/lilypond-program)Invoking etf2ly. Importing Finale. * lilypond-book: (lilypond/lilypond-program)LilyPond-book. Itegrating text and music. * midi2ly: (lilypond/lilypond-program)Invoking midi2ly.Importing MIDI. * mup2ly: (lilypond/lilypond-program)Invoking mup2ly. Importing Mup. This should be taken care of, I think... I've removed the obsolete references to mup2ly, now getting install-info --remove --info-dir=/usr/local/share/info ./out/lilypond.info install-info --info-dir=/usr/local/share/info ./out/lilypond.info install-info: menu item `midi2ly' already exists, for file `lilypond/lilypond-program' John, can you fix this, please? I'm using texinfo 4.8, in case this is of importance (which I don't believe). The problem was, lilypond.info also contains entries for lilypond-program.info. This should be fixed in Git now. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH]: musicxml2ly: Don't crash when a score does not have a key or clef set
Reinhold Kainhofer escreveu: Attached is another git patch for musicxml2ly to make it not crash, when a score does not have a key or a clef set in the .xml file. Rosegarden produces such files. Cheers, Reinhold +children = None should be [] +try: +children = attrs.get_named_children (k) +except KeyError: +pass Don't use exceptions here. Looks like class_dict should have another member. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scaling problem
[Using git 2007-08-19 f3734e9]
[Han-Wen, I'm resending this with slightly improved code and wording
to the lilypond-devel list since it seems that you don't have enough
time to answer.]
String numbers usually get put next to (left or right) of notes;
check out the manual on to how to use them - probably you can get
away with disguising your as the text of a StringNumber grob. If you
put the markup vertically (below/above) and move it with
extra-offset, you will get undesirable extra offsets due to notehead
and stem size which may not scale in the way you expect them to.
Ok, here's my next try. Perhaps due to my lack of the deeper
knowledge of lilypond internals, I'm stuck now.
. What must I do to guarantee that the vertical brackets are always
positioned left of the accidentals?
. The vertical positioning of the markup objects in the code below
is done in a very clumsy way, as can be seen easily, but I wasn't
able to find out how I can shift `ly:bracket' vertically. It
appears as if it is always centered relative to the note head it
is attached to.
I would like to do it better; however, it should be done *within*
my `make-vbracket' function because I plan to improve the logic of
the vertical positioning (depending on the note's pitches).
My code (ab)uses the `Fingering' interface -- I think that single
vertical brackets should become a new grob: Just think of vertical
brackets *plus* fingerings...
Werner
==
#(define-public (make-vbracket grob)
(let* ((event (event-cause grob))
(digit (ly:event-property event 'digit))
(mag (magstep (ly:grob-property grob 'font-size)))
(m (if ( digit 0)
(markup #:override (cons 'baseline-skip (* mag 3))
#:column (#:null
#:stencil (ly:bracket Y (cons 0 (* mag (-
digit)))
(* mag 0.2) (* mag 0.4
(markup #:override (cons 'baseline-skip (* mag 1))
#:column (#:stencil (ly:bracket Y (cons 0 (* mag digit))
(* mag 0.2) (* mag 0.4))
#:null)
m))
vbracket =
#(define-music-function (parser location interval) (number?)
Add a vertical bracket, using the given @var{interval} (which can be
negative).
(apply make-music
(append
(list
'FingeringEvent
'origin location)
(list 'digit interval
{
\override Fingering #'text = #make-vbracket
\override Fingering #'padding = #0.2
\set fingeringOrientations = #'(left)
c'-\vbracket #2 es' a'4
c' es'! a'-\vbracket #-3 4
c'-\vbracket #2 es' as'-\vbracket #-3 4
}
{
\set fingeringOrientations = #'(left)
c'-\vbracket #2 es' a'4
c' es'! a'-\vbracket #-3 4
c'-\vbracket #2 es' as'-\vbracket #-3 4
}
\paper {
ragged-right = ##t
}
inline: fingering.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Punctuation after @ref
See below the snippet from the texinfo manual. I haven't yet checked how to handle languages other than English. Thanks for the explanation, and sorry for not reading Texinfo manual. This rule can also apply to French and (I suppose) to other European languages, although it sometimes sounds too heavy with too much commas. At least in German those commas are just fine, and it should be always possible to find a solution to make this look fine, I believe. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problems with compiling the documentation
Hi John, thanks for the answer,
John Mandereau wrote:
Which Texlive version do you have? I have Texlive 2007 on my box, and
it includes epsf.tex. Maybe you need to upgrade to 2007 or rerun
Texlive setup to install the package providing epsf.tex.
Indeed, I installed texlive 2007 after removing the old 2005 that is
included in Ubuntu.
But, there is no epsf.tex, only xepdf.tex. Luckily i know that now so I
just created the link.
Argument localedir is obviously missing in www_post invocation, which is
quite strange. GNUmakefile.in from Git HEAD contains
$(PYTHON) $(buildscript-dir)/www_post.py $(PACKAGE_NAME) $(TOPLEVEL_VERSION)
$(buildscript-dir) $(top-build-dir)/Documentation/po/$(outdir) $(outdir)
$(WEB_TARGETS)
Please check you have the same command line in GNUmakefile. If it's OK,
then there might be a problem with $(top-build-dir); in the case you
have moved the source and build tree, make sure you have rerun
configure.
Please report any succesful or unsuccesful experience, so you can start
updating the docs ;-)
I didn't check that so far, but after all: the build succeeded, so it
might well be a problem of the old texlive and
has nothing to do with python.
I then updated the changes to the index.html.in for German language, I
send you the two patches. Hopefully my lilypond/translation
tree is still clean. After all, also check-translation works now, thanks
for pointing out the problem.
Greetings
Till
From a9a9fc1bc956e22d04a3a0b655ef84f31b59989a Mon Sep 17 00:00:00 2001
From: Till Rettig [EMAIL PROTECTED]
Date: Sun, 19 Aug 2007 17:19:45 +0300
Subject: [PATCH] Changes to de/index.html.in updated
---
Documentation/de/index.html.in | 114 +++-
1 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/Documentation/de/index.html.in b/Documentation/de/index.html.in
index 12e9f77..e906885 100644
--- a/Documentation/de/index.html.in
+++ b/Documentation/de/index.html.in
@@ -1,6 +1,6 @@
html
!--
-Translation of GIT committish: FILL-IN-HEAD-COMMITTISH
+Translation of GIT committish: d4bbdac80e19eb56e2a8b70067bb221c56ee7a39
When revising a translation, copy the HEAD committish of the
version that you are working on. See TRANSLATION for details.
@@ -10,7 +10,7 @@
META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=UTF-8
meta name=aesop content=links
meta name=description
- content=Top-level index to the standard documentation for
+ content=Allgemeiner Index der Standard-Dokumentation fuuml;r
LilyPond @TOPLEVEL_VERSION@
style type=text/css
.navigation { background-color: #e8ffe8;
@@ -51,6 +51,114 @@
a class=title href=user/lilypond/Tutorial.htmlUuml;bung/a
br(Fuuml;r einen ersten Anfang)
+
+lia class=title href=user/music-glossary/index.htmlGlossar/a
+(auf a class=title href=user/music-glossary-big-page.htmleiner groszlig;en Seite/a ~ 1 Mb,
+als a class=title href=user/music-glossary.pdfPDF/a)
+
+ br(Uuml;bersetzung von musikalischen Begriffen vom Englischen in andere Sprachen)
+ /ul
+ /td
+ td class=right-column
+ ul
+li
+ a class=title href=user/lilypond-program/index.htmlProgrammbenutzung/a
+(auf a class=title href=user/lilypond-program-big-page.htmleiner groszlig;en Seite/a,
+als a class=title href=user/lilypond-program.pdfPDF/a)
+ br(Wie das Programm installiert und gestartet wird.)
+
+lia class=title href=../examples.htmlBeispiele/a
+ br(Sehen Sie sich Notationsbeispiele an.)
+
+ /ul
+ /td
+/tr
+tr
+ td valign=baseline class=left-column
+ nbsp;
+ ul
+ li
+a class=title href=user/lilypond/index.htmlBenutzerhandbuch/a
+(auf a class=title href=user/lilypond-big-page.htmleiner groszlig;en Seite/a ~ 4 Mb,
+als a class=title href=user/lilypond.pdfPDF/a)
+ br(Alles uuml;ber LilyPond.)
+
+ li
+ a class=title href=user/lilypond-internals/index.htmlProgrammreferenz/a
+ (auf a class=title href=user/lilypond-internals-big-page.htmleiner groszlig;en Seite/a ~ 1 Mb)
+ br(Definitionen, wie die Standardeinstellungen verauml;ndert kouml;nnen.)
+
+ /ul
+ /td
+ td valign=baseline class=right-column
+ nbsp;
+ ul
+li
+ a class=title href=topdocs/NEWS.htmlNeuigkeiten/a
+ br(Auml;nderungen seit der letzten Hauptversion auf Englisch.)
+
+lia class=title href=../input/lsr/collated-files.htmlSchnipsel/a
+ br(Schnelle Tricks, Tipps und Beispiele.)
+
+ /ul
+
+/tdtr
+tr
+ td valign=baseline class=left-column
+ nbsp;
+ ul
+ lia class=title href=bibliography/index.htmlBibliographie/a
+ br(Weiterführende Information und Literatur uuml;ber Notation.)
+
+li
+ a class=title href=../input/regression/collated-files.htmlRegressionsteste/a (~ 5 Mb, in a class=title href=../input/regression/collated-files.pdfPDF/a)
+ br(Für Entwickler.)
+
+ /ul
+/tdtd class=right-column
Re: musicxml2ly patch: Convert articulations (fermata, staccato, tremolo, etc.)
2007/8/19, Reinhold Kainhofer [EMAIL PROTECTED]:
use {}.get (..)
I was just using the style of the rest of the code...
Certainly, however, the rest of the code is not perfect either.
BTW, what is an easy way to work with git on multiple patches at the same
time? Currently, I'm using git-format-patch origin to get the patches, but
modifying something later on is not possible this way...
I don't understand this question completely. If you modify previous
patches a lot,
it makes more sense to just send the output of
git diff origin HEAD
However, once you get the hang of style issues, there won't be as much
need for all the going back forth with patches.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: musicxml2ly patch for articulations (fermata, staccato, accent, etc.)
2007/8/19, Reinhold Kainhofer [EMAIL PROTECTED]: Grr, each small project has its own coding style (kdepim has spaces inside the parentheses, kdelibs has different style, lilypond another different style). That's so confusing, and I'm mainly used to the kdepim coding style, as that's my main project! Yes, that's unfortunate. We use the GNU coding style, FWIW. Ouch, To be honest, after looking at the style (it's at http://www.gnu.org/prep/standards/standards.html#Formatting, right?), I think it was designed to make it artificially hard to visually parse the code quickly. That's what I always think when starting to work in whatever new coding style there is, but it turns out that this is never true. Furthermore, do I really need to compile all of lilypond just to install a python script, that does not need compiling just installation? No, you don't have to compile anything. I'm just interested in the musicxml related patches. Look under scripts/ and python/ Yes, the scripts are there, but I still need to build lilypond, since during the build the preambles in musicxml2ly.py are inserted ([EMAIL PROTECTED]@ and @relocate-preamble@)... you can run configure and do cp GNUmakefile.in GNUmakefile make -C python make -C scripts that should suffice. BTW, why is TARGET_PYTHON set to /usr/bin/python instead of the usual /usr/bin/env python?\ Good question. I don't know actually. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scaling problem
2007/8/19, Werner LEMBERG [EMAIL PROTECTED]: . What must I do to guarantee that the vertical brackets are always positioned left of the accidentals? huh? I thought they were supposed to be right of them. If you want brackets left of the note, you could try the arpeggio bracket; in that case, the easiest solution, would be to insert another property into the arpeggio bracket c++ code, so you can override the start and end Y position of the bracket. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCHES] musicxml2ly patches revisited
Next round of patches: After Han-Wens comments about coding style (no
exceptions, spaces, etc.), I reworked all my patches so far. Here they are
all again:
-) 0001-Convert-articulations-like-fermata-staccato-tenuto.patch:
Convert articulations like fermata, staccato, tenuto, tremolo (only
single-note tremolo), accents, etc.
These entries in the xml are inside the notation.../notation tags, listed
in the ornaments, technical and articulations tags.
-) 0002-Sorting-of-the-parts-in-the-.ly-output.-Currently-t.patch:
Sorting of the parts in the .ly output. Currently, their order was not first
staff, second staff, third, etc. but seemingly random
Basically, I use the part_list to sort the individual music voices in the
order as they appear in the score before printing them out.
-) 0003-Also-convert-0-in-part-ids-to-Zero-simplify-tha.patch:
Also convert '0' in part ids to 'Zero', simplify that code a bit.
-) 0004-Don-t-crash-when-a-score-does-not-have-an-explicit-k.patch:
Don't crash when a score does not have an explicit key or clef set (e.g.
Rosegarden produces such files).
-) 0005-Convert-dynamic-marks-given-in-a-direction-tag-a.patch:
Convert dynamic marks (given in a direction tag, assigned to the staff at a
given position in xml, not to a note like in lilypond)
In the LilyPondVoiceBuilder, I added a method to store any pending dynamics
and print them out only after the next note or rest (everything with
duration0) is encountered.
Also convert (de-)crescendo (begin/end also given in a direction tag, not
assigned to a particular note)
Comment about broken dynamics, when they appear as first element of a part
before any note (so that no voice_id is known yet).
Cheers,
Reinhold
--
--
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
* K Desktop Environment, http://www.kde.org, KOrganizer maintainer
* Chorvereinigung Jung-Wien, http://www.jung-wien.at/
From ad228b1e645d8f8e0bf0116d784a76f73dbc0a67 Mon Sep 17 00:00:00 2001
From: Reinhold Kainhofer [EMAIL PROTECTED]
Date: Sun, 19 Aug 2007 23:50:29 +0200
Subject: [PATCH] Convert articulations like fermata, staccato, tenuto, tremolo (only single-note tremolo), accents, etc.
These entries in the xml are inside the notation.../notation tags, listed in the ornaments, technical and articulations tags.
---
python/musicexp.py | 29 ++-
python/musicxml.py | 36 +
scripts/musicxml2ly.py | 136
3 files changed, 200 insertions(+), 1 deletions(-)
diff --git a/python/musicexp.py b/python/musicexp.py
index e7b3870..56252f3 100644
--- a/python/musicexp.py
+++ b/python/musicexp.py
@@ -498,7 +498,34 @@ class TieEvent(Event):
def ly_expression (self):
return '~'
-
+
+class ArticulationEvent (Event):
+def __init__ (self):
+self.type = None
+self.force_direction = None
+
+def direction_mod (self):
+dirstr = { 1: '^', -1: '_', 0: '-' }.get (self.force_direction)
+if dirstr:
+return dirstr
+else:
+return ''
+
+def ly_expression (self):
+return '%s\\%s' % (self.direction_mod (), self.type)
+
+
+class TremoloEvent (Event):
+def __init__ (self):
+self.bars = 0;
+
+def ly_expression (self):
+str=''
+if self.bars 0:
+str += ':%s' % (2 ** (2 + string.atoi (self.bars)))
+return str
+
+
class RhythmicEvent(Event):
def __init__ (self):
Event.__init__ (self)
diff --git a/python/musicxml.py b/python/musicxml.py
index 3466473..304b2c6 100644
--- a/python/musicxml.py
+++ b/python/musicxml.py
@@ -450,6 +450,32 @@ class Staff (Music_xml_node):
class Instrument (Music_xml_node):
pass
+class Fermata (Music_xml_node):
+pass
+class Dynamics (Music_xml_node):
+pass
+class Articulations (Music_xml_node):
+pass
+class Accent (Music_xml_node):
+pass
+class Staccato (Music_xml_node):
+pass
+class Tenuto (Music_xml_node):
+pass
+class Tremolo (Music_xml_node):
+pass
+class Technical (Music_xml_node):
+pass
+class Ornaments (Music_xml_node):
+pass
+
+
+class Direction (Music_xml_node):
+pass
+class DirType (Music_xml_node):
+pass
+
+
## need this, not all classes are instantiated
## for every input file.
class_dict = {
@@ -477,6 +503,16 @@ class_dict = {
'type': Type,
'part-list': Part_list,
'staff': Staff,
+'fermata': Fermata,
+'articulations': Articulations,
+'accent': Accent,
+'staccato': Staccato,
+'tenuto': Tenuto,
+'tremolo': Tremolo,
+'technical': Technical,
+'ornaments': Ornaments,
+'direction': Direction,
+'direction-type': DirType
}
def name2class_name (name):
diff --git
Re: [PATCHES] musicxml2ly patches revisited
Reinhold Kainhofer escreveu:
Next round of patches: After Han-Wens comments about coding style (no
exceptions, spaces, etc.), I reworked all my patches so far. Here they are
all again:
Thanks, I've applied them now.
Some minor comments; I would appreciate if you address them before sending more
patches.
{}.get
takes a default argument, so
f = dict.get(key)
if f:
return f
else:
return ''
can be shorter written as
return dict.get(key, '')
- not):
+# +tied | +slur | +tuplet | glissando | slide |
+ # ornaments | technical | articulations | dynamics |
+ # +fermata | arpeggiate | non-arpeggiate |
+ # accidental-mark | other-notation
can you put indents inside the comments,
# foo
# bar
+if wedgetypeval != None:
better:
if wedgetypeval:
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scaling problem
2007/8/19, Han-Wen Nienhuys [EMAIL PROTECTED]:
. What must I do to guarantee that the vertical brackets are always
positioned left of the accidentals?
huh? I thought they were supposed to be right of them. If you want
brackets left of the note, you could try the arpeggio bracket; in that
case, the easiest solution, would be to insert another property into
the arpeggio bracket c++ code, so you can override the start and end Y
position of the bracket.
in 2.11.30 you will be able to do
\relative
{
\arpeggioBracket
\override Arpeggio #'positions = #'(-5 . 5)
d f a\arpeggio
}
and get a bracket with the desired size.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scaling problem
in 2.11.30 you will be able to do
\relative
{
\arpeggioBracket
\override Arpeggio #'positions = #'(-5 . 5)
d f a\arpeggio
}
and get a bracket with the desired size.
This sounds great! However, I need more than a single vertical
bracket in a chord. AFAIK, this is not (easily?) possible with
Arpeggio grobs since it was the first I've tried to use.
inline: vbracket.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
collision barline with accidental
[git 2007-08-19 13d78fe]
While Joe's latest changes to the horizontal spacing are giving good
results, here's a special case where it fails.
Werner
==
\relative c' {
\tieDashed
ces1 ~ |
ces!8 bes ces bes ces bes ces bes |
}
\paper {
ragged-right = ##t
}
inline: barline-accidental.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: collision barline with accidental
While Joe's latest changes to the horizontal spacing are giving good
results, here's a special case where it fails.
\relative c' {
\tieDashed
ces1 ~ |
ces!8 bes ces bes ces bes ces bes |
}
\paper {
ragged-right = ##t
}
BTW, this very example exposes another bug in lilypond: There
shouldn't be a flat on the second ces in the second bar.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
