I have searched most of my accordion literature, both old and modern
norwegian and german publications, some old sovjet accordion books
and old american publications like the one I sent you a snapshot of
earlier. I only find the (R) and (*) symbols in the publications
from Alfred Music in New
High priority issues (I'd like to get these done before I begin
integrating my GSoC work):
* A glyph should be created for SMuFL's clefChangeCombining
character.
Really? Why?
I was following precedent. Bravura includes it, even though it's a
zero-width empty character.
As far as I
Hi Benkő,
On 3/19/22 02:00, Benkő Pál wrote:
Hi Owen,
Owen Lamb ezt írta (időpont: 2022. márc. 19., Szo, 7:38):
Hi Benkő,
On 3/17/22 10:05, Benkő Pál wrote:
re the longest rests:
1. a perfect longa rest and a maxima rest are not the same;
2. a perfect longa rest should take three spaces
Hi Benkő,
On 3/17/22 10:05, Benkő Pál wrote:
re the longest rests:
1. a perfect longa rest and a maxima rest are not the same;
2. a perfect longa rest should take three spaces (like current
emmentaler rests.M3mensural), not four (as, I fear, the bravura
mensuralRestLongaPerfecta implies)
3. a
next time,
Owen Lamb
Hi Jürgen,
Thank you so much! Apologies for the delayed reply.
*noteheads.uM2, noteheads.dM2*
IIRC, I have seen these noteheads various times in print (which does
not necessarily mean that they are an agreed standard), though I can
not immediately find an example to show. If I remember
left off.
I don't like to make promises, but I *think* I'll be able to, God
willing, knock out the Mensural and Neomensural sections within the
coming week. If all goes well.
So, stay tuned!
Owen Lamb
cents to offer regarding what I've previously mapped, let me know!
Owen Lamb
Hi all,
Just wanted to give a quick half-update. I sent a message to the W3C
mailing list about the rotated arpeggio glyphs, so that should move
along soon.
I also discovered I'd missed a treasure trove of pre-encoded ornaments
in SMuFL! Things are matching up quite nicely now. There's just
Hi Werner,
* about `trill_element` vs. `trillelement`: This was changed by Han-Wen in
commit c49e0fd544f (dated 2004) without any log messages. It looks
like an oversight that `trillelement` wasn't removed then.
Good to know! I'll put a further investigation/usage poll on the list of
The
next update should finish out the next five (small) modern notation
sections; after that, it's on to ancient notation.
Thanks for bearing with me!
Owen Lamb
That's right--good catch! I just pushed a fix. (SMuFL prefers -Black to
-Quarter, but otherwise you're spot on.)
Thanks for your help,
Owen
On 7/24/2021 6:31 AM, Mark Knoop wrote:
At 23:43 on 23 Jul 2021, Owen Lamb wrote:
Hi all! A few updates from the SMuFL front.
You have mapped both
noteheads.
Owen Lamb
On 7/10/2021 9:38 PM, Werner LEMBERG wrote:
* Regarding `noteheads.uM2`, I don't see a problem with removing the
hard-coded stems.
That's good to hear. If we do, though, we'll have to reconcile
breve/longa sidebars with Lily's customizable stems. I'm thinking
we keep our breve glyphs for
r's source material and make sure the output is
nice/consistent enough not to be too bothersome. That way, whenever a
shape-note user does come along, if they spot mistakes, at least they'll
be consistent and thus easy to work around.
You are reaching a point where I am starting to go, "Eh, if Owe
can make no
promises) I *might* try my hand at expanding Emmentaler in a couple areas.
Owen
On 7/10/2021 6:29 AM, Hans Åberg wrote:
On 10 Jul 2021, at 04:09, Owen Lamb wrote:
A bit of news on the SMuFL front. I've dropped in the next few Emmentaler categories
(Default Noteheads, Special
Hi Werner,
* Regarding `noteheads.uM2`, I don't see a problem with removing the
hard-coded stems.
That's good to hear. If we do, though, we'll have to reconcile
breve/longa sidebars with Lily's customizable stems. I'm thinking we
keep our breve glyphs for SMuFL compatibility, but in LP
W3C Music Notation Community
Group, but otherwise not much has changed.
Regards,
Owen Lamb
Hi Werner,
Indeed. Care to open an SMuFL issue at their site?
Do you mean we propose that SMuFL *itself* should explicitly recommend
that programs default to timeSigX when the other number sets aren't
present? I doubt we'd find success there; I only meant it'd be less
awful for Emmentaler to
Hi Werner,
* Number sets: Since LilyPond uses the same glyphs for time
signatures, figured bass, and fingerings, we probably have to map
the Emmentaler glyphs to all SMuFL sets, irrespective of the size.
In general, I think that size issues are only to be considered if
the size
you
think (even if you think it's all good).
Sincerely,
Owen Lamb
P.S. I'd particularly appreciate the help of anyone who's had experience
with Stockhausen accidentals. But really--anyone and everyone should
give it a look! The more pairs of eyes, the better.
Hi Werner,
Unfortunately, I'll have to decline for now. School is picking up around
here--there's only a couple weeks left in the semester, and I'd like to
make sure I keep that commitment first. I don't think I'll have the time
to learn to put together a PDF like that until finals are over.
y simplify the effort somewhat.
Keep up the awesome work!
Best,
Abraham
On Thu, Apr 8, 2021 at 3:00 PM Owen Lamb <mailto:ol...@asu.edu>> wrote:
Hi all!
I've been working on matching Emmentaler's glyphs to SMuFL glyph
names,
and I'd appreciate some input on what I have so
Hi all!
I've been working on matching Emmentaler's glyphs to SMuFL glyph names,
and I'd appreciate some input on what I have so far.
Attached is a spreadsheet with my plans for naming the Clef, Time
Signature, Number, and Accidental glyph categories, as enumerated at
anymore, unless we want to keep that for records as well.
Regards,
Owen Lamb
On 1/10/2021 4:32 AM, Jonas Hahnfeld wrote:
Hi all,
there are currently 38 branches (out of 72 in total) in the canonical
repository that have a committed date older than 90 days, excluding the
stable/* branches. I
?
Owen Lamb
community, and
I'd like to stick around if I can. I plan on continuing to improve SMuFL in
LilyPond, but in case I don't follow through, I've included in the summary
a list of what to do next.
Happy LilyPonding,
Owen Lamb
Arizona State University
On Sat, Aug 29, 2020 at 5:07 PM Carl Sorensen wrote:
> As long as all of your commits build successfully, it's not a big deal if
> there is a regression problem in the middle, IMO. I'd just add a commit at
> the end and call it good.
OK. (I already did it the other way, but for any other
On Sat, Aug 29, 2020 at 2:39 AM Werner LEMBERG wrote:
>
> > Ah! It looks like the issue is in line 12 of palm-mute.ly:
> >
> > e8^\markup { \musicglyph "noteheads.u2do" = palm mute }
> >
> > Here, \musicglyph is looking for noteheads.u2do, which I combined
> > with .d2do to make .s2do.
On Sat, Aug 29, 2020 at 3:09 AM Werner LEMBERG wrote:
>
> > So, glyphnames.json.txt would look like this?
> >
> > glyphnames.json, created by Daniel Spreadbury, was retrieved from
> > https://github.com/w3c/smufl on DD Mon . It is licensed under
> > the W3C Community Contributor
On Mon, Aug 24, 2020 at 1:07 AM Werner LEMBERG wrote:
> * Who has written the file `glyphnames.json`? It lacks a copyright
> header. If this is a non-lilypond file copied verbatim, please add
> a separate file (say, `glyphnames.json.txt`) that gives all the
> details: author, origin,
On Fri, Aug 28, 2020 at 3:00 AM Michael Käppler wrote:
> I cannot reproduce this on my machine.
>
All right. Thanks for giving it a try. Han-Wen, I'll take your advice and
ignore this issue for the time being.
> What I see are differences in input/regression/tablature-letter.ly
> (which I
Hi all,
I've encountered a couple of unexpected regressions for my first commit.
The first one was an issue with tablature stems, which I was able to fix.
The other, however, is baffling to me.
It appears that musicxml2ly creates slightly different .ly files between
the two commits, for musicxml
On Tue, Aug 25, 2020 at 11:45 AM Werner LEMBERG wrote:
>
> >> Werner (and the community in general), is backwards compatibility
> >> important enough that I should try to take care of it before the
> >> deadline?
> >
> > I think backwards compatibility is important enough that we should
> >
Hi all!
Daniel drew my attention to the fact that my work doesn't keep backwards
compatibility with other fonts encoded in the LilyPond manner, such as
Gonville. He made a good point--it's definitely worth it to continue
supporting the old format until Emmentaler reaches a reasonable SMuFL or
Hi all!
First, an apology--I thought the project was due today, the 23rd, but it's
actually due next week, on the 31st. Tomorrow is just the first day I can
submit the project. Well, better to err on the side of caution! I'd like to
finish things up at least three days before the Monday
On Mon, Aug 17, 2020 at 12:13 AM Werner LEMBERG wrote:
>
> I wonder whether it is possible to improve legibility: Could you
> modify the code so that whitespace in the strings gets ignored? I
> consider
>
> "accidentalFlat & accidentalKucukMucennebFlat & accidentalFlatArabic"
>
> much more
Hi all!
This week, I encoded the rest of the Feta glyphs, giving them SMuFL names
and alternate/ligature information. Only Parmesan is left without SMuFL
names for the time being.
Some of our glyphs, I noticed, needed to be encoded in more than one spot
in the specs, so I added a new separator,
On Fri, Aug 7, 2020 at 10:06 PM Urs Liska wrote:
> Hi Owen,
>
> it's always a pleasure seeing your project evolve and proceed. I'd like
> to throw in a comment, although I'm rather sure it isn't actually
> needed.
> I don't recall reading anything about it but probably you have thought
> about
Hi all!
I've been pretty active on the mailing list this week, so you can see what
I've been up to by checking out the archive.
Essentially, what first seemed to be a minor inconvenience--a grob
misplacement--turned out to be a major point of difference between
LilyPond's and SMuFL's treatment
On Thu, Aug 6, 2020 at 9:03 PM Carl Sorensen
wrote:
>
> I am a bit concerned that we are talking about eliminating some of what I
> think are superior design decisions of LilyPond in order to be SMuFL
> compliant. I prefer the convention of attaching the flag to the center of
> the stem as
On Wed, Aug 5, 2020 at 10:57 PM Werner LEMBERG wrote:
>
> Well, LilyPond's solution is more versatile...
>
I agree, to a point. It's more versatile for the user, but not necessarily
for the font designer. At any rate, it's not exactly something we can
overturn when the specification has already
Wow!
Thanks everyone... even if a lot of this went over my head. I've never
rebased before, so I can't say what would be the better option.
At any rate, my understanding is that I'll organize my commits near the end
of the project to make sure everything is reviewable, correct? If that's
the
Hi all,
I've been working on making flags appear at the correct position for both
Emmentaler and Bravura, and I've hit a snag.
Emmentaler's flag glyphs are minimal: they deliberately don't overwrite
a stem's tip, only overlapping with the stem in a thin, rectangular area
(see the attached
On Fri, Jul 31, 2020 at 9:59 PM Werner LEMBERG wrote:
> A question to commit d092b23276059c77e33cab9428b9a9753b5cd27a: Why do
> you change from the (IMHO preferable) `-` to `_` in the file name? I
> consider `_` an abomination that is only necessary because `-` is not
> a valid character in
Thanks for the tip! I just filed issue #4417 on their repo.
(I originally was going for the mailing list because I thought there might
be something wrong with our font files, not FontForge itself, and it'd be
premature to file a bug report. But I guess if FontForge can't fail
gracefully and tell
(Forgot to reply-all, so sending this to the mailing list as well.)
Hi Daniel,
I see what you mean. Judging from the example you offered, however, I
believe the issue is not one of scaling, but of origin misplacement. When
zoomed in, my current reproduction of Bravura appears to be too far to
Hi all,
Thanks for your encouragement from last week! I took Monday off and made
sure not to overwork myself this week.
I tried posting to the public-music-notation-contrib mailing list with my
SMuFL proposals, but it turns out you have to be a member of the group to
do so. SMuFL's specs offered
Hi all,
I didn't make my goal of being able to drop Bravura in, but I made progress.
My research on shape-notes you can see on the list archive--thanks again
everyone for helping out! I'm fairly certain now what to propose to add to
SMuFL, and have written a draft proposal that I will send at
with such
an Anglo-Saxon name as Maine! Ha...maine? Hawaiine? Mawaii?
Hey, that last one actually doesn't sound half bad! ...oh wait, it's a
lotion brand.
On Thu, Jul 23, 2020 at 5:18 PM Aaron Hill wrote:
> On 2020-07-23 4:28 pm, Owen Lamb wrote:
> > (It starts to get confusing to keep track of
23, 2020 at 12:25 PM Karlin High wrote:
> On Wed, Jul 22, 2020 at 4:31 PM Owen Lamb wrote:
> > Firstly, none of the corpora (aha!) you provided or ones I found myself
> > seemed to present both mirrored versions of mi in the same document, as
> > Massive Lion claimed o
AM Benkő Pál wrote:
> I just raised it to show that SMuFL may evolve so (if musicology's
> interpretation of dragmae change so) that separate properties of up
> and down stem attachment points may come handy. you may well have far
> stronger counterarguments, of course.
>
> O
trup wrote:
> Jean Abou Samra writes:
>
> > Le 22/07/2020 à 03:32, Aaron Hill a écrit :
> >
> >> On 2020-07-21 5:39 pm, Owen Lamb wrote:
> >>> corpuses (corpori?)
> >>
> >> Off-topic: "corpora" is the plural in Eng
On Mon, Jul 20, 2020 at 8:25 PM Werner LEMBERG wrote:
>
> > [...] This will allow other programs to throw an error when, e.g.,
> > noteShapeKeystoneBlack isn't found in the font, notifying the user
> > that something's wrong. If the correct styleset is used, the
> > program will correctly
Thanks for the tip, Benkő!
At the moment, I think these sort of double stems are outside of my
project's scope. A two-stemmed black dragma is present in SMuFL as a
pre-composed note (mensuralBlackDragma), but Emmentaler does not have a
glyph for it and LilyPond does not specifically support
Hi all,
LilyPond's catalog of shape-note noteheads is unique because it contains
three full sets of noteheads--Aikin (default), Funk, and Walker. Even if
some noteheads are similar between the three sets, they are
deliberately defined separately and have slightly different looks.* SMuFL
has no
On Sun, Jul 19, 2020 at 2:17 AM Han-Wen Nienhuys wrote:
> I don't understand why we need 2 properties here. What benefit do we
> get relative to a single property?
>
Well, you got me there! Originally, I was under the impression that a
notehead grob may at some point have two stems attached to
Hi all,
Well, I stuck to my plan this week! To recap:
In feta-autometric.mf, I made sure that the chardwx and chardwy variables
are correctly calculated as reflections of charwx and charwy if they aren't
explicitly defined in the character definition. There was a bit of
hullabaloo around strange
Hi all!
This week, I forgot to make a plan, so my work was a bit all over the
place. However, I did make progress in a couple places, and now I have a
plan of action for next week.
First, I added support for ligatures in the .mf files. To do this, I
changed the syntax in fet_beginchar's
Hi all!
The last couple weeks were pretty stressful, which I'm sure you'll be able
to tell from the list archive. However, in the past couple days I have been
able to make up for much of the time lost.
Last week, I made plans for changing LilyPond's internal treatment of
glyphs--namely, that
you've been to help me out, though, and I
hope you all have a great rest of your summer (or winter for those in the
Southern Hemisphere).
Thanks for everything,
--Owen
On Wed, Jul 1, 2020 at 1:18 PM Owen Lamb wrote:
> Sure thing--it's coming your way!
>
> On Wed, Jul 1, 2020 at 1:01 P
Sure thing--it's coming your way!
On Wed, Jul 1, 2020 at 1:01 PM Michael Käppler wrote:
> Am 01.07.2020 um 21:15 schrieb Owen Lamb:
> > Hi Michael,
> >
> > 1. I've been using VBox version 6.1.8, one version behind the latest.
> > Today I updated to 6.1.10, but the
Hi Michael,
1. I've been using VBox version 6.1.8, one version behind the latest. Today
I updated to 6.1.10, but the problem persists.
2. No, I'm not using -j, but today I tried -j2 to see what would happen.
Both threads got stuck, one while processing feta11.pfb, and the other
while processing
ention that in my last
message, sorry.)
On Tue, Jun 30, 2020 at 3:36 PM Owen Lamb wrote:
> On Tue, Jun 30, 2020 at 3:04 PM Jean Abou Samra
> wrote:
>
>> So git clean didn't work? At this point, unfortunately I can't help
>> much--my
>> previous message was merely a sho
On Tue, Jun 30, 2020 at 3:04 PM Jean Abou Samra wrote:
> So git clean didn't work? At this point, unfortunately I can't help
> much--my
> previous message was merely a shot in the dark but I understand almost
> nothing
> about fonts. Also, I'll be going on vacation pretty soon, so I won't have
>
Apologies--I double-checked the tutorial, and it looks like I just missed a
half-line of code. I put it in, and the beta looks fine now. So...
disregard the beta stuff!
On Tue, Jun 30, 2020 at 2:35 PM Owen Lamb wrote:
> Hi Jean,
>
> If Fontforge is too old, it never told me so. It
Hi Jean,
If Fontforge is too old, it never told me so. It generated font files
perfectly well over the last month. Running sudo apt update didn't show any
newer versions.
I can't help but notice that CI failed to build some commits on Friday due
to font issues, the same day that my issue first
I've got ghostscript version 9.26, too. I'm using a LilyDev 2 VM, which I
believe is based on 64-bit Debian.
Thanks,
Owen
On Mon, Jun 29, 2020 at 3:35 PM Thomas Morley
wrote:
> Am Mo., 29. Juni 2020 um 23:54 Uhr schrieb Owen Lamb >:
> >
> > On Mon, Jun 29, 2020 at 2:4
On Mon, Jun 29, 2020 at 2:40 PM Thomas Morley
wrote:
> Am Mo., 29. Juni 2020 um 22:43 Uhr schrieb Owen Lamb >:
> >
> > Hi all,
> >
> > On Friday, make started hanging when making the first .pfb font file,
> > displaying no new information after:
&
Hi all,
On Friday, make started hanging when making the first .pfb font file,
displaying no new information after:
Making mf/out/feta11.pfb < mf
Copyright (c) 2000-2014 by George Williams. See AUTHORS for Contributors.
License GPLv3+: GNU GPL version 3 or later <
Hi all,
I've started to dive into looking up glyph alternates, but quickly realized
I'll need to have a bigger plan in place first regarding what naming system
LP uses internally (the job that is currently done via
Font_metric::find_by_name). I figured I should probably update you guys
with my
On Tue, Jun 23, 2020 at 12:39 PM Han-Wen Nienhuys wrote:
> On Tue, Jun 23, 2020 at 9:55 AM Jonas Hahnfeld via Discussions on
> LilyPond development wrote:
> >
> > Am Montag, den 22.06.2020, 16:44 -0700 schrieb Owen Lamb:
> > > Thanks, everyone! It looks like jsoncpp sh
Thanks, everyone! It looks like jsoncpp should work well for LilyPond.
I don't have experience with adding files from one project to another.
Jonas, is this "Amalgamated" procedure what you were describing?
https://github.com/open-source-parsers/jsoncpp/wiki/Amalgamated-(Possibly-outdated)
If
Hi all! Here with another weekly update.
This week, I corresponded with Daniel Spreadbury on the W3C Music Notation
Community Group public email list and Behdad Esfahbod on the HarfBuzz
mailing list, and received some clarifications on how to continue. It looks
like we won't need to add OpenType
Hi all,
I need to be able to expose the contents of a SMuFL font's JSON metadata
file to LilyPond. From what I can tell, LilyPond currently doesn't have any
sort of JSON-parsing library in its dependencies, either in Scheme or in
C++. An internet search revealed that there are... a *lot* of
On Tue, Jun 16, 2020 at 12:16 AM Han-Wen Nienhuys wrote:
> On Tue, Jun 16, 2020 at 9:06 AM Werner LEMBERG wrote:
[...] Now we have external
> > metadata files again – not a single one, but a bunch of them...
>
> They're putting the metadata in separate files?
If they are, I'm not aware of
Hi all,
Apologies for the lateness of this update. Last week was mostly research
into stylistic alternates and how to support OpenType features in a SMuFL
font, so not much was done in the way of code changes aside from creating a
proof-of-concept stylistic alternate mapping.
It appears that the
Hi Werner,
I can help here. Extracting lookup data for a single feature table in
an OpenType font is really just jumping from one font offset to
> another. However, I agree that it is better to use a higher-level
> approach if available.
>
That would be fantastic! Hopefully HarfBuzz will fit
Hi Werner,
It should be straightforward to set up a fully functional OpenType
table for stylistic alternatives, as you've started already – the
> 'salt' feature in a 'GSUB' table, I guess. LilyPond then extracts and
> parses this table directly (similar to 'LILY'). This should be rather
> easy
Hi Werner et al,
I've given Emmentaler an OpenType lookup subtable for stylistic alternates,
as the SMuFL specification suggests, and, as an experiment, I have
successfully encoded the two types of double whole note (breve), one as a
stylistic alternate of the other. However, LilyPond's current
Hi all,
This week, I was able to encode the whole note (semibreve) glyph in its
proper SMuFL-encoded spot in the PUA based on .mf log output.
I also got LilyPond to use a generated Scheme hash table to try to look up
a glyph's SMuFL character code before falling back to the old way. This was
>
> ... but not pushed yet, it seems.
Sorry about that! I thought I did... anyway, it's pushed now.
--Owen
Hi Werner,
Thank you for pointing out the Metapost documentation!
I've given it a look, and I wonder whether using a number type to store the
codes is worth the hassle of conditionally changing the number system.
According to the docs, there is no 0x prefix or anything similar to denote
a
Sun, May 31, 2020 at 12:50 AM wrote:
> >
> > Date: Sat, 30 May 2020 15:41:31 -0700
> > From: Owen Lamb
> > To: Werner LEMBERG , lilypond-devel@gnu.org
> > Subject: Metafont optional parameters
> > Message-ID:
> > uf...@mail.gmail.com>
> &
ds, not Unicode encoding.
>
>
>
> It’s been long enough since I worked on this that I’m apparently fuzzy.
>
>
>
> Sorry for the noise.
>
>
>
> Carl
>
>
>
>
>
>
>
>
>
>
>
> *From: *Owen Lamb
> *Date: *Monday, June 1, 2020 at 12:1
uggested, which you can see in my latest commit.
I suppose in the future it would be nice to know how to make optional
arguments in MF, but I only ever meant to use them here temporarily, so no
harm done. Does this all sound good?
--Owen
On Sun, May 31, 2020 at 1:31 AM Han-Wen Nienhuys wrote:
>
sen
wrote:
> On Sat, May 30, 2020 at 4:41 PM Owen Lamb wrote:
> >
> > Hi all,
> >
> > I'd like to add an optional parameter for smuflcode to fet_beginchar, so
> > that I don't have to take two lines redeclaring the variable in every
> > glyph. Ideally, it w
Hi all,
I'd like to add an optional parameter for smuflcode to fet_beginchar, so
that I don't have to take two lines redeclaring the variable in every
glyph. Ideally, it won't have to be optional once every character has it,
but in the meantime, it would help with testing individual characters'
Hi all. Sorry for the radio silence the past couple days. I got rather
overwhelmed trying to learn Metafont on my own, and the schedule I set up
for myself broke down rather quickly. I'll do my best to give my next
weekly report on time (i.e. on Friday).
Since I gave an update earlier this week,
Hi all,
I do believe I've finally tracked down the place where lilypond glyph names
are turned into character codes: Open_type_font::name_to_index. I can add a
ternary operator here based on whether the Open_type_font is_smufl (a new
property that, in the future, should be detected and set when
Ah! And of course, soon after I ask, I find that the point is moot. I'm
sticking Bravura deep in the build/out directory where the font files are,
which of course is already ignored by git. Thank you and sorry for the
trouble!
--Owen
On Wed, May 27, 2020 at 2:36 PM Werner LEMBERG wrote:
>
> >
Hi all!
I pushed the new dev/lamb/GSoC-2020 branch to origin yesterday, and it
appears to be visible on GitLab. I haven't committed anything new yet, but
I will soon. I'll push any commits I make at the end of each work day.
I plan to give updates regularly every Friday. So far I have been
Hi all,
I think I've got branching figured out. I pulled the latest changes from
origin/master to my machine's master, then created a new dev/lamb/GSoC-2020
branch from there.
It seems I need permission to push this new branch to origin and make it
publicly visible. Provided I understand this
>
> To preserve your code within LilyPond it probably makes sense if you put
> your code into a private (but public) branch of the upstream lilypond
> repository (i.e., not a gitlab clone of it), for example
> 'dev/lamb/GSoC-2020'.
>
I'm a bit confused here, so let me just make sure I understand
l Sorensen
> > Verzonden: Monday, May 11, 2020 5:43 AM
> > Aan: Owen Lamb ; Werner LEMBERG ;
> > lilypond-devel@gnu.org; Federico Bruni
> > Onderwerp: Re: Compiling from LilyDev
> >
> >
> > On 5/10/20, 8:50 PM, "lilypond-devel on behalf of Owen La
Hi all,
I've hit a couple roadblocks trying to compile LilyPond from LilyDev as per
the instructions on the website(
http://lilypond.org/doc/v2.21/Documentation/contributor/compiling-with-lilydev),
both during the "Preparing the build" step where ../configure is run.
First, the environment
Thank you so much! I'm looking forward to working with you all.
I'm not familiar with IRC, although I've heard the name passed around. If
this list is more active, I suppose I'll stay here. I do appreciate the
ability to spend time crafting a good email response.
In the meantime, I have a few
Hi all,
I'm new here--been using LilyPond and Frescobaldi for a month or so, and
I'm loving it. Being an undergrad music composition major and a coding
hobbyist (experience with Java & JS and a smattering of Python, C#, C++,
Haskell, and LilyPond's Scheme), I'm interested in applying for a GSoC
98 matches
Mail list logo
