> On 8 Feb 2020, at 13:51, Marnen Laibow-Koser wrote:
>
> From the feedback I’ve been getting, it looks like my 64-bit Mac builds are
> working well for most people. However, one user—one only one of two Macs
> he has access to—is consistently getting a segfault with these builds right
> aroun
> On 9 Feb 2020, at 15:09, Graham King wrote:
>
> From a speed-reading of Gould, it appears that she uses the verb "alter" and
> the adjective "altered", but _not_ the noun "alteration" in this context.
>
> It is worth noting that "alteration" has a very specific and well-established
> meani
> On 17 Feb 2020, at 17:04, Werner LEMBERG wrote:
>
>
> For fun I tried to execute
>
>
> https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83/2.19.83.build20200207173449
>
> on my old MacOS Lion box, with the following error.
>
> Traceback (most recent call last):
> …
> ImportE
> On 1 Mar 2020, at 23:45, Marnen Laibow-Koser wrote:
>
> One question as I continue to work on 64-bit Mac packaging: how do I set
> LOCALEDIR (in this case, to match the packaged app bundle rather than the
> build-time path)? Unlike everything else of this nature, neither the
> .reloc files n
> On 2 Mar 2020, at 01:46, Marnen Laibow-Koser wrote:
>
> On Sun, Mar 1, 2020 at 7:04 PM Hans Åberg wrote:
>
> > On 1 Mar 2020, at 23:45, Marnen Laibow-Koser wrote:
> >
> > One question as I continue to work on 64-bit Mac packaging: how do I set
> > L
> On 13 Apr 2020, at 17:15, hanw...@gmail.com wrote:
>
> On 2020/04/13 14:55:12, hahnjo wrote:
>> If the function is not meant to be implemented / used, it should be
> explicitly
>> deleted (C++11).
>
> Done.
>
> https://codereview.appspot.com/557680043/
One might prefer having a deleted oper
> On 5 May 2020, at 17:09, David Kastrup wrote:
>
> One reason is that we want to get rid of finalisers particularly in
> connection with the Boehm GC. Finalisers are called when garbage is
> collected, the collection of garbage is typically indicative of the
> expected lifetime of our objects
> On 5 May 2020, at 18:57, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 5 May 2020, at 17:09, David Kastrup wrote:
>>>
>>> One reason is that we want to get rid of finalisers particularly in
>>> connection with the Boehm GC. Fin
> On 6 May 2020, at 08:21, Han-Wen Nienhuys wrote:
>
> Regarding GC, once we leave behind GUILE 1.x, we could adorn all SCM
> containing structures with a operator new/operator delete, which calls
> scm_gc_alloc()/scm_gc_free(). That would get rid of marking functions.
> For vectors, we could i
> On 7 Aug 2020, at 08:17, Werner LEMBERG wrote:
>
> As the attached images show, the breathing sign *sometimes* collides
> with accidentals. Looks like a bug. If you agree I'll add it to the
> tracker.
>
> Any idea how to circumvent that?
In addition to that, I place the breath mark above
> On 20 Aug 2020, at 15:22, Phil Holmes wrote:
>
> If I go to http://lilypond.org/doc/v2.21/Documentation/notation/index.html
> and click any of the links, I get a page in Spanish, which I'm not.
>
> Anyone know why?
Probably because your parents weren't Spanish.
> On 26 Sep 2020, at 14:55, Werner LEMBERG wrote:
>
> Despite Gould's “incorrect” verdict, here is an example from an old UE
> edition of Liszt's “Liebestraum No. 1”, which demonstrates that ties
> over clef changes *do* happen and make sense sometimes...
>
> I still think that LilyPond should
> On 26 Sep 2020, at 18:04, Dan Eble wrote:
>
>> On Sep 26, 2020, at 09:41, Dan Eble wrote:
>>
>> On Sep 26, 2020, at 08:55, Werner LEMBERG wrote:
>>>
>>>
>>> Despite Gould's “incorrect” verdict, here is an example from an old UE
>>> edition of Liszt's “Liebestraum No. 1”, which demonstrat
> On 26 Sep 2020, at 19:56, Werner LEMBERG wrote:
>
The notes d♯ to e♭ have different pitches in the staff notation
system, which cannot express E12 enharmonic equivalents, so this
is slur. So it should be a slur that looks like slur.
>
> I disagree. For all practical purposes
> On 26 Sep 2020, at 19:36, Dan Eble wrote:
>
> On Sep 26, 2020, at 13:11, Hans Åberg wrote:
>>
>>>
>>> On 26 Sep 2020, at 18:50, Dan Eble wrote:
>>>
>>> On Sep 26, 2020, at 12:34, Hans Åberg wrote:
>>>>
>>>>>
> On 26 Sep 2020, at 20:58, Kevin Barry wrote:
>
> On Sat, 26 Sep 2020 at 19:30, Hans Åberg wrote:
>>>>>> The notes d♯ to e♭ have different pitches in the staff notation
>>>>>> system, which cannot express E12 enharmonic equivalents, so this
>
> On 27 Sep 2020, at 19:31, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 26 Sep 2020, at 18:04, Dan Eble wrote:
>>>
>>>> On Sep 26, 2020, at 09:41, Dan Eble wrote:
>>>>
>>>> On Sep 26, 2020, at 08:55, Werner LEMBE
> On 27 Sep 2020, at 20:20, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 27 Sep 2020, at 19:31, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
>>>>> On 26 Sep 2020, at 18:04, Dan Eble wrote:
>>>>>
> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser wrote:
>
>> I seem to remember that even in Bach's B minor mass (where E12 was not
>> yet a thing) there is an enharmonic tie (or at least tonal repetition?)
>> in the transition from "Confiteor" to "Et expecto". I mean, that
>> transition is a to
> On 27 Sep 2020, at 20:59, Kevin Barry wrote:
>
>> Both cases were discussed. For an orchestra they are not the same pitch,
>> thus formally a slur.
>
> You cannot make this assumption. It is exceptional to distinguish D
> sharp and E flat since most performed orchestral music is equally
> t
> On 27 Sep 2020, at 22:01, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 27 Sep 2020, at 19:57, Lukas-Fabian Moser wrote:
>>>
>>>> I seem to remember that even in Bach's B minor mass (where E12 was not
>>>> yet a thin
> On 27 Sep 2020, at 22:17, Werner LEMBERG wrote:
>
>>> It is common, for example, for a composer to write D sharp for some
>>> instruments and E flat for others.
>>
>> A composer should write so that it becomes easy for the musician to
>> perform, otherwise they will have to edit the score, w
> On 28 Sep 2020, at 00:26, Lukas-Fabian Moser wrote:
>
>>> However, this gets *never* notated as such.
>>>
>> I gave the example of augment sixth chords, that seem to never be notated as
>> diminished sevenths.
>>
>> https://en.wikipedia.org/wiki/Augmented_sixth_chord
> I assume you meant "
> On 16 Jan 2021, at 13:05, Werner LEMBERG wrote:
>
> According to
>
> https://ports.macports.org/port/lilypond/summary
>
> the problems with the dependencies have been fixed; this means that
> lilypond should now install fine using MacPorts on Apple silicon.
I tried building lilypond-devel
> 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 Noteheads, and Shape-note Noteheads),
> so feel free to give it a look at
> https://wolfgangsta.github.io/emmentaler-bravura/. P
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
>>> cate
> On 25 Sep 2021, at 17:47, Lukas-Fabian Moser wrote:
>
> And I think it would be nice to have an even more natural variant for that; I
> think it's reasonable to provide & show/recommend convenient solutions for
> standard tasks (rather than say "you can define your own abbreviation here if
> On 25 Sep 2021, at 18:37, Werner LEMBERG wrote:
>
>>> And I think it would be nice to have an even more natural variant
>>> for that; I think it's reasonable to provide & show/recommend
>>> convenient solutions for standard tasks (rather than say "you can
>>> define your own abbreviation here
> On 25 Sep 2021, at 19:25, Werner LEMBERG wrote:
>
Perhaps the LilyPond syntax might be tweaked so that identifiers
starting with a UTF-8 multi-byte (high bit set) character do not
need the backslash. Then simply ×2 would look good.
>>>
>>> This reminds me of TeX's 'active cha
> On 26 Sep 2021, at 06:49, Werner LEMBERG wrote:
>
The idea here is different, it is for identifiers, and in the
input syntax only, does not change the internal semantics at all.
It is good not having to type backslash when a command is used.
>>>
>>> Really? I highly doubt tha
> On 26 Sep 2021, at 10:16, Jean Abou Samra wrote:
>
> Le 26/09/2021 à 09:57, Hans Åberg a écrit :
>>> On 26 Sep 2021, at 06:49, Werner LEMBERG wrote:
>>>
>>> You might provide a MR, maybe it gets accepted. I still doubt that it
>>> would b
> On 9 Nov 2021, at 00:50, Karlin High wrote:
>
> On 11/8/2021 4:55 PM, Kieren MacMillan wrote:
>> I’m on 10.13.6 (High Sierra)
>
> High Sierra can still run 32-bit, right? That could allow for using GUB on
> LilyDev to produce a standard macOS installer.
The intent is probably to create an
> On 9 Nov 2021, at 19:06, Kieren MacMillan
> wrote:
>
> Hi Hans,
>
>> One can make installers with MacPorts, I posted some on the users list.
>
> I found that thread — helpful!
>
> I tried, and got:
>
> Error: …
You tried what? Making your own installer from MacPorts? —The ones I do ins
> On 9 Nov 2021, at 19:06, Kieren MacMillan
> wrote:
>
> Hi Hans,
>
>> The intent is probably to create an app.
>
> Yes, for me to run (personally).
>
>> One can make installers with MacPorts, I posted some on the users list.
>
> I found that thread — helpful!
>
> I tried, and got:
>
> E
> On 9 Nov 2021, at 19:06, Kieren MacMillan
> wrote:
>
>> The intent is probably to create an app.
>
> Yes, for me to run (personally).
>
>> One can make installers with MacPorts, I posted some on the users list.
>
> I found that thread — helpful!
>
> I tried, and got:
>
> Error: Failed t
> On 11 Nov 2017, at 12:52, Urs Liska wrote:
>
>
>
> Am 11.11.2017 um 12:30 schrieb David Kastrup:
>> I find "grouping" without "beat" fine. I could have been responsible
>> for the terminology in the code (pretty sure I wasn't, but it matches
>> the terminology I use quite better).
>>
>> N
> On 11 Nov 2017, at 12:52, Urs Liska wrote:
>
>
>
> Am 11.11.2017 um 12:30 schrieb David Kastrup:
>> I find "grouping" without "beat" fine. I could have been responsible
>> for the terminology in the code (pretty sure I wasn't, but it matches
>> the terminology I use quite better).
>>
>> N
> On 11 Nov 2017, at 12:52, Urs Liska wrote:
>
>
>
> Am 11.11.2017 um 12:30 schrieb David Kastrup:
>> I find "grouping" without "beat" fine. I could have been responsible
>> for the terminology in the code (pretty sure I wasn't, but it matches
>> the terminology I use quite better).
>>
>> N
> On 24 Jan 2018, at 18:46, David Kastrup wrote:
>
> Joseph Austin writes:
>
>> I asked this question on the user forum but got no answers.
>>
>> My lilypond error messages are in Spanish, but my language is English.
>> I do have the Spanish keyboard options present on my Mac (Sierra 10.12.3
> On 24 Jan 2018, at 18:46, David Kastrup wrote:
>
> Joseph Austin writes:
>
>> I asked this question on the user forum but got no answers.
>>
>> My lilypond error messages are in Spanish, but my language is English.
>> I do have the Spanish keyboard options present on my Mac (Sierra 10.12.3
> On 26 Jan 2018, at 16:05, Joseph Austin wrote:
>
> Hans,
> From Mac terminal, I run the locale command and get the following:
> joemacbook:~ josephaustin$ locale
> LANG="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_CTYPE="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
>
> On 27 Jan 2018, at 17:51, Joseph Austin wrote:
>
> When I run from Terminal, I get messages in English.
> When I run through Frescobaldi, I get messages in English
>
> When I run by clicking the app name in the Applications folder, I get
> messages in Spanish,
> even with version 2.19.80-1
> On 14 May 2018, at 01:28, Dave Tremblay wrote:
>
> Hi, I just found out about your software, and I love it! Great work, and very
> powerful tool. However, I wonder if it would be possible to make it play, or
> at least display, microrhythms, as there are no available option that I know
> of
> On 14 May 2018, at 01:28, Dave Tremblay wrote:
>
> Hi, I just found out about your software, and I love it! Great work, and very
> powerful tool. However, I wonder if it would be possible to make it play, or
> at least display, microrhythms, as there are no available option that I know
> of
> On 15 May 2018, at 04:12, Dave Tremblay wrote:
>
> Thanks a lot! I’m not very proficient with lilypond just yet, but when I have
> some time to myself and work with it I’ll go back to this message and try it
> out! Thanks!
You are welcome. Keep the CC so that the community can follow: It ma
> On 19 May 2018, at 12:13, Torsten Hämmerle wrote:
>
> Dave Tremblay wrote
>> However, I wonder if it would be possible to make it play, or at least
>> display, microrhythms, [...]
>
> MIDI playback of microrhythms (including interpolation between the two
> notated extremes by applying time-de
> On 22 May 2018, at 06:01, metachromatic wrote:
> Different percentages of microrhythm will require correspondingly
> larger tuplets, and, due to the bad design decision to represent
> rhythms internally in Lilypond as integers, you'll soon run out of
> integers to represent extremely large tu
[Adding reference that dropped out.]
I used continued fractions; see [1], which gives some useful algorithms. They
converge very quickly, and one can refine to a suitable degree. In music, one
does not need very large denominators, as the timing quickly becomes fine
enough.
1. https://en.wikip
> On 22 May 2018, at 20:45, David Kastrup wrote:
>
> LilyPond's "rational" type should indeed get replaced
> by Guile's rational types which would seriously shift the threshold
> where things start breaking apart at the cost of efficiency.
>
> That's quite a lot of tedious work (I have some sta
> On 22 May 2018, at 21:10, Hans Åberg wrote:
>
>
>> On 22 May 2018, at 20:45, David Kastrup wrote:
>>
>> LilyPond's "rational" type should indeed get replaced
>> by Guile's rational types which would seriously shift the threshol
> On 22 May 2018, at 22:07, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 22 May 2018, at 20:45, David Kastrup wrote:
>>>
>>> LilyPond's "rational" type should indeed get replaced
>>> by Guile's rational types which
> On 22 May 2018, at 22:53, David Kastrup wrote:
>
>>> This was somewhat complicated by some Midi classes being heap-allocated
>>> and containing Rational/Moment members: those Midi classes would have to
>>> become SCM-connected. I did some work on that, don't remember how
>>> complete it was.
> On 22 May 2018, at 23:28, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 22 May 2018, at 22:53, David Kastrup wrote:
>>>
>>>>> This was somewhat complicated by some Midi classes being heap-allocated
>>>>> and containi
> On 23 May 2018, at 00:41, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 22 May 2018, at 23:28, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
>>>>>> I wrote a C++ wrap for that latter, too. As it turns out to
> On 23 May 2018, at 10:39, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 23 May 2018, at 00:41, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
>>>>> On 22 May 2018, at 23:28, David Kastrup wrote:
>>>&
> On 23 May 2018, at 11:04, Werner LEMBERG wrote:
>
>> The ultimate in self-assertion is to disagree with those that agree
>> with you.
>
> Hans, such remarks aren't helpful. You sound like you are lecturing.
> Maybe this is not your intention and you have serious questions – if
> this is so,
> On 23 May 2018, at 12:20, David Kastrup wrote:
>
> ... work on "the problem" has moved beyond the
> stage where one can just propose a generic solution, everybody slaps his
> forehead and gets to work and does what it takes to do.
How about using what I suggested and what you touched upon in
> On 23 May 2018, at 13:10, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 23 May 2018, at 12:20, David Kastrup wrote:
>>>
>>> ... work on "the problem" has moved beyond the stage where one can
>>> just propose a generic solut
> On 23 May 2018, at 14:34, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> I mentioned that the GC supports traditional allocations/deallocation,
>> but they must be traced so as to not end up with dead pointers.
>
> Hans, please. You are proferring utter tr
> On 23 May 2018, at 15:46, David Kastrup wrote:
>
> Try actually reading the code. lily/include/smobs* are not that many
> files and nowadays pretty exclusively encapsulate all Scheme-related
> memory management.
As long you don't have pointers into that, as you suggested with Rational and
o
> On 23 May 2018, at 16:15, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 23 May 2018, at 15:46, David Kastrup wrote:
>>>
>>> Try actually reading the code. lily/include/smobs* are not that many
>>> files and nowadays pretty exclu
> On 23 May 2018, at 18:12, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> I ended up using GC_malloc_uncollectable, because it turned out too
>> tricky to use malloc.
>
> This is C++, so we basically end up with operator ::new and operator
> ::delete unles
> On 23 May 2018, at 18:36, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 23 May 2018, at 18:12, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
>>>> I ended up using GC_malloc_uncollectable, because it turned ou
> On 23 May 2018, at 18:58, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 23 May 2018, at 18:36, David Kastrup wrote:
>>>
>>> Hans Åberg writes:
>>>
>>>>> On 23 May 2018, at 18:12, David Kastrup wrote:
> On 23 May 2018, at 19:32, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> But scm_malloc does not use GC_malloc_uncollectable, it seems, so it
>> too would require explicit markups in order to get internally in
>> Guile.
>
> Getting "internally in
> On 26 May 2018, at 08:35, metachromatic wrote:
>
> ... let's calculate the
> difference in time twixt a tuplet like 7919/4451 against a tuplet
> 7909/4447 over the course of two minutes and 13 seconds of 4/4 time at
> a tempo of metronome marking 90:
>
>The difference is (0.00064839149)*6
> On 26 May 2018, at 08:35, metachromatic wrote:
>
> ... let's calculate the
> difference in time twixt a tuplet like 7919/4451 against a tuplet
> 7909/4447 over the course of two minutes and 13 seconds of 4/4 time at
> a tempo of metronome marking 90:
>
> The difference is (0.00064839149)*60
> On 21 Jun 2018, at 10:48, d...@gnu.org wrote:
>
> I think C++19(?) or so already states that returned classes
> are to be considered initializers rather than temporaries.
Perhaps this is what you have in mind: C+17 returns prvalues without creating
temporaries; [1], first note.
1. https://e
> On 21 Jun 2018, at 00:30, nine.fierce.ball...@gmail.com wrote:
> Maybe a function would help:
>
>Transform make_transform(const Transform *t)
> {
>return t ? Transform (*t) : Transform ();
> }
>
> You could also do it as a constructor, if you prefer its syntax and
> d
> On 22 Jun 2018, at 11:09, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> You could also do it as a constructor, if you prefer its syntax and
>>> don't mind implementing yet another one:
>>>
>>> explicit Transform(const Transform *
> On 22 Jun 2018, at 14:27, David Kastrup wrote:
>
> What would that be good for concerning this issue?
Only you know that: you did not like the explicit constructor for some reason,
but didn't detail.
___
lilypond-devel mailing list
lilypond-dev
> On 5 Jul 2018, at 20:02, David Kastrup wrote:
>
> What C++ standard should we be able to ask for? I think that at the
> current point of time, C++11 should be reasonably fine for the asking.
The g++7 default, and clang++6, is C++14, but supports C++17 with the
--std=c++17 flag.
> Should w
> On 6 Jul 2018, at 00:17, Dan Eble wrote:
>
> On Jul 5, 2018, at 15:20, Hans Åberg wrote:
>>
>>> On 5 Jul 2018, at 20:02, David Kastrup wrote:
>>>
>>> What C++ standard should we be able to ask for? I think that at the
>>> current poi
> On 6 Jul 2018, at 11:12, d...@gnu.org wrote:
>
> On 2018/07/05 21:32:25, Dan Eble wrote:
>
>> The rationale is that std::optional is fit for this situation and if
> LilyPond
>> were built with C++17 I would simply have used it.
>
> Any C++17 lookalike package is _not_ "simply using it" but a
> On 7 Jul 2018, at 00:13, nine.fierce.ball...@gmail.com wrote:
>
> On Jul 6, 2018, at 18:02, Hans Åberg wrote:
> One can do it the other way around, too:
> #if __cplusplus < 201703L
> namespace std {
> using optional = Optional;
> }
> #endif
>
> Ugh. That’
> On 7 Jul 2018, at 00:26, nine.fierce.ball...@gmail.com wrote:
>
> On 2018/07/06 22:19:29, haberg-1_telia.com wrote:
>> The technique is useful for transforming code, though.
>
> Into what? :)
What you deem suitable. Cf.
https://en.wikipedia.org/wiki/Code_refactoring
_
> On 7 Jul 2018, at 09:35, David Kastrup wrote:
>
> Hans Åberg writes:
>
>>> On 6 Jul 2018, at 11:12, d...@gnu.org wrote:
>>>
>>> On 2018/07/05 21:32:25, Dan Eble wrote:
>>>
>>>> The rationale is that std::optional is fit for this
> On 7 Jul 2018, at 10:04, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> The idea is to do it all now, then the change is automatic and the old
>> code can just be removed at some point in time, but you would need a
>> compiler that can do C++17, too.
>
> On 7 Jul 2018, at 12:14, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> The first step would probably to switch to a later compiler with a
>> flag for an older C++ version. Then one can test later C++ versions in
>> independent builds.
>
> We are not
> On 7 Jul 2018, at 13:12, David Kastrup wrote:
>
> Hans Åberg writes:
>
>> There is a danger in using an older compiler that is not supported, as
>> there might be bugs that are not going to be fixed.
>
> Well, that's the point, isn't it? If
> On 7 Jul 2018, at 22:02, Werner LEMBERG wrote:
>
>> It took long time to get C++11 right, so it is best to avoid older
>> compilers I think.
>
> I disagree. The proper way is to test various C++11 features to check
> whether a compiler really supports this standard. The macro
> AX_CXX_COMP
> On 8 Jul 2018, at 08:00, Werner LEMBERG wrote:
>
>
>>> I disagree. The proper way is to test various C++11 features to
>>> check whether a compiler really supports this standard. The macro
>>> AX_CXX_COMPILE_STDCXX does such checks, BTW.
>>
>> Full C++11 support was first in GCC 4.8.1, se
> On 18 Sep 2018, at 19:01, Adam Good wrote:
>
> Hi everyone!
> I'm assuming no one is currently working on the current issues involving
> transposition when using makam.ly ... if so please be in touch with me.
> Otherwise, would anyone be willing to work on it? I'm MORE than happy to
> sponsor
> On 20 Sep 2018, at 17:40, Adam Good wrote:
>
> Thank you so much for the reply and suggestions!
>
> Previously I've gone down the route of creating my own makam.ly file and
> defining every ratio that comes up as an error but remember it being a bit
> endless. Might be a rabbit hole. But what
> On 21 Sep 2018, at 00:00, Adam Good wrote:
>
> Hans this is great, I'm on a roll over here. Will pick up on this in a couple
> of days.
Start with that. One can also use glyphs that LilyPond does not have using
SMuFL.org: With that, the regularE53.ly can for example be set in
Helmholz-Ell
> On 20 Oct 2018, at 03:24, Adam Good wrote:
>
> Hi Hans,
> I hope this email finds you well. Some questions for you if you have time
> plus I want to share my close to complete turkish makam file based on the
> file you sent me originally plus regular.ly
>
> here's the new makam include file
> On 20 Oct 2018, at 03:24, Adam Good wrote:
>
> I hope this email finds you well. Some questions for you if you have time
> plus I want to share my close to complete turkish makam file based on the
> file you sent me originally plus regular.ly
>
> here's the new makam include file:
> turkish
> On 20 Oct 2018, at 19:03, David Kastrup wrote:
>
>> The only difference is that I have 0 in some positions where you have 0/53.
>
> To Scheme that is no difference.
Indeed, I was thinking about 1/53. :-)
___
lilypond-devel mailing list
lilypond
> On 20 Oct 2018, at 19:25, Adam Good wrote:
>
> Hans thank you for passing this along to the dev list, replies below...
Yes, it is important to le other to be able to follow, especially with such
nice examples!
> On Sat, Oct 20, 2018 at 4:40 AM Hans Åberg wrote:
>
&g
> On 20 Oct 2018, at 19:25, Adam Good wrote:
>
> Could you please show a pdf of your Cemil Bey Hicazkar Pesrev using HE
> arrowed accidentals? And how to make that an option?
One only needs two extra files (below) that define and call the accidental
glyphs in the Bravura.otf font, which in tur
> On 21 Oct 2018, at 10:56, Torsten Hämmerle wrote:
>
> 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!
Thanks!
> If I understand it corr
> On 21 Oct 2018, at 10:10, Graham Breed wrote:
>
> On 2018-10-20 02:24, Adam Good wrote:
>> Hi Hans,
>> I hope this email finds you well. Some questions for you if you have time
>> plus I want to share my close to complete turkish makam file based on the
>> file you sent me originally plus r
> On 21 Oct 2018, at 14:42, Torsten Hämmerle wrote:
>
> 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.
> On 21 Oct 2018, at 17:34, Torsten Hämmerle wrote:
>
> 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 certainl
> On 21 Oct 2018, at 17:41, Adam Good wrote:
>
> Hans and everyone,
> This is about as much as I can do for a new Turkish Makam .ly file,
> see attached: turkish-makam.ly Hans it's very similar to what I sent you
> privately, took out some unwanted pitch definitions.
>
> I can see this replacin
> On 23 Oct 2018, at 04:56, Adam Good wrote:
>
> On Sun, Oct 21, 2018 at 12:28 PM Hans Åberg wrote:
>
>>
>> I made a version that allows one to switch to Helmholtz-Ellis notation,
>> with arrow accidentals: Just uncomment the line
>> %\bravuraOn
&g
> On 25 Oct 2018, at 06:02, Adam Good wrote:
>
> On Tue, Oct 23, 2018 at 9:42 AM Hans Åberg wrote:
>>
>> > On 23 Oct 2018, at 04:56, Adam Good wrote:
>> >
>> Does it sound lower in standard Turkish performance, that is, which does not
>> refer t
> On 21 Oct 2018, at 10:56, Torsten Hämmerle wrote:
>
> Incidentally, I'm planning to fill in the Emmentaler gaps in the (very) near
> future directly
...
> The Metafont overhaul was, among others, the reason why it took so long (but
> it's in the final internal testing phase now, struggling wit
> On 31 Oct 2018, at 19:51, Adam Good wrote:
>
> I have issues in that the tonic of these makams is a microtone. In standard
> Turkish notation, "fb" which is "f" 4k sharp
> We need
> \key fb \bestenigar
Is this right? It is traditional to raise the third below the finalis, but not
in the oc
1 - 100 of 226 matches
Mail list logo
