Am 07.01.2012 23:56, schrieb Janek Warchoł:
2012/1/7 m...@apollinemike.comm...@apollinemike.com:
On Jan 7, 2012, at 1:49 AM, Janek Warchoł wrote:
Hi,
i'm inside Clef_engraver::create_clef () - line 130 of lily/clef-engraver.cc
I'd like to do sth based on the clef type (G, F or C). What
Am 21.01.2012 18:44, schrieb Carl Sorensen:
On 1/21/12 10:37 AM, David Kastrupd...@gnu.org wrote:
I have actually found out that I promised too much about string numbers
appearing on isolated notes: since the string number events _are_
listened to (likely by the tabstaff engraver team), the
Am 21.01.2012 19:41, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Am 21.01.2012 18:44, schrieb Carl Sorensen:
On 1/21/12 10:37 AM, David Kastrupd...@gnu.org wrote:
I have actually found out that I promised too much about string numbers
appearing on isolated notes: since the
Am 21.01.2012 20:17, schrieb Carl Sorensen:
On 1/21/12 11:47 AM, Marc Hohlm...@hohlart.de wrote:
I must admit that I am lost here and do not quite understand what's
going on,
but will there be any difference between
c\3 e\2 g\1 and c e g\3\2\1
once these changes are implemented?
The
Am 29.01.2012 10:35, schrieb mts...@gmail.com:
Reviewers: ,
Message:
The idea here is to create a generic framework that allows for
modifications to note lengths (i.e. swing) in the MIDI without having a
typographical impact on the score.
Brilliant idea, from my rather amatheurish point of
Am 31.01.2012 08:52, schrieb m...@apollinemike.com:
On Jan 31, 2012, at 8:48 AM, Marc Hohl wrote:
Am 29.01.2012 10:35, schrieb mts...@gmail.com:
Reviewers: ,
Message:
The idea here is to create a generic framework that allows for
modifications to note lengths (i.e. swing) in the MIDI without
Am 31.01.2012 09:09, schrieb m...@apollinemike.com:
On Jan 31, 2012, at 8:59 AM, Marc Hohl wrote:
Am 31.01.2012 08:52, schrieb m...@apollinemike.com
mailto:m...@apollinemike.com:
On Jan 31, 2012, at 8:48 AM, Marc Hohl wrote:
Am 29.01.2012 10:35, schrieb mts...@gmail.com
mailto:mts
Am 31.01.2012 09:28, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Am 31.01.2012 08:52, schrieb m...@apollinemike.com:
On Jan 31, 2012, at 8:48 AM, Marc Hohl wrote:
Am 29.01.2012 10:35, schrieb mts...@gmail.com:
Reviewers: ,
Message:
The idea here is to create a generic
Am 31.01.2012 10:57, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Am 31.01.2012 09:09, schrieb m...@apollinemike.com:
Check out:
http://crism.maden.org/music/swing.ly
This is a function that takes music and returns two musics, one
swung and one unswung, w/ appropriate tags for
Am 31.01.2012 10:56, schrieb m...@apollinemike.com:
[...]
I wrote my own set of Scheme functions based on this method that got all the
swing I needed into a score.
Would you mind to post these functions?
I am currently working on a project that needs swing articulation, so I
would be glad to
Am 01.02.2012 11:06, schrieb padovani:
Em 2/1/12 6:34 AM, Marc Hohl escreveu:
Am 31.01.2012 21:55, schrieb padovani:
hello,
I'm having troubles with 2.15.27 and OSX 10.7.2.
In a simple piece of code using fonts like Texier's Controla
(http://christian.texier.pagespro-orange.fr/mididesi/free
Am 05.02.2012 18:51, schrieb Thomas Morley:
[...]
I added \voiceOne near the end of the first voice. Of course this
changes the stem-direction (which I'd prefer) but Graham told not to
change the output.
IIRC, the definition for calc-extra-dy is included in the source
as
Am 05.02.2012 20:16, schrieb Marc Hohl:
Am 05.02.2012 18:51, schrieb Thomas Morley:
[...]
I added \voiceOne near the end of the first voice. Of course this
changes the stem-direction (which I'd prefer) but Graham told not to
change the output.
IIRC, the definition for calc-extra-dy
Hello all,
while typesetting a piece for two guitars, I stumbled across
the influence of the commit mentioned above.
Before that,
something like
\set minimumFret = #2
dis'8 ( e' dis ) h fis2
worked smoothly out of the box, now I have to tell
lilypond explicitly which string to use when I
Am 14.02.2012 09:58, schrieb Marc Hohl:
Hello all,
while typesetting a piece for two guitars, I stumbled across
the influence of the commit mentioned above.
Before that,
something like
\set minimumFret = #2
dis'8 ( e' dis ) h fis2
worked smoothly out of the box, now I have to tell
lilypond
Am 14.02.2012 21:01, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Am 14.02.2012 09:58, schrieb Marc Hohl:
+\set TabStaff.handleOpenStrings = #'forbid
+ g, d1
+ }
+}
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index 6335ab6..11181d3 100644
--- a/ly/engraver-init.ly
Am 14.02.2012 21:18, schrieb Marc Hohl:
Am 14.02.2012 21:01, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Am 14.02.2012 09:58, schrieb Marc Hohl:
+\set TabStaff.handleOpenStrings = #'forbid
+ g, d1
+ }
+}
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index 6335ab6
Mon Sep 17 00:00:00 2001
From: Marc Hohl m...@hohlart.de
Date: Tue, 14 Feb 2012 20:43:10 +0100
Subject: [PATCH] Handling of open strings in tablature
This patch creates a switch called handleOpenStrings which is set
to 'allow by default which allows the fret calculation routine to use
open strings
and \harmonicByRatio.
Patch is attached, but I have no push privileges.
Thanks for your work!
Regards,
Marc
From b56abfe0b25fdab0cf47388bbc7abbf9b6b31cc4 Mon Sep 17 00:00:00 2001
From: Marc Hohl m...@hohlart.de
Date: Fri, 17 Feb 2012 09:59:58 +0100
Subject: [PATCH] Improving \harmonicBy
Am 23.02.2012 14:35, schrieb d...@gnu.org:
On 2012/02/23 12:37:04, MikeSol wrote:
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc#newcode932
Am 23.02.2012 15:59, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
As the person who wrote a lot of stuff for tablature and removed the
stems and stuff by default,
made them transparent
Yes, of course ;-)
I second that it is an ugly workaround.
Ideally, I had removed the
Am 24.02.2012 09:30, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Hello list,
there are two tiny patches concerning open strings and harmonics in
tablature:
http://lists.gnu.org/archive/html/lilypond-devel/2012-02/msg00541.html
touching the strings above fret is misleading.
Am 24.02.2012 10:19, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Am 24.02.2012 09:30, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Hello list,
there are two tiny patches concerning open strings and harmonics in
tablature:
Am 24.02.2012 15:32, schrieb d...@gnu.org:
http://codereview.appspot.com/5695059/diff/1001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/5695059/diff/1001/ly/music-functions-init.ly#newcode393
ly/music-functions-init.ly:393:
Am 26.02.2012 07:07, schrieb julien.ri...@gmail.com:
1 line adds whitespace errors. That's all.
Regards,
Julien
http://codereview.appspot.com/5695058/diff/6001/input/regression/tablature-open-string-handling.ly
File input/regression/tablature-open-string-handling.ly (right):
Am 27.02.2012 10:01, schrieb d...@gnu.org:
On 2012/02/27 00:17:05, Carl wrote:
Looks like a good solution.
I think I would prefer the name excludeOpenStrings to
ignoreOpenStrings.
I think exclude is a better word for what is happening than ignore
I am actually not all too happy with
Am 27.02.2012 12:09, schrieb d...@gnu.org:
On 2012/02/27 10:51:25, marc wrote:
I hope I corrected everything accordingly, because I screwed up my
local
branch ... :-(
That's quite improbable to do thoroughly with git.
Well, I did it.
I don't know what happened, but most probably a git
Am 27.02.2012 12:19, schrieb d...@gnu.org:
Instead of dontTreatOpenStringsSpecially, something like omitOpenStrings
Well, omitOpenStrings sounds quite good IMHO. Before I do another patch,
any suggestions/corrections from other string-addicted people ;-) ?
Regards,
Marc
or skipOpenStrings
Hello list,
I want to rewrite most if not all definitions currently settled in
lily/bar-line.cc in scheme. Please see the attached file for my
progress so far; I don't get any error messages, but no bar lines either :-(
Is this a feasible approach? What am I currently doing wrong?
Thanks for
Am 20.03.2012 10:19, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Hello list,
I want to rewrite most if not all definitions currently settled in
lily/bar-line.cc in scheme. Please see the attached file for my
progress so far; I don't get any error messages, but no bar lines
Am 21.03.2012 03:20, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Is this a feasible approach? What am I currently doing wrong?
#(define bar-line-stencil-alist
'((| . thin-stil)
(. . thick-stil)
( . empty-stil)
))
(thin-stil
Am 21.03.2012 11:03, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Am 21.03.2012 03:20, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Is this a feasible approach? What am I currently doing wrong?
#(define bar-line-stencil-alist
'((| . thin-stil)
(. .
Am 21.03.2012 02:11, schrieb Thomas Morley:
Hi Marc,
Some observations:
the main problem seems to be the storing of the new stencils in an
alist and how to call them. Directly in bar-line::compound-bar-line
works.
Ok, this is what David explained to me, too.
Also, I created
Am 21.03.2012 11:43, schrieb David Kastrup:
Marc Hohlm...@hohlart.de writes:
Anyway, I don't get the case statement right - am I too stupid?
Stupid enough to follow my advice without checking the manual first (or
afterwards). Looking in the Guile manual, it turns out that case uses
eqv? for
Am 21.03.2012 21:39, schrieb Nicolas Sceaux:
Le 20 mars 2012 à 09:39, Marc Hohl a écrit :
Hello list,
I want to rewrite most if not all definitions currently settled in
lily/bar-line.cc in scheme. Please see the attached file for my
progress so far; I don't get any error messages, but no bar
Am 21.03.2012 21:39, schrieb Nicolas Sceaux:
Le 20 mars 2012 à 09:39, Marc Hohl a écrit :
Hello list,
I want to rewrite most if not all definitions currently settled in
lily/bar-line.cc in scheme. Please see the attached file for my
progress so far; I don't get any error messages, but no bar
Hello list,
while analyzing and rewriting Bar_line::compound_barline in scheme
I stumbled across an inconsistency:
In Bar_line::print, the function compound_barline is called only if
the length of bar-extent is 0.
In Bar_line::compound_barline, there is
h = extent.length ();
and later
if
Am 26.03.2012 12:15, schrieb James:
Hello
On 25 March 2012 14:10, Phil Holmesem...@philholmes.net wrote:
In Notation/wind.itely, please could the following be changed:
Die Liste aller möglichen Löcher und Einstellungen eines bestimmten
Instruments kann auf der Kommandozeile oder in einer
Am 05.04.2012 14:02, schrieb Aleksandr Andreev:
Hello list,
I'm back to trying to work on this issue after a bit of a hiatus.
The problem is how to get the staff lines to stop printing before the
Kievan bar line appears:
http://code.google.com/p/lilypond/issues/detail?id=2344
I've been
Am 05.04.2012 14:39, schrieb Aleksandr Andreev:
Wouldn't it be easier to draw a white box underneath the kievan glyph?
Can that be done with the same Stencil object?
Have a look at lily/grob.cc where the whiteout handling is defined.
I don't know if this is of interest for you, but I am
Hello list,
as issue 1320 is labeled as 'frog', I thought it would be a good idea
to dig deeper into scheme and c++ by rewriting most parts of
lily/bar-line.cc
and lily/span-bar.cc
It was not as easy and straightforward as I thought, because there were
some cross-references between the two
Am 06.04.2012 23:04, schrieb Carl Sorensen:
On 4/5/12 12:51 PM, Marc Hohlm...@hohlart.de wrote:
Does it make sense to replace the definitions in bar-line.cc/span-bar.cc
with the scheme equivalents? If yes, I'd draw a patch and would include
one example for integrating user-defined bar lines
Am 07.04.2012 01:03, schrieb Thomas Morley:
Am 6. April 2012 23:04 schrieb Carl Sorensenc_soren...@byu.edu:
On 4/5/12 12:51 PM, Marc Hohlm...@hohlart.de wrote:
Does it make sense to replace the definitions in bar-line.cc/span-bar.cc
with the scheme equivalents? If yes, I'd draw a patch and
Am 08.04.2012 15:38, schrieb Thomas Morley:
Am 7. April 2012 16:06 schrieb Marc Hohlm...@hohlart.de:
How shall we proceed? I am short of time now (I have to move with my familiy
into
another house by the end of april, perhaps even one or two weeks earlier),
Well, that's the main problem for
Am 15.04.2012 12:06, schrieb Federico Bruni:
Il 15/04/2012 11:00, James ha scritto:
Federico, it seems you have the ability (and knowledge) to create a
tracker yourself so I suggest that if issue 1459 is fixed you change
the label to fixed - someone else will verify - and then create a new
Am 16.04.2012 23:25, schrieb Federico Bruni:
Il 16/04/2012 12:24, Marc Hohl ha scritto:
if you create a patch, I think you can remove the
Stem #'transparent = ##t
in the definition of TabVoice in ly/engraver-init.ly, because the stems
have
now length zero, so this is superfluous
Am 16.05.2012 05:23, schrieb Colin Campbell:
[...]
Issue 2497 http://code.google.com/p/lilypond/issues/detail?id=2497:
restrainOpenStrings: please fix snippet in
Documentation/notation/fretted-strings.itely - R 6206072
http://codereview.appspot.com/6206072/
[...]
Issue 1320
Happy birthday,
alles Gute zum Geburtstag!
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Am 04.06.2012 09:14, schrieb Janek Warchoł:
Hi,
On Sun, Jun 3, 2012 at 10:58 PM, Thomas Morley
thomasmorle...@googlemail.com wrote:
together with Marc Hohl I was working on Issue 1320 for a couple of weeks.
Now we have a first working version using a new approach to design BarLines:
wow
Am 04.06.2012 13:21, schrieb Janek Warchoł:
On Mon, Jun 4, 2012 at 10:55 AM, David Kastrupd...@gnu.org wrote:
Werner LEMBERGw...@gnu.org writes:
Uh, oh, please not a letter. I almost always use seriffed fonts, and
it looks rather strange. What slightly longer but easy to remember
Am 04.06.2012 17:13, schrieb Graham Percival:
On Mon, Jun 04, 2012 at 05:01:44PM +0200, Marc Hohl wrote:
Am 04.06.2012 13:21, schrieb Janek Warchoł:
How about ! then? It actually has both | and . in it, and it _is_ a
sentence ending punctuation.
I missed something; why not keep
Hi all,
Am 03.06.2012 22:58, schrieb Thomas Morley:
Hi,
together with Marc Hohl I was working on Issue 1320 for a couple of weeks.
Now we have a first working version using a new approach to design BarLines:
Only simple BarLines are predefined e.g | . : etc (plus some
exceptions).
Some
Am 05.06.2012 08:29, schrieb Marc Hohl:
Hi all,
Am 03.06.2012 22:58, schrieb Thomas Morley:
Hi,
together with Marc Hohl I was working on Issue 1320 for a couple of
weeks.
Now we have a first working version using a new approach to design
BarLines:
Only simple BarLines are predefined e.g
Am 11.06.2012 13:14, schrieb lilyp...@googlecode.com:
Updates:
Status: Fixed
Labels: -Patch-push Fixed_2_15_41
Comment #7 on issue 2580 by philehol...@gmail.com: Apparent mistake in
output-lib.scm - fine barglyph-alist
http://code.google.com/p/lilypond/issues/detail?id=2580
Pushed as
Hello list,
I decided to split the bar line issue in two parts.
The first step is to move the main routines from c++ to Scheme,
the second step covers the user interface.
Some issues with the patch:
(*) Please have a look at lily/span-bar.cc.
Is Span-bar::center_on_spanned_callback used
/6305115/diff/1/scm/bar-line.scm#newcode495
scm/bar-line.scm:495: ;; bulky side. Rewritten by Han-Wen. Ported from
c++ to Scheme by Marc Hohl.
Can you get this down to the 80 character line width?
Done.
http://codereview.appspot.com/6305115
Am 20.06.2012 21:34, schrieb benko@gmail.com:
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm#newcode83
scm/bar-line.scm:83: (define (make-colon-bar-line grob)
I'm afraid this defun
Hello list,
the following snippet prints a value of 5 in both cases,
whereas the second system has
only four staff lines. What's wrong here?
Regards,
Marc
\version 2.15.41
#(define (test-bar-print grob)
(let* ((staff-symbol (ly:grob-object grob 'staff-symbol))
(line-count (if
Am 22.06.2012 10:29, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
Hello list,
the following snippet prints a value of 5 in both cases,
whereas the second system has
only four staff lines. What's wrong here?
Regards,
Marc
\version 2.15.41
#(define (test-bar-print grob)
(let
Am 22.06.2012 10:49, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
You are only overriding line-positions. While the bar line printer will
see that this now contains a value and heeds it, this does not magically
affect the (now ignored) line-count property.
Ah, I see, thanks
Am 22.06.2012 11:33, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
Ok, but in lily/bar-line.cc, Bar_line::compound_barline, the number
of lines is computed by
int lines = Staff_symbol_referencer::line_count (me)
which is defined as
int
Staff_symbol_referencer::line_count (Grob
Am 22.06.2012 10:49, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
You are only overriding line-positions. While the bar line printer will
see that this now contains a value and heeds it, this does not magically
affect the (now ignored) line-count property.
Ah, I see, thanks
Am 23.06.2012 11:06, schrieb Benkő Pál:
hi Marc,
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm#newcode83
scm/bar-line.scm:83: (define (make-colon-bar-line grob)
I'm afraid this defun
Am 23.06.2012 11:11, schrieb Marc Hohl:
Am 23.06.2012 11:06, schrieb Benkő Pál:
hi Marc,
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm#newcode83
scm/bar-line.scm:83: (define (make
Am 27.06.2012 14:14, schrieb Graham Percival:
On Tue, Jun 26, 2012 at 11:13:21PM +0200, David Kastrup wrote:
Düsseldorf -- Dortmund -- 45 minutes hourly
Sounds good. Ok, I'm in as long as we have at least 3 developers
other than myself. So far there's David and Werner.
Well, I do not count
Am 29.06.2012 08:05, schrieb m...@apollinemike.com:
On 26 juin 2012, at 18:26, David Kastrup wrote:
Graham Percival gra...@percival-music.ca writes:
Mailing list arguments are a trickier issue. It’s clearly a big
problem, but this isn’t something we can fix by waving a change of
policy. I’ll
Hello list,
while still working on Issue 1320, I found out that
the functions defined in lily/span-bar.cc
Span_bar::center_on_spanned_callback
and
Span_bar::get_spanned_interval
are apparently not used since
SHA1 ID 4995fea559cd5399b4f462de546a15195d76f4c3
dated 2001-06-29.
Is it ok to
Original-Nachricht
Betreff: Re: Questions about Issue 1320: Scheme bar line interface
(issue 6305115)
Datum: Wed, 4 Jul 2012 06:48:56 +0200
Von:m...@apollinemike.com m...@apollinemike.com
An: Marc Hohl m...@hohlart.de
Hey Mark,
This is because, in this instance, you
Am 04.07.2012 13:29, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
Hello list,
the topic is somewhat over my head, but perhaps someone with more
insight can answer this question?
I think that gcc likely can, don't know about g++, and we don't want to
rely on it anyhow.
Ok.
Well
Hello Mike,
Am 05.07.2012 00:37, schrieb m...@apollinemike.com:
[...]
I just realized that there's an easier way to do this w/ existing code
conventions. You can overload Pointer_group_interface::find_grob so that it
accepts a simple closure as the third argument. Then, wrap the Scheme
Am 05.07.2012 08:14, schrieb Joe Neeman:
On Thu, Jul 5, 2012 at 12:37 AM, m...@apollinemike.com
mailto:m...@apollinemike.com m...@apollinemike.com
mailto:m...@apollinemike.com wrote:
On 4 juil. 2012, at 20:10, Marc Hohl wrote:
Am 04.07.2012 13:29, schrieb David Kastrup:
Marc
...@apollinemike.com
mailto:m...@apollinemike.com m...@apollinemike.com
mailto:m...@apollinemike.com wrote:
On 4 juil. 2012, at 20:10, Marc Hohl wrote:
Why not just leave the function in C++? I have nothing against
porting things to scheme, but in this case it just seems like
Am 06.07.2012 09:51, schrieb David Kastrup:
Joe Neeman joenee...@gmail.com writes:
I think it's exercises like that that help strengthen the Scheme
bindings and thus lead to more customizability/extensibility.
In this case, I disagree. The function in question is used in 2 places
Am 06.07.2012 18:06, schrieb Joe Neeman:
[...]
The semi-trivial C++ function is _not_ useful for the scheme code. It
is used in two parts of the C++ code. However, because it belonged to
the same file as various other functions that were being ported, Marc
was planning to port this
with harm6 and Marc Hohl on this toppic, I had a look to the 'end
hook suppression on the volta brackets based on the barline type'. There I
worked to move the 'list of bar lines' from C++ source code to a staff
context property.
Next I had the idea to suppress the 'repeated triggers due to grace
Am 16.07.2012 19:31, schrieb lilyp...@googlecode.com:
Updates:
Labels: -Patch-new Patch-needs_work
Comment #30 on issue 1320 by colinpkc...@gmail.com: Enhancement:
user-customizable barlines through a Scheme interface.
http://code.google.com/p/lilypond/issues/detail?id=1320#c30
Patchy
Am 17.07.2012 00:58, schrieb k-ohara5...@oco.net:
Wherever there is an empty bar-line, \bar , this patch reserves too
much space for the bar-line. Possibly the extent of empty bar-lines is
computed wrongly.
Obviously, I swapped the x- and y-coordinates within the definition
of
Hello list,
I tried to follow the instructions on
http://lilypond.org/doc/v2.15/Documentation/contributor/working-with-remote-branches
Since I have now push access and I am supposed to push to staging,
I tried to create a local branch called 'staging' and I did
git config --add
Am 17.07.2012 21:48, schrieb m...@hohlart.de:
The regression test
span-par-allow-span-bar.ly
Should read
span-bar-allow-span-bar.ly
;-)
After
make test-redo; make check
I still see some small differences between master and my patch.
I think the differences concerning MIDI output can
Am 20.07.2012 12:24, schrieb d...@gnu.org:
On 2012/07/20 10:15:41, marc wrote:
I think the differences concerning MIDI output can safely be
ignored,
What makes it safe to ignore them?
Well, I don't know.
But diffs like
@@ -1,4 +1,5 @@
Parsing...
+Renaming input to:
Am 20.07.2012 12:26, schrieb Phil Holmes:
[...]
It might be worth your comparing the differing output by eye - the
regtest checker only gives a rough idea of where the differences lie.
Failing that, I think I could create a windows .exe if the patch was
in an accessible branch on git, and
Am 20.07.2012 20:17, schrieb Marc Hohl:
Am 20.07.2012 12:24, schrieb d...@gnu.org:
On 2012/07/20 10:15:41, marc wrote:
I think the differences concerning MIDI output can safely be
ignored,
Thinko – IIUC, not the MIDI output is changed, only the log file.
Regards,
Marc
http
Am 17.07.2012 17:51, schrieb Keith OHara:
On Mon, 16 Jul 2012 22:42:55 -0700, gra...@percival-music.ca wrote:
regtest
I'm expanding `alignment-order.ly` after the patchy test.
I think that my current redefinition already includes the sorting
(see lines 578/579 of
Am 20.07.2012 20:28, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
Am 20.07.2012 12:24, schrieb d...@gnu.org:
On 2012/07/20 10:15:41, marc wrote:
I think the differences concerning MIDI output can safely be
ignored,
What makes it safe to ignore them?
Well, I don't know
Am 20.07.2012 21:15, schrieb Benkő Pál:
Marc, please don't throw the whole 2533 issue stuff out;
look at the newer version at
http://codereview.appspot.com/6431044
p
Pál, thanks for the hint – I stored the changes I made
before the revert of your patch ;-)
Obviously, I have do rework some
Am 20.07.2012 23:43, schrieb Keith OHara:
On Fri, 20 Jul 2012 11:38:34 -0700, Marc Hohl m...@hohlart.de wrote:
I think that my current redefinition already includes the sorting
(see lines 578/579 of
http://codereview.appspot.com/6305115/diff/30001/scm/bar-line.scm)
I don't read Scheme
Am 20.07.2012 23:16, schrieb k-ohara5...@oco.net:
Works fine for me, but it will need updated to synchronize with the
patches soon-to-be-pushed to the C version.
Ok.
Since the C code is getting bug-fixes and improvements at the same time
as you port to Scheme, you should incorporate the
Am 20.07.2012 21:03, schrieb d...@gnu.org:
http://codereview.appspot.com/6305115/diff/30001/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6305115/diff/30001/scm/bar-line.scm#newcode649
scm/bar-line.scm:649:
Empty line at end of file makes git complain about
Am 21.07.2012 15:02, schrieb lilyp...@googlecode.com:
Updates:
Labels: -Patch-new Patch-needs_work
Comment #35 on issue 1320 by d...@gnu.org: Enhancement:
user-customizable barlines through a Scheme interface.
http://code.google.com/p/lilypond/issues/detail?id=1320#c35
Patchy the autobot
Am 23.07.2012 10:30, schrieb Marc Hohl:
[...]
The x-extent of all bar lines is identical except for the dashed
bar line (the newer version is centered around x=0, but the width is
identical),
so IIUC, rounding errors may not a problem here.
Corrected in the latest patch set.
Interestingly
Am 23.07.2012 23:45, schrieb k-ohara5...@oco.net:
Looks like LilyPond defines two line-thicknesses,
one for staff-line thickness in each StaffSymbol,
and one (confusingly called staffline in C) for bar-line width in
paper.scm.
Thanks for your explanation! Indeed, staffline is not the
best
Am 24.07.2012 13:53, schrieb lilyp...@googlecode.com:
Updates:
Labels: -Patch-new Patch-review
Comment #40 on issue 1320 by d...@gnu.org: Enhancement:
user-customizable barlines through a Scheme interface.
http://code.google.com/p/lilypond/issues/detail?id=1320#c40
Patchy the autobot
Am 26.07.2012 09:51, schrieb benko@gmail.com:
Marc, please don't throw the whole 2533 issue stuff out; look at the
latest version at
http://codereview.appspot.com/6431044
in particular bar-line.cc and repeat-sign.ly.
I really don't mind if your patch goes before mine (it would even be
Am 26.07.2012 10:31, schrieb Keith OHara:
On Thu, 26 Jul 2012 00:51:56 -0700, benko@gmail.com wrote:
Marc, please don't throw the whole 2533 issue stuff out; look at the
latest version at
http://codereview.appspot.com/6431044
in particular bar-line.cc and repeat-sign.ly.
I really don't
Hi list,
this is the time for my first patch to be pushed by myself ;-)
... and it doesn't work.
I followed the instructions at
http://lilypond.org/doc/v2.15/Documentation/contributor/git-for-the-impatient
My work is on barlineI, so I did
(on master)
git pull
git checkout barlineI
git rebase
Am 27.07.2012 08:45, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
this is the time for my first patch to be pushed by myself ;-)
... and it doesn't work.
I followed the instructions at
http://lilypond.org/doc/v2.15/Documentation/contributor/git-for-the-impatient
My work
Am 27.07.2012 09:01, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
[remote origin]
url = git://git.sv.gnu.org/lilypond.git/
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/staging:refs/remotes/origin/staging
So I think I am not using http
Am 27.07.2012 09:16, schrieb Trevor Daniels:
Marc Hohl wrote Friday, July 27, 2012 8:11 AM
I must admit that I am not very familiarwith the whole ssh stuff – is
there anything I can do
to make it work? The git instructions on
http://lilypond.org/doc/v2.15/Documentation/contributor
don't seem
Am 27.07.2012 11:07, schrieb Phil Holmes:
- Original Message - From: Marc Hohl m...@hohlart.de
To: Trevor Daniels t.dani...@treda.co.uk
Cc: David Kastrup d...@gnu.org; lilypond-devel@gnu.org
Sent: Friday, July 27, 2012 8:28 AM
Subject: Re: git push doesn't work
I have saved my public
Am 27.07.2012 12:28, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
After Trevor's mail, I found out that I already *had*
.ssh/config|id_rsa|id_rsa.pub etc.
due to some ssh connections to other servers a friend of mine created for me
(I was sitting next to him, but apparently he can
1 - 100 of 620 matches
Mail list logo
