Hi David,
> It's just possible that the Guix developers will refuse accepting a
> Guile-1.8 development package on philosophical grounds.
We Guix people have had a “guile-1.8” package since a long time and it
is still used by our “lilypond” package. There are no plans to remove
it.
--
Ricardo
Hi Conor,
David Kastrup writes:
> For extending LilyPond, you need Scheme. Scheme knowledge is only of
> limited marketing value but of course the general kind of solving
> programming tasks from within a fourth generation extension language may
> still be reasonably relevant.
Carl Sorensen writes:
>>Midi Sounds
>>__
>>
>>I¹m no midi expert, but I¹ve used it over the years. My impression is
>>that tools like Apple Logic, Sibelius, and so on, provide their own
>>sounds, which are unrelated, in particular, to midi, which only gives a
David Kastrup <d...@gnu.org> writes:
> Ricardo Wurmus <rek...@elephly.net> writes:
>
>>>> I don't know what the current Guile-2.0 situation is, but compiling
>>>> Guile-2.1 (namely master) is insane. It takes about a day on my
>>>> comp
>> I don't know what the current Guile-2.0 situation is, but compiling
>> Guile-2.1 (namely master) is insane. It takes about a day on my
>> computer.
>
> Took me ~8h
There is a “guile-next” package for GNU Guix, which makes it possible to
get a binary build of Guile 2.1.1 (built from the 2.1.1
Philip Olson writes:
> I just finished a beta version of my lilypond version manager "lilyvm" found
> on
> github
>
> https://github.com/olsonpm/lilyvm
>
> I'm emailing because I would like to know whether it's a tool that would help
> anyone besides myself, and
Hi,
> I getting used to the BeagleBone Black, so I though I'd try compiling
> Lilypond. It runs Debian, but on an ARM. LilyPond hasn't provided a
> precompiled binary for ARM for a decade.
The GNU Guix project is providing binary substitutes for Lilypond for
four systems (armhf, mips64el, i686,
are there any plans to build a Docker image for building LilyPond? It would
be a much more lightweight solution than a VirtualBox image, so I think
contributors would be grateful.
I would like to note that Lilypond has been packaged for GNU Guix, a
functional package manager. To create a
e9686ff0e6534292278924de4ac1586e366adcd5 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus rek...@elephly.net
Date: Mon, 23 Feb 2015 23:00:54 +0100
Subject: [PATCH] Add scheme engraver for StaffTab notation
The StaffTab notation is a system combining graphic elements of
tablature with standard music
an example of how to use it:
nyan.ly
Description: Binary data
I'm not particularly fond of the position of the fret indicators, nor do I like
that they get so very close to the annotations (arr. Ricardo Wurmus) on the
top right.
This is not *exactly* the same as StaffTab notation as the string
Werner LEMBERG writes:
Just having a quick look (since I don't understand Tab notation at
all) I ask you the same as almost everybody else who commits a patch
the first time: Please try to limit the line length to 80 characters!
The line length in the patch is already limited to 80
Werner LEMBERG writes:
The line length in the patch is already limited to 80 characters.
Indeed, the line length is OK in stafftab-engraver.scm, but both
stafftab.ly and string-tunings-init.ly exceed the limit.
Ah, I see. Sorry about that. I already modified stafftab.ly to break
the
David Nalesnik writes:
When I apply your patch and try to compile the example file I get:
warning: cannot find or create new `StaffTab'
warning: cannot find or create new `StaffTab'
warning: cannot find or create new `StickVoice'
warning: cannot find or create new `StickVoice'
MIDI output
Hi,
a while ago I wrote a scheme engraver that outputs something close to
StaffTab notation. StaffTab notation is a mix of standard two staff
notation with a few elements of tabulature tailored to the free hands
methods of playing the Chapman Stick.
Here's the essence of what it does:
The
So ly:glob-property has side effects because of the stem callback?
How can I make sure to get the final stem direction after all
dependent properties were calculated?
I want to replace a note head with a triangle, but there is a gap
between note head a stem when the stem points upward.
Hi list,
I'm having a problem with a scheme engraver. Whenever I fetch the
direction property of a grob's stem object (or directly through a
listener on stem-event), the following warning is shown:
warning: no viable initial configuration found: may not find good
beam slope
The
On Aug 10, Reinhold Kainhofer wrote:
Am Mittwoch, 10. August 2011, 17:11:44 schrieb Ricardo Wurmus:
On Aug 10, Neil Puttock wrote:
BTW, if you're prepared to wrap the notes in a chord (so you have
access to 'articulations), you won't even need a scheme engraver (all
the processing can
Hello,
I'm currently attempting to write a custom engraver in scheme.
This is the shortened code:
;; global variables to be used in `do-something'
#(define g_filled #f)
#(define g_direction 0)
#(define g_finger 0)
#(define g_string-number 0)
;;
#(define-public
On Aug 10, Reinhold Kainhofer wrote:
Am Wednesday, 10. August 2011, 09:44:00 schrieb Ricardo Wurmus:
Hello,
I'm currently attempting to write a custom engraver in scheme.
This is the shortened code:
It will increase the chances for a useful answer dramatically if you could
attach
I have now spent ~25 minutes trying to strip down the engraver and adding what
you had in your first mail, but I can't reproduce anything. The music-cause
simply does not have any articulations here.
So, I now wasted almost half an hour for what?
Oh shoot, I confused my example scores. I just
On Aug 10, Neil Puttock wrote:
On 10 August 2011 15:00, Ricardo Wurmus ricardo.wur...@gmail.com wrote:
Is there a way to change that order, or call the note-head-interface
function again at the very end for processing a grob?
Acknowledger order depends on the order engravers are \consist
21 matches
Mail list logo