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/DejaVuSans.ttf
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
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
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 {
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
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
>
> %=====
> \versio
`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.ily'
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 some
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
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 make s
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, adding stuff
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
lilypond-user@gnu.org
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 make some
contributions for SMuFL (renaming and rearranging glyphs should
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 probably should
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
>>> cont
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
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
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
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” symbols. But why
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 opportunity
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:
ent 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
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
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
, 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
> On 5 Apr 2018, at 10:58, Malte Meyn <lilyp...@maltemeyn.de> 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
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.
: Re: Fwd: [smufl-discuss] SMuFL development
moves to the new W3C Music Notation Community Group
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
http://lilypond
be a problem if the
person is comfortable using LilyPond in the first place. I wonder if it
could be connected to LilyBin somehow? That way you could upload music from
anywhere! Sounds like a cool service to me.
- Abraham
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Fwd-smufl
be represented as a single file)?
--
View this message in context: Re: Fwd: [smufl-discuss] SMuFL development
moves to the new W3C Music Notation Community Group
http://lilypond.1069038.n5.nabble.com/Fwd-smufl-discuss-SMuFL-development-moves-to-the-new-W3C-Music-Notation
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.___
lilypond-user mailing list
lilypond
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
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 good thing
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 presumed
to the
idea of SMuFL brought up by Steinberg and Daniel Spreadbury?
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.
Any thoughts?
I've missed the main
Hi,
2013/8/18 u...@openlilylib.org:
Zitat von Janek Warchoł janek.lilyp...@gmail.com:
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 other
Hi,
a short comment:
2013/8/11 David Kastrup d...@gnu.org:
Werner LEMBERG w...@gnu.org 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
Hi folks,
2013/8/9 Urs Liska u...@openlilylib.org:
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
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 complete notes as provided, or assemble
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.
In the current SMuFL paper (Version 0.4) there are some
Carl Peterson carlopeter...@gmail.com 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
Johan Vromans jvrom...@squirrel.nl schrieb:
Carl Peterson carlopeter...@gmail.com 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
Urs Liska u...@openlilylib.org writes:
Johan Vromans jvrom...@squirrel.nl schrieb:
Carl Peterson carlopeter...@gmail.com 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
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 start thinking how LilyPond font
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 under free licenses so that people can
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 music system vendors will release
their fonts in a usable
the very heavy black
Germanic 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 music system
be
feasible to create a _conversion_ from SMuFL to LilyPond's layout and
metrics. Of course, that would not really be contributing anything back
to SMuFL or Steinberg but it would likely be easier than making LilyPond
work with more than one font type.
--
David Kastrup
to stress.
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
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 if we bailed on
SMuFL, and simply
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 fonts
Kieren MacMillan kieren_macmil...@sympatico.ca 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
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
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 software and use
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
On 10/08/13 6:30
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 this is all quite
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, commercially packaged
Andrew Bernard andrew.bern...@gmail.com 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,
they are 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
find more details.
HTH
Urs
Although I personally would like to have the option to use
proprietary
fonts with LilyPond.
Not proprietary, but SMuFL fonts, commercially packaged! :-) Emmentaler
is, in effect, proprietary, although free.
Andrew
Andrew Bernard andrew.bern...@gmail.com 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
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 entities releasing them under proprietary licenses).
Having
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 entities releasing them under proprietary licenses).
Having
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 the SMuFL
Evan Driscoll drisc...@cs.wisc.edu 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
Andrew Bernard andrew.bern...@gmail.com 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
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 (but
Werner LEMBERG w...@gnu.org 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
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 http
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
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.
Making Emmentaler/Feta SMuFL
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, at a
minimum
to Unicode 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
SMuFL
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
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 since
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
Consortium have been doing
On Sat, Aug 10, 2013 at 12:21 AM, Werner LEMBERG w...@gnu.org 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's a
step away
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
entities into the Unicode standard
89 matches
Mail list logo
