I found the culprit! I had to add the actual Bravura font (not profondo or
whatever else openlilylib smufl font) in the Lilypond font directory. I was
confused because in another computer I had the exact same setup without
having to add Bravura in that directory for some reason.
All good.
Thanks
Hi Dimitris,
Le 23/06/2022 à 13:49, Dimitris Marinakis a écrit :
I'm getting some errors with smufl fonts even though I've installed
everything properly
No UTF-8 characters in any of the paths.
Lilypond 2.33.7
warning: no glyph for character U+E4CE in font
`C:/WINDOWS/fonts/Deja
I'm getting some errors with smufl fonts even though I've installed
everything properly
No UTF-8 characters in any of the paths.
Lilypond 2.33.7
warning: no glyph for character U+E4CE in font
`C:/WINDOWS/fonts/DejaVuSans.ttf`
Le 12/02/2021 à 18:53, Jean Abou Samra a écrit :
Le 12/02/2021 à 16:48, Garap Magu a écrit :
Dear LilyPond Users,
Hello, I had a question about Lilypond input files.
I saw on the Google Summer of Code page that SMuFL adoption was planned.
Would this change the syntax of Lilypond input
Le 12/02/2021 à 16:48, Garap Magu a écrit :
Dear LilyPond Users,
Hello, I had a question about Lilypond input files.
I saw on the Google Summer of Code page that SMuFL adoption was planned.
Would this change the syntax of Lilypond input files?
I’m new to Lilypond and am not familiar with
Dear LilyPond Users,
Hello, I had a question about Lilypond input files.
I saw on the Google Summer of Code page that SMuFL adoption was planned.
Would this change the syntax of Lilypond input files?
I’m new to Lilypond and am not familiar with what SMuFL adoption would mean to
end users
On 2020-07-11 1:00 am, Andrew Bernard wrote:
Possibly answering my own question, this works:
<
\tweak Accidental.stencil #ly:text-interface::print
\tweak Accidental.text
\markup {
\smuflglyph "accidentalHalfSharpArrowUp"
}
fis'
\tweak Accidental.stencil #ly:text-interface::pr
Possibly answering my own question, this works:
<
\tweak Accidental.stencil #ly:text-interface::print
\tweak Accidental.text
\markup {
\smuflglyph "accidentalHalfSharpArrowUp"
}
fis'
\tweak Accidental.stencil #ly:text-interface::print
\tweak Accidental.text
\markup {
\s
I am able to use various exotic accidentals from SmuFl with my own
music functions such as this:
accidentalHalfSharpArrowUp =
#(define-music-function (note)
(ly:music?)
#{ \once \override Voice.Accidental.stencil =
#ly:text-interface::print
\once \override Voice.Accidental.text
u need to be familiar with openlilylib and install it. See
> archives for instructions. [I cant assume you know how to use it.]
> Then there is a snippet for custom-music-fonts/smufl.
>
> Here's some functions I have, as an example.
>
> Andrew
>
>
`C:/Users/GDC60~1/AppData/Local/Temp/frescobaldi-j6t528_a/tmpznoagsaa/
document.ly'
Parsing...
C:/Users/GDC60~1/AppData/Local/Temp/frescobaldi-j6t528_a/tmpznoagsaa/document.ly:6:11
<https://mail.google.com/mail/u/0/0>: error: cannot find file:
`custom-music-fonts/smufl/definitions.i
Hi Freeman,
Be assured that this can be done. I use the following technique all the time.
First you need to be familiar with openlilylib and install it. See
archives for instructions. [I cant assume you know how to use it.]
Then there is a snippet for custom-music-fonts/smufl.
Here's
I want to place the accidental accSagittal7v11CommaUp, xE346 on note c. I
do not have a clue.Please explain how? And can this be done global,
please explain also?
%%%
\version "2.18.0"
\include "definitions.ily"
\smuflOn
\relative c''
{a4 b c d}
%%%
Thank you,
ƒg
On this topic, the original query still stands. Would it be possible to use
SMuFL glyphs in the Accidental glyph-name-list?
Andrew
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Answering my own query, this may be useful for others searching the
archives in the future. This example uses the openlilylib
custom-music-fonts code to load Bravura, and this example shows how a SMuFL
glyph can be used as an accidental. Quite handy, even if I do so day myself.
[Obviously this
SMuFL has a large collection of accidental glyphs, some of which I need.
The openlilylib custom-music-fonts snippet enables the use of SMuFL fonts
and works pretty well for me. But I would like to add a SMuFL accidental to
the Accidental.glyph-name-alist, for my locally customised note name set
ns.
> > Which I think is true and not. If there is someone willing to spend
> efforts adding stuff to Emmentaler that's a great thing and shouldn't be
> discouraged because we have even more pressing things to do.
>
> That sounds reasonable. And maybe I should try to
ant to use
the new features introduced in 2.21.0 but not 2.20.0 (there probably
will be a lot of those), therefore I’d add changes to master only
after the release of 2.21.0 (i. e. 2.21.1 would be the earliest
possible release for big SMuFL changes).
Ah that's why you asked. No,
2.21.0 but not 2.20.0 (there probably will be
a lot of those), therefore I’d add changes to master only after the
release of 2.21.0 (i. e. 2.21.1 would be the earliest possible release
for big SMuFL changes).
___
lilypond-user mailing list
lilypo
there is someone willing to spend
efforts adding stuff to Emmentaler that's a great thing and shouldn't
be discouraged because we have even more pressing things to do.
That sounds reasonable. And maybe I should try to make some
contributions for SMuFL (renaming and rearranging glyphs
adding stuff to Emmentaler that's a great thing and shouldn't be discouraged
because we have even more pressing things to do.
That sounds reasonable. And maybe I should try to make some
contributions for SMuFL (renaming and rearranging glyphs should be not
too hard). But that proba
Am 1. April 2019 20:07:47 MESZ schrieb Malte Meyn :
>
>
>Am 01.04.19 um 12:01 schrieb Johan Vromans:
>> On Mon, 1 Apr 2019 09:17:26 +0200, Malte Meyn
>wrote:
>>
>>> SMuFL integration and using Metafont for glyph creation don’t
>>> contradict, do
Am 01.04.19 um 12:01 schrieb Johan Vromans:
On Mon, 1 Apr 2019 09:17:26 +0200, Malte Meyn wrote:
SMuFL integration and using Metafont for glyph creation don’t
contradict, do they?
They do, in so far that with limited resources you cannot do both.
[sending on-list, sorry Johan for the
On Mon 01 Apr 2019 at 09:16:24 (+0200), David Kastrup wrote:
> David Wright writes:
> > On Mon 01 Apr 2019 at 11:37:42 (+1100), Andrew Bernard wrote:
> >> Hi Valentin,
> >>
> >> Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have
> >> been a programmer for more than forty y
On Mon, 1 Apr 2019 09:17:26 +0200, Malte Meyn wrote:
> SMuFL integration and using Metafont for glyph creation don’t
> contradict, do they?
They do, in so far that with limited resources you cannot do both.
___
lilypond-user mailing list
li
David Wright writes:
> On Mon 01 Apr 2019 at 11:37:42 (+1100), Andrew Bernard wrote:
>> Hi Valentin,
>>
>> Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have
>> been a programmer for more than forty years. [Despite that, I still cannot
>> come to grips with the lilypond s
epted
standards where possible.
So I'd rather see decent SMuFL integration than more home grown Emmentaler
extensions.
SMuFL integration and using Metafont for glyph creation don’t
contradict, do they? Of course we should concentrate on glyphs requested
by SMuFL instead of “home grown” symbol
o for widely accepted
standards where possible.
So I'd rather see decent SMuFL integration than more home grown Emmentaler
extensions.
I wanted to join this discussion although my comments had already become
separate from the direction of the discussion, but your comment gives me
a good o
Aaron Hill writes:
> On 2019-03-31 6:14 pm, edes wrote:
>> el 2019-04-01 a las 11:37 Andrew Bernard escribió:
>>
>>> Thanks so much. Now to learn Metafont then. Shouldn't be too hard
>>
>> unlike valentin, i admire you already even if you don't succeed. i
>> don't
>> know what admire the most: th
er see decent SMuFL integration than more home grown Emmentaler
extensions.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
On 2019-03-31 6:14 pm, edes wrote:
el 2019-04-01 a las 11:37 Andrew Bernard escribió:
Thanks so much. Now to learn Metafont then. Shouldn't be too hard
unlike valentin, i admire you already even if you don't succeed. i
don't
know what admire the most: the determination of the "now to learn
On Mon 01 Apr 2019 at 11:37:42 (+1100), Andrew Bernard wrote:
> Hi Valentin,
>
> Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have
> been a programmer for more than forty years. [Despite that, I still cannot
> come to grips with the lilypond source, and all my lilypond que
el 2019-04-01 a las 11:37 Andrew Bernard escribió:
> Thanks so much. Now to learn Metafont then. Shouldn't be too hard
unlike valentin, i admire you already even if you don't succeed. i don't
know what admire the most: the determination of the "now to learn
metafont", or the optimism of the "sho
Hi Valentin,
Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have
been a programmer for more than forty years. [Despite that, I still cannot
come to grips with the lilypond source, and all my lilypond questions all
appear to be from a beginner. :-) ]
The immediate task is to
, however, assuming you can master metafont syntax. Many have
given up, but you’ll be regarded as a hero if you do -- well, at least
by me :-)
Using SMuFL with LilyPond requires but a thin compatibility layer
(mainly because of different glyph name mapping); that’s what the
OpenLily thingamabob does and
What is the current state of the art in using SMuFL fonts with lilypond
2.19.83? The blog posts I read referred to openlilylib modules to enable
it, but with many references to issues such as subtle sizing problems etc
etc. Is this ready for pro. use yet? Will it ever be, or are the
> On 5 Apr 2018, at 10:58, Malte Meyn wrote:
>
> I see another option:
> 4. Add this ornament to Feta.
>
> SMuFL is a good argument for that, if we want to support it some day.
That would be best, as it is already possible in LilyPo
;
>
> Thank you for the clarification. I have not experimented with it,
> myself, but that was my perception based on the documentation. So,
> I assume it has the full app behind it (i.e., to create a score
> from any code we throw at it, as long as it can be represented as
&g
the full app behind it (i.e., to create a score from any code we throw at
> it, as long as it can be represented as a single file)?
>
> --
> View this message in context: Re: Fwd: [smufl-discuss] SMuFL development
> moves to the new W3C Music Notation Comm
file)?
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Fwd-smufl-discuss-SMuFL-development-moves-to-the-new-W3C-Music-Notation-Community-Group-tp179133p179139.html
Sent from the User mailing list archive at Nabble.com.___
lil
onnected to LilyBin somehow? That way you could upload music from
> anywhere! Sounds like a cool service to me.
>
> - Abraham
>
> ------
> View this message in context: Re: Fwd: [smufl-discuss] SMuFL development
> moves to the new W3C Music Notation Communi
message in context:
http://lilypond.1069038.n5.nabble.com/Fwd-smufl-discuss-SMuFL-development-moves-to-the-new-W3C-Music-Notation-Community-Group-tp179133p179136.html
Sent from the User mailing list archive at Nabble.com.___
lilypond-user mailing list
lily
Hi,
a small side note on this: Of course, the W3C and Wikipedia are much
different levels in terms of web standards. But at least there is some
type of music representation available for websites which (in my naïve
thinking) should not be ignored completely when working on a new standard.
https:/
This has been around on a few channels, but I'd like to forward it to
this place too.
Development of MusicXML and SMuFL is moved from two commercial companies
to a W3C community group.
This is definitely a big step and will change a few things. However, I'm
not fully convinced it is a
Yesterday at the MusicXML community meeting at the Musikmesse in
Frankfurt we were informed about the approaching 1.0 release of
Steinberg's proposed SMuFL standard (http://smufl.org). Once 1.0 is
published there shall be no further changes in the set of covered
glyphs, and the pre
Hi,
2013/8/18 :
>
> Zitat von Janek Warchoł :
>> We don't know if it would be worth it to make LilyPond support SMuFL.
>> But i think the question is: what should we do to make it easier to us
>> to adopt SMuFL if we decide to to do in the future?
>> In othe
Zitat von Janek Warchoł :
Hi folks,
2013/8/9 Urs Liska :
Hi all,
although I suspect this could once more become a longish and scattered
thread, I feel forced to bring it up here.
What do you think: would it make sense to open up LilyPond thinking to the
idea of SMuFL brought up by
Hi folks,
2013/8/9 Urs Liska :
> Hi all,
>
> although I suspect this could once more become a longish and scattered
> thread, I feel forced to bring it up here.
>
> What do you think: would it make sense to open up LilyPond thinking to the
> idea of SMuFL brought up by
Hi,
a short comment:
2013/8/11 David Kastrup :
> Werner LEMBERG writes:
>
>>> I think "so poorly documented that in practice almost no one can
>>> understand how it works" still can't qualify as "in effect
>>> proprietary".
>>
>> It is not *that* badly documented. However, the number of people
objects
> like staves are draws not using glyphs from fonts but more primitive
> graphics objects. So I feel one should also change the layout of quite
> a few graphical objects when switching fonts.
>
> I wonder whether one would call that "layout" or "style".
>
&
s but more primitive
graphics objects. So I feel one should also change the layout of quite
a few graphical objects when switching fonts.
I wonder whether one would call that "layout" or "style".
In the current SMuFL paper (Version 0.4) there are some options:
use compl
Kieren MacMillan writes:
> Hi all,
>
>> 3)
>> It's currently not really an option to tackle such a change from the
>> technical POV.
>> LilyPond is quite far away from being able to play together with other fonts.
>
> From my (perhaps naïve) perspective, this seems to be the chicken
> whence the
since there is more than one
issue involved.
> 1)
> Conceptually it would be acceptable to have LilyPond support SMuFL
> compliant fonts.
Supporting something is not the question. The question is whether there
are efforts needed _specifically_ to support only hypothetical or
non-free f
s. ;)
Put another way: If we focused on solving #3 — i.e., fixing Lily so that she
DOES play easily/well/perfectly with other fonts — wouldn't we be in a far
better position to act on #1 and #2, if it was desirable/feasible/acceptable?
And said effort, it seems to me, would not be wasted even
More than once in this discussion we had comments that seem to indicate
that SMuFL is evil because it allows non-free fonts to be used.
But if for example someone would (hypothetically) provide a means to
use alternative fonts, this contribution wouldn't have to be rejected,
right? Otherwi
c font. But you can't choose. Your installation
supports one or the other.
Supporting more than one font layout plays second fiddle to supporting
more than one font.
Once supporting more than one font is possible, it would likely be
feasible to create a _conversion_ from
standard lilypond font, attractive though it may
be. It would be nice to have a wider choice to offer in the future,
and if SMuFL takes off as a standard, there may well be many fonts to
choose from.
Do you really think that proprietary music system vendors will release
their fonts in a usable form
ermanic look of the standard lilypond font, attractive though it may
>>> be. It would be nice to have a wider choice to offer in the future,
>>> and if SMuFL takes off as a standard, there may well be many fonts to
>>> choose from.
>> Do you really think that proprietary m
nice to have a wider choice to offer in the future,
and if SMuFL takes off as a standard, there may well be many fonts to
choose from.
Do you really think that proprietary music system vendors will release
their fonts in a usable form under free licenses so that people can
forego buying their
On 11/08/13 8:09 PM, David Kastrup wrote:
So far, I don't see that SMuFL is more than calling a particular
choice a standard. You could equally well say "why isn't Steinberg
picking up the Emmentaler standard?". SMuFL is a font layout. Saying
"it will be good to st
Urs Liska writes:
> Johan Vromans schrieb:
>
>>Carl Peterson writes:
>>
>>> I think we're getting hung up on the fact that SMuFL is being
>>> promulgated by a corporate entity and the only implementation of
>>> SMuFL is produced by that corpo
Johan Vromans schrieb:
>Carl Peterson writes:
>
>> I think we're getting hung up on the fact that SMuFL is being
>promulgated
>> by a corporate entity and the only implementation of SMuFL is
>produced by
>> that corporate entity (and that most of the mus
Carl Peterson writes:
> I think we're getting hung up on the fact that SMuFL is being promulgated
> by a corporate entity and the only implementation of SMuFL is produced by
> that corporate entity (and that most of the musical font work is being done
> by other corporate entiti
Werner LEMBERG writes:
>> I think "so poorly documented that in practice almost no one can
>> understand how it works" still can't qualify as "in effect
>> proprietary".
>
> It is not *that* badly documented. However, the number of people who
> understand Metafont are rather small today.
git sh
> I think "so poorly documented that in practice almost no one can
> understand how it works" still can't qualify as "in effect
> proprietary".
It is not *that* badly documented. However, the number of people who
understand Metafont are rather small today.
> - Someone who doesn't really want to
Andrew Bernard writes:
> Emmentaler is, in effect, proprietary, although free.
I disagree. I think "so poorly documented that in practice almost no one
can understand how it works" still can't qualify as "in effect
proprietary".
It just qualifies as "needing a huge amount of work; work that the
Evan Driscoll writes:
> As a fairly outside observer who is only an occasional user of Lilypond
>
> On 08/09/2013 11:43 PM, Carl Peterson wrote:
>> The concern I have on SMuFL is that it is an as-of-yet immature standard
>> without broad support outside of Steinberg. ..
As a fairly outside observer who is only an occasional user of Lilypond
On 08/09/2013 11:43 PM, Carl Peterson wrote:
> The concern I have on SMuFL is that it is an as-of-yet immature standard
> without broad support outside of Steinberg. ... Will it be a futile
> effort because
eel about it.
Having the option to use any font, including commercial ones, was one of the
things that finally made me switch to LaTeX.
If OpnOffice forced me to use free fonts exclusively I probably wouldn't use it.
>I think we're getting hung up on the fact that SMuFL is bein
o use proprietary fonts
intentional or incidental is likely one of those dreaded semantic
distinctions).
I think we're getting hung up on the fact that SMuFL is being promulgated
by a corporate entity and the only implementation of SMuFL is produced by
that corporate entity (and that most of the
Andrew Bernard writes:
> On 10/08/13 7:10 PM, David Kastrup wrote:
>
>> Of course, people are free to do whatever they want with their own time
>> and efforts. But if you do it out of a feeling of contributing to
>> LilyPond, it may be worth looking quite closer before investing a lot of
>> effo
page or on the referenced "texlive
contribution" page you'll find more details.
HTH
Urs
>>
>> Although I personally would like to have the option to use
>proprietary
>> fonts with LilyPond.
>Not proprietary, but S
e not standardized. At any rate, it's not much of a
priority for a free software project to make it easier to use
proprietary software.
I was not clear. What I meant was, if SMuFL does become an accepted
standard, then fonts could be standardised, and then we could use them
if lilypond adopted SMuFL.
Andrew Bernard writes:
> Interesting valid points David.
>
> But I was thinking that it although lilypond is open source, why can't
> I purchase _commercial_ music fonts to use with it, just as one does
> for print typesetting?
Because they are not standardized. At any rate, it's not much of a
ConTeXT program.
But the free TeX distros won't for example packages that are "macros
supporting non-free fonts".
Can you explain that more?
Although I personally would like to have the option to use proprietary
fonts with LilyPond.
Not proprietary, but SMuFL fonts, commer
reference font
implementation for SMuFL.
Andrew
On 10/08/13 6:30 PM, David Kastrup wrote:
Do you really think that proprietary music system vendors will
release their fonts in a usable form under free licenses so that
people can forego buying their software and use LilyPond instead?
Of course th
licensing restrictions that prevent lilypond components such as fonts
being utilised by commercial software (I don't know)? And I think you
can download Steinberg Bravura font presently for free, although I
understand this is principally as a reference font implementation for SMuFL.
Andrew
O
to offer in the future,
> and if SMuFL takes off as a standard, there may well be many fonts to
> choose from.
Do you really think that proprietary music system vendors will release
their fonts in a usable form under free licenses so that people can
forego buying their software and use LilyPo
Thanks Werner for pointing this out.
It would help if I read the SMuFL standard before commenting. :-) So I
think my previous comments are invalid. Now that I have read the
standard v 0.6, I see that it works hand in hand with Unicode, and is
not in opposition to, or outside of Unicode. Given
>> Unicode is a *character* standard, mainly to *exchange*
>> information. It is *not* related to glyphs, or to fonts. The
>> SMuFL team correctly maps the glyphs to the Private Area of
>> Unicode, and they don't suggest the inclusion of any of those
>>
On Sat, Aug 10, 2013 at 12:21 AM, Werner LEMBERG wrote:
>
> > The SMuFL standard is just a specification cooked up by Steinberg
> > for the new program. It's been possible for them to consider this
> > since they are architecting the program from scratch. But it
> The SMuFL standard is just a specification cooked up by Steinberg
> for the new program. It's been possible for them to consider this
> since they are architecting the program from scratch. But it's a
> step away and outside of the hugely important work the Unicode
Greetings List,
There's an old IT joke that the beauty of having standards is that there
are so many to choose from!
I agree with Shane. The SMuFL standard is just a specification cooked up
by Steinberg for the new program. It's been possible for them to
consider this sinc
SMuFL has nothing much to do with preserving the Unicode standard. If
you can get the Unicode consortium to participate in outlining SMuFL
stuffs in its standard than it would be good, but an abstracted
standard used by one or two applications is a bad idea especially for
one text based like ours
nicode numbers
I think that would be very simple, just a matter of remapping
them in a suitable application.
If LilyPond really accesses the glyphs by their names this
wouldn't even imply any internal changes.
But then, if we intended to allow LilyPond to use other
SM
mapping them in a
> suitable application.
>If LilyPond really accesses the glyphs by their names this wouldn't
> even imply any internal changes.
>
But then, if we intended to allow LilyPond to use other SMuFL-compliant
fonts, there *would* be internal changes, as we would have to have
of SMuFL brought up by Steinberg and Daniel Spreadbury?
http://www.smufl.org <http://www.smufl.org/>
Of course currently it's only their new Bravura font that complies to
that proposed standard.
But I can imagine there will be more 'participators' in mid-term future.
M
Am 09.08.2013 14:39, schrieb Urs Liska:
Hi all,
although I suspect this could once more become a longish and scattered
thread, I feel forced to bring it up here.
:)
What do you think: would it make sense to open up LilyPond thinking to
the idea of SMuFL brought up by Steinberg and Daniel
Hi all,
although I suspect this could once more become a longish and scattered
thread, I feel forced to bring it up here.
What do you think: would it make sense to open up LilyPond thinking to
the idea of SMuFL brought up by Steinberg and Daniel Spreadbury?
http://www.smufl.org <h
89 matches
Mail list logo
