Re: 2.21.0 released

Great, thanks! That's very good news, and I'm even more excited about it than stable 2.20 release, as there are many new experimental features, and, even if possibly being especially instable at the beginning, I believe many things will happen in the near future. Looking forward to it Torsten

Re: Proposal: Changing tremolo beam gap implementation

Thomas Morley-2 wrote > P.S. I crossposted to devel, not all are subscribed to the user-list I first wanted to ask what users in general think about the gap size. Thomas Morley-2 wrote > Thus I think 'gap should always specify the _white_ space. That's exactly what I had in mind, but the

Re: Running fixcc.py

Hi David, No objections! Probably this is, directly after introduction of new stable, the best opportunity for tidying up and general re-formatting we'll have in years. I'm a bit confused though: starting off with fixcc, you are suddenly talking about fixscm. Is it about cc files, or scm

Re: [LSR 2.20] what to do with #280

Hi Harm, It's the New_fingering_engraver! It will also activate the Script_engraver, that's why the scripts are there from the beginning in newer LilyPond versions, even before explicitly adding the Scrip_engraver. And as long as there are no stems, you get the "script direction not yet known"

Re: [LSR 2.20] #114 (a doc-tagged partcombine-snippet) complains

By the way: this is Issue 5389: partcombine warns about unterminated slur Cheers, Torsten -- Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html

Re: [LSR 2.20] #114 (a doc-tagged partcombine-snippet) complains

Hi Harm, I can't comment on the unterminated slur at the moment, but I think the "Solo II" should never have been there. Thomas Morley-2 wrote > Also, the "Solo II"-text vanishes, see attached images. Why should there be a "Solo II" text at all? Both voices are still present and in action,

Re: Upgrading to current makeinfo

Jean-Charles Malahieude-2 wrote > Furthermore, texi2html doesn't honor French typographic rules regarding > ordinals: you can't use @sup{letter} like 1^er for 1st and I have to type > > @ifnothtml > 256@sup{e}, 512@sup{e} et 1024@sup{e} > @end ifnothtml > @ifhtml > 256e, 512e et 1024e > @end

Re: How to report `FontForge` problems while creating LilyPond fonts

Werner LEMBERG wrote > Yes, and avoiding overlaps everywhere would lead to unnecessarily > complicated code. Tools like FontForge should be used to fix this in > a post-processing stage, exactly as we do. I totally agree. I'm going to fix the cases giving an error. "Don't fix it if it ain't

Re: How to report `FontForge` problems while creating LilyPond fonts

Sorry, my "turn" was a goof: The loop in the outline produced a tiny fissure… Now I've put a bit more effort in it, combining two subpaths at their intersection so that metapost's output will be a plain and simple outline, /exactly/ matching the original turn outline, but without any loops or

Re: How to report `FontForge` problems while creating LilyPond fonts

Werner LEMBERG wrote > The output produced by the `mf2pt1` script to convert METAFONT input files > to Type1 PostScript fonts often contains overlapping glyphs. This should > be > avoided in general.[1] For this reason, `mf2pt1` by default calls > `FontForge` in batch mode to remove overlaps.

Re: converting tabs to spaces in .mf files

Werner LEMBERG wrote > What do you think about converting all tabs in the .mf files to > spaces? I consider this a good idea. On the one hand, we are encouraged /not/ to use tabs. On the other hand, however, especially mf files are full of them and I've often wondered how to behave when

Re: Quarter Note Support for All Languages etc.

Wols Lists wrote > Don't forget that where you use the word "English", I believe the > standard is that you actually *mean* American. Does that have any impact > on your work? > > (For example, your very subject line is not English - if it were it > would read "Crotchet Support ..." :-) Hi Wol,

Quarter Note Support for All Languages etc.

Hello all, I've prepared a patch introducing full quarter note support for all currently existing LilyPond languages. MusicXML import has also been adapted accordingly and was successfully tested with all of the notes in all in all of the languages. The Documentation/notation/*/pitches.itely

Re: New LilyPond contributor: Basia Mroczek

Welcome, Basia, and welcome back, Janek! Good to see young people joining the flock. :) @Karlin: Basia is a Polish affectionate/familiar form of Barbara. It is pronounced "Basha", similar to Masha or Sasha, just with a B in front. "Bahsa Mrotchek" would probably be the anglicised spelling, with

Re: Turkish makam using regular.ly

Hi, Adam and Hans (in alphabetical order), I had to stop to think about it (the key signature problem). *Result: forget about all the fancy tricks, LilyPond can do it out-of-the-box!* It's rather uncommon (to say the least) to spare out a certain scale step from the key signature, so it took a

Re: Turkish makam using regular.ly

Adam Good-3 wrote > Attached is a shortish example showing that Rast and Segah transposition > works great and shows bestenigar and revnaknuma with the fb in the key > signature with two examples of what Bestenigar and Revnaknuma should look > like. Hi Adam, When applying my solution to your

Re: Turkish makam using regular.ly

Hans Åberg-2 wrote > You mean i LilyPond? What version. Yes, in LilyPond resp. LilyPond's notation font Emmentaler. Current developments are done in Version 2.21.0. The new accidentals certainly will not make their way in the soon-to-come stable release 2.20, but I think they should be contained

Re: Turkish makam using regular.ly

Hans Åberg wrote > I do not have any preference about the names. You can see the Smufl names > in the file regularE53smufl.ly I posted. I actually used the SMuFL names to see what accidentals used are missing in Emmentaler. My proposed names are (hopefully) in accordance with LilyPond glyph

Re: Turkish makam using regular.ly

Hans Åberg wrote > If one typesets the file regularE53smufl.ly, one gets output below. Some > single arrow accidentals are also missing in LilyPond, I think. Yes, also single arrow accidentals are missing. Most notably, we'll have to distinguish between the (bigger) standard arrows and the

Re: Turkish makam using regular.ly

Werner LEMBERG wrote > Indeed. I suggest that the tips of the arrows don't cross the staff > lines. Hi Werner, Yes, the by far most difficult task when dealing with arrows (and slahes!) is to avoid them being obscured by the stave lines. The smaller the design size, the bigger the problem.

Re: Turkish makam using regular.ly

Sorry, I forgot to attach an screenshot of some of the future Emmentaler tiny-arrow accidentals. It's not the final design state, there's still some tweaking needed. All the best, Torsten -- Sent from:

Re: Turkish makam using regular.ly

Hans Åberg-2 wrote > One only needs two extra files (below) that define and call the accidental > glyphs in the Bravura.otf font, […] Hi Hans, Nice work! If I understand it correctly, the main reason for switching to Bravura are missing Emmentaler accidental glyphs (obviously the multi-arrowed

Re: define-note-names.scm: Wrong German beh definition???

David Kastrup wrote > So SEMI_FLAT would rather be heh? Heh. Yup. Music can be fun! :) But seriously (this also affects the Scandinavian languages): If b is already a semitone flat, a mere quarter tone flat must be heh. David Kastrup wrote > THREE-Q-FLAT regularly would be heseh? Well,

define-note-names.scm: Wrong German beh definition???

Hello all, Working on a complete set of note names for all languages (including quarter tones the new triple flat/sharp accidentals), I've stumbled over an erroneous German note name definition of "beh". In German (and most Scandinavian languages), B is called h, and there is the exception of

Re: LilyPond Snippet Repository Login/registration problems

James Lowe-3 wrote > Do I need to wait for someone to approve my request for a login? Hi James, No, you don't have to wait. I just tested it by creating a new user (didn't have one yet) and I immediately could log in without any problems. Does it help to close all the browser windows and try

Re: What's up with grob property "skyline-quantizing" ?

David Kastrup wrote > Should we stick with that and just drop the name of the property > altogether? It does not seem like it has been missed all that much... Hi David, For long slurs or (in particular steep ones or ones with strong curvature), it might be desirable to have a better skyline

Re: issue 5319: Make skylines reflect grob rotation (issue 342060043 by torsten.haemme...@web.de)

Oui, mon Général ! ;) Issue #5341 "Urgent corrections to stencil-integral.cc (skylines)" created. -- Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html ___ lilypond-devel mailing list lilypond-devel@gnu.org

Re: issue 5307: Skyline Refinements (Rounded Boxes and Rotated Ellipses) (issue 341140043 by torsten.haemme...@web.de)

David Kastrup wrote > https://codereview.appspot.com/341140043/diff/20001/lily/stencil-integral.cc#newcode393 > lily/stencil-integral.cc:393: for (vsize i = 0; i < (vsize) points.size > () - 1; i++) > Why would the last point not be transformed? Oh, the last point actually is being transformed,

Re: issue 5319: Make skylines reflect grob rotation (issue 342060043 by torsten.haemme...@web.de)

David Kastrup wrote > Once you create a smobbed copy, it must be protected from garbage > collection. > […] > However, it seems that uses here are few enough that you can just do > SCM q = s->smobbed_copy (); > and use unsmob > > (q) where you now use q. Hi David, Many thanks for your review

Re: Microrhythm

Dave Tremblay wrote > However, I wonder if it would be possible to make it play, or at least > display, microrhythms, [...] Hi Dave, MIDI playback of microrhythms (including interpolation between the two notated extremes by applying time-dependent percentages) surely will not be possible to

Re: Microrhythm

Dave Tremblay wrote > However, I wonder if it would be possible to make it play, or at least > display, microrhythms, [...] Hi Dave,MIDI playback of microrhythms (including interpolation between the two notated extremes by applying time-dependent percentages) surely will not be possible to

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

Noeck wrote > I've confidence in your algorithm. I just thought I post a situation > which I would have neglected at first – without knowing what your > algorithm does. Hi Joram, It's good have asked, it is just too easy to overlook things... Noeck wrote > Thanks for your explanation! It

Re: issue 5312: Key cancellation glyph position inconsistent (issue 343020043 by torsten.haemme...@web.de)

Joram Berger wrote > Will it also look good for custom key signatures? Hi Joram, Well, in your example, there will be no difference between the old and new coding: The first two naturals with full overlap get a maximum extra padding of 0.3, the second and third naturals are (vertically) so far

Re: make-tie-stencil: bug? and optional values?

dak wrote > Well, yeah. (* (/ ... h_inf) h_inf) does not make a whole lot of sense > either way. @Harm Function F0_1(w) basically is supposed to return 0 for w = 0 and asymptotically approach a limit of 1 as w grows wider. Because atan(x) -> π/2 (i.e. 90°) as x -> infinity, the result is

Re: Skylines and certain grob properties (rotation, extra-offset)

Hi all, Thanks for the confirmation, we all seem to agree that grob rotation should be taken into account when creating skylines, whereas extra-offset should stay as it is, i.e. not affect the skylines. Carl Sorensen-3 wrote > If it doesn't slow the code down too much, I would be in favor of

Skylines and certain grob properties (rotation, extra-offset)

Hello developers, When dealing with skylines in issue #5307 "Skyline Refinements (Rounded Boxes and Rotated Ellipses)" , I noticed that the rotation grob property is not reflected in the skylines at all. At present, skylines do not know

Re: 1/8 and 1/16 feta flags too wide?

Hi Malte and Werner, I've just noticed that I apparently forgot "make test-clean" before starting "make check"... (cough...) A new regression check run revealed lots of regression issues - but everything within very slight corrections of spacing, as expected. Optically, everything's OK, I just

Re: 1/8 and 1/16 feta flags too wide?

Hi Werner, I've now set up a little comparison test (see attachment). On the left, you can see three flags (8th, 16th and 32th) with a tight surrounding box in a markup \column so that the slight differences in width are clearly visible. On the right, there is one bar of quavers with alternating

Re: 1/8 and 1/16 feta flags too wide?

Werner LEMBERG wrote > Malte (or Thorsten), can you check whether formatting of 1/8 and 1/16 > flags improves if the width is harmonized with the other flags? I've now remove the extra stemthickness# / 2 from the 8th and 16th flags and run a regtest. There were no effects to be seen at all. So

Re: 1/8 and 1/16 feta flags too wide?

Hi Werner, As I see it, the character width (width of bounding box) of u* flags differs by half the stem thickness: width of flags.u3 and u4: hip_width# + *stemthickness# / 2* + right_upflag_space# width of flags.u5, u6, u7, etc.: hip_width# + right_upflag_space# This looks like an

Re: Issue 5272: Add \depart (issue 337520043 by nine.fierce.ball...@gmail.com)

Hello all, Admittedly, something like "goto" or "jump" seemed obvious to me, too. In more musical terms, however, we're talking about "repeated sections". As opposed to repeat bars, there are textual instructions involved, and there are, sort of, "marks" involved, too: capo, fine, segno, etc.

Request for LilyPond Issue Tracker Project Authorization

Hi all, Could anybody please be so kind as to add me to the LilyIssues project in sourceforge? Without this authorization the automatic tag update etc using git didn't work when trying to upload a patch regarding issue #3653. Thomas Morley/Harm edited the tags for me this time (thanks!) My

LilyJAZZ font - confusion about LICENSE

Hi all, After quite a long absence from the web I've come out of the woodwork again... Unfortunately, I obviously had left the LilyJAZZ font licensing question rather unclear. As Urs pointed out, primarily the somewhat vague wording "... shall be open and free" was not at all as clear as I