If you wanted to avoid having an external server, you could always use Docker.
I’ve been running LP in a Docker container on my mac for a couple of months
now, and it’s worked flawlessly.
--Steven
From: lilypond-user On
Behalf Of Austin Blaser
Sent: Tuesday, March 5, 2019 7:20 PM
To: Karlin
Regarding the iOS App Store: Oh yeah I forgot about the licensing: definitely a
potential deal breaker. One other possibility I’ve thought about is building an
iOS app that would have all the text editing capability one would need, but
then send the .ly files to a backend server to typeset with
On Tue, Mar 5, 2019, 8:02 PM Austin Blaser wrote:
> I’d like to make an attempt at compiling Llilypond on the Mac.
That sounds like an interesting project. If it turns out to not be very
hard, it might influence software distribution choices for LilyPond.
I’m an iOS developer, so I’m also inte
I’d like to make an attempt at compiling Llilypond on the Mac. I’m an iOS
developer, so I’m also interested to see if we can compile it to run natively
for iOS as well. Compiling for OSX is a good first step to getting it running
on iOS.
Who would be the best contact to help with any trouble-sh
Karlin High writes:
> On 3/5/2019 11:10 AM, David Kastrup wrote:
>>> I don't know if anybody has tried building 64-bit executables in GUB
>>> using the current Darwin SDK. If that works, we'd have a regular
>>> build. But I don't think that's a feasible path forward long-term.
>
>> I think it w
On 3/5/2019 11:10 AM, David Kastrup wrote:
I don't know if anybody has tried building 64-bit executables in GUB
using the current Darwin SDK. If that works, we'd have a regular
build. But I don't think that's a feasible path forward long-term.
I think it would be feasible and likely the best
Am 05.03.19 um 19:27 schrieb Rachel Knight:
That idea should have worked, but the ties don’t look quite right.
Below is a compilable example.
Yes, that's why working with hidden extra notes is a bit messy: We have
to prevent those from taking up space. (Omit the \hideNotes to
understand what
That idea should have worked, but the ties don’t look quite right. Below is a
compilable example.
Rachel
\version "2.19.81"
down = { \change Staff = "bass" \stemUp }
up = {\change Staff = "treble" \stemDown}
\language "english"
Treble = {
<<
\relative c'
{
\set tieWaitForNote = ##t
How to control vertical spacing in the middle of a piece?
\new StaffGroup \with
{ \override StaffGrouper.staff-staff-spacing.padding = 10 } % It's OK
<<
\new Staff
{
c' c' c' c'
\break
\override StaffGrouper.staff-staff-spacing.padding = 30 % It isn't work
c' c' c' c'
Carl Sorensen writes:
> Our current build system doesn't use the Apple SDK; instead it uses a
> Darwin SDK which was created for use with open-source software.
Unfortunately, this is wishful thinking. Our current build system uses
a version of the Apple SDK that is so old that we are unable to
On 3/4/19, 10:20 PM, "Mason Hock" wrote:
On 03/02, Carl Sorensen wrote:
> We cannot use our regular build system to create LilyPond binaries due to
Apple’s restrictive licensing on the OSX SDK.
Could you explain briefly or link to why this is? I understand that the
App Store
Ok, this does the trick:
oddHeaderMarkup = \markup
\fill-line {
" "
\on-the-fly \not-part-first-page
\on-the-fly #print-page-number-check-first
\fromproperty #'page:page-number-string
}
evenHeaderMarkup = \markup
\fill-line {
\on-the-fly \not-part-first-page
\on-t
Karlin High writes:
> On 3/5/2019 8:27 AM, Kieren MacMillan wrote:
>> I have a half-dozen Mac machines (of various ages and superpowers)
>> here, most of which do nothing >95% of the time. If "running GUB for
>> official builds" is a relatively one-click process [assuming the
>> setup is already
Kieren MacMillan writes:
> Hi Karlin,
>
>> Nothing. But unless the person running GUB for official builds is a
>> big Mac fan and wants to go to extra effort to produce macOS
>> installers, it's doubtful those will be coming from lilypond.org.
>
> I have a half-dozen Mac machines (of various ages
On 3/5/2019 8:27 AM, Kieren MacMillan wrote:
I have a half-dozen Mac machines (of various ages and superpowers) here, most of which do
nothing >95% of the time. If "running GUB for official builds" is a relatively
one-click process [assuming the setup is already done, of course!], then I’m happ
Hi Karlin,
> Nothing. But unless the person running GUB for official builds is a big Mac
> fan and wants to go to extra effort to produce macOS installers, it's
> doubtful those will be coming from lilypond.org.
I have a half-dozen Mac machines (of various ages and superpowers) here, most
of w
Kieren MacMillan writes:
> Hi David,
>
>> Frankly, I am not overly interested in tap-dancing around the rules
>> Apple makes in order to keep its users from benefitting from software
>> freedom. When the rules Apple makes prohibit us from providing LilyPond
>> on MacOSX in a useful and reasonabl
On 3/5/2019 7:32 AM, Kieren MacMillan wrote:
what’s keeping someone with a Mac from compiling Lilypond on their Mac?
Nothing. But unless the person running GUB for official builds is a big
Mac fan and wants to go to extra effort to produce macOS installers,
it's doubtful those will be coming
Hi David,
> Frankly, I am not overly interested in tap-dancing around the rules
> Apple makes in order to keep its users from benefitting from software
> freedom. When the rules Apple makes prohibit us from providing LilyPond
> on MacOSX in a useful and reasonably sustainable manner, the conclusi
Sven Axelsson writes:
> On Tue, 5 Mar 2019 at 12:59, David Kastrup wrote:
>
>> Apple disallows using the OSX SDK on non-Apple hardware. That
>> definitely is a dealbreaker for GUB.
>>
>
> If that is the problem, couldn't we get around it by running GUB in a
> virtual machine on a Mac?
Frankly,
On Tue, 5 Mar 2019 at 12:59, David Kastrup wrote:
> Apple disallows using the OSX SDK on non-Apple hardware. That
> definitely is a dealbreaker for GUB.
>
If that is the problem, couldn't we get around it by running GUB in a
virtual machine on a Mac?
--
Sven Axelsson
++[>++>++
Mason Hock writes:
> On 03/02, Carl Sorensen wrote:
>> We cannot use our regular build system to create LilyPond binaries
>> due to Apple’s restrictive licensing on the OSX SDK.
>
> Could you explain briefly or link to why this is? I understand that the
> App Store's restrictions would violate th
22 matches
Mail list logo