Re: GUB

2018-07-13 Thread Ricardo Wurmus
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

Re: Programming Language

2016-08-11 Thread Ricardo Wurmus
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.

Re: midi articulation

2016-03-25 Thread Ricardo Wurmus
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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

2016-01-09 Thread Ricardo Wurmus
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

Re: guilev2-work [was: LilyPond boolean syntax? \true and \false]

2016-01-09 Thread Ricardo Wurmus
>> 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

Re: lilypond version manager

2016-01-03 Thread Ricardo Wurmus
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

Re: compiling on Debian on an ARMv7

2015-10-05 Thread Ricardo Wurmus
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,

Re: Fwd: LilyDev Docker image?

2015-06-26 Thread Ricardo Wurmus
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

Re: [PATCH] Add scheme engraver for StaffTab notation

2015-03-01 Thread Ricardo Wurmus
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

[PATCH] Add scheme engraver for StaffTab notation

2015-02-23 Thread Ricardo Wurmus
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

Re: [PATCH] Add scheme engraver for StaffTab notation

2015-02-23 Thread Ricardo Wurmus
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

Re: [PATCH] Add scheme engraver for StaffTab notation

2015-02-23 Thread Ricardo Wurmus
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

Re: [PATCH] Add scheme engraver for StaffTab notation

2015-02-23 Thread Ricardo Wurmus
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

scheme engraver for StaffTab notation

2015-01-07 Thread Ricardo Wurmus
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

Re: chaotic stems when querying direction property

2011-08-14 Thread Ricardo Wurmus
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.

chaotic stems when querying direction property

2011-08-13 Thread Ricardo Wurmus
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

Re: custom engraver in scheme: accessing nested Music object

2011-08-11 Thread Ricardo Wurmus
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

custom engraver in scheme: accessing nested Music object

2011-08-10 Thread Ricardo Wurmus
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

Re: custom engraver in scheme: accessing nested Music object

2011-08-10 Thread Ricardo Wurmus
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

Re: custom engraver in scheme: accessing nested Music object

2011-08-10 Thread Ricardo Wurmus
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

Re: custom engraver in scheme: accessing nested Music object

2011-08-10 Thread Ricardo Wurmus
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