Re: Moving a tempo mark to the right

[David Wright]

On Fri 01 Sep 2017 at 23:14:13 (+0200), David Kastrup wrote:
> Anthony Youngman  writes:

> > Nothing to do with the distro - as I said I daren't upgrade. Firstly,
> > gentoo has dropped KDE4 which means major UI changes which will give
> > my wife panic attacks (slight exaggeration, but not much). (Plus a big
> > learning curve for me.) And secondly my hardware is not quite
> > trustworthy - gcc crashes a lot which I think is down to the CPU
> > somewhere :-( Dunno why it's only gcc that seems to suffer (remember,
> > the distro is gentoo :-)
> 
> Gcc's internal data structures tend to be quite prone to corruption.
> I've had flaky memory that had no problems surviving days of elaborate
> memory pattern tests but did not survive 20 minutes of kernel
> compilation.  Change the memory for known good memory, and the kernel
> compiled fine.  No idea what Gcc does that memory test programs fail to
> account for.

http://www.tldp.org/FAQ/sig11/html/index.html

This page is ancient but I don't think much has changed, except
that I no longer find it necessary to compile my own kernels for
Debian. Decades ago, I would buy (rather, have bought for me)
new modules to increase the memory in my acquired PCs; maybe that
helped in staying error-free. I don't do much compiling now, and
certainly not linux kernels.

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Anthony Youngman]

On 01/09/17 23:19, David Kastrup wrote:

Anthony Youngman  writes:


On 01/09/17 22:14, David Kastrup wrote:

Change the memory for known good memory, and the kernel
compiled fine.  No idea what Gcc does that memory test programs fail to
account for.


Have you come across the memory smashing exploit? I can't remember
much about it, but if you can hammer memory in your own VM, you can
actually corrupt memory in the next door VM. Even worse, you can
control the corruption with the intent of hacking into the VM!

I'm pretty certain there are proofs of concept out there. So I guess
gcc might be doing exactly that by accident to cheap memory (my RAM is
the "value" brand - paid about £13 per 4GB stick). When I think back
the first memory I ever bought was £50 for a 32*M*B stick :-)


The first memory I bought was about DM800 for 64kByte and I had to
solder it to the PCB myself, all 32 DIP packages.  And it needed +12V
and -5V rails in addition to the +5V rail to run.


Ouch!

£1 = 3DM roughly, iirc?


The first external data media I worked with was cardboard, and the
biggest longterm data storage peril were mice.  And I don't mean the
input devices but the rodents.

The first PC I *bought* was a Pentium (actually a 686), but seeing as I 
started work as a programmer immediately on leaving school I had access 
to old computers my employer(s) were scrapping.


The first piece of hardware I remember my employer buying was one of 
those 300MB drives - you know - the ones with the 10-platter diskpacks, 
and the size of a domestic fridge. It quadrupled our storage capacity!


Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[David Kastrup]

Anthony Youngman  writes:

> On 01/09/17 22:14, David Kastrup wrote:
>> Change the memory for known good memory, and the kernel
>> compiled fine.  No idea what Gcc does that memory test programs fail to
>> account for.
>
> Have you come across the memory smashing exploit? I can't remember
> much about it, but if you can hammer memory in your own VM, you can
> actually corrupt memory in the next door VM. Even worse, you can
> control the corruption with the intent of hacking into the VM!
>
> I'm pretty certain there are proofs of concept out there. So I guess
> gcc might be doing exactly that by accident to cheap memory (my RAM is
> the "value" brand - paid about £13 per 4GB stick). When I think back
> the first memory I ever bought was £50 for a 32*M*B stick :-)

The first memory I bought was about DM800 for 64kByte and I had to
solder it to the PCB myself, all 32 DIP packages.  And it needed +12V
and -5V rails in addition to the +5V rail to run.

The first external data media I worked with was cardboard, and the
biggest longterm data storage peril were mice.  And I don't mean the
input devices but the rodents.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Anthony Youngman]

On 01/09/17 22:14, David Kastrup wrote:

Change the memory for known good memory, and the kernel
compiled fine.  No idea what Gcc does that memory test programs fail to
account for.


Have you come across the memory smashing exploit? I can't remember much 
about it, but if you can hammer memory in your own VM, you can actually 
corrupt memory in the next door VM. Even worse, you can control the 
corruption with the intent of hacking into the VM!


I'm pretty certain there are proofs of concept out there. So I guess gcc 
might be doing exactly that by accident to cheap memory (my RAM is the 
"value" brand - paid about £13 per 4GB stick). When I think back the 
first memory I ever bought was £50 for a 32*M*B stick :-)


Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Kieren MacMillan]

Hi Wol,

> I still want some way of making rehearsal marks push notes sideways out of 
> the way, as it looks naff and can waste space, but it's much better.

{
  \tweak RehearsalMark.extra-spacing-height #'(-inf.0 . +inf.0)
  \tweak RehearsalMark.extra-spacing-width #'(-0.5 . 0.5)
  \tweak RehearsalMark.self-alignment-X #LEFT
  \mark \markup "TESTING THIS MARK"
  c''1
}

Hope this helps!
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[David Kastrup]

Anthony Youngman  writes:

> On 01/09/17 21:36, David Kastrup wrote:
>>> I find the same thing with databases. So many people have their minds
>>> stuck in the 2-D relational world, and just cannot grasp the concept
>>> of a multi-dimensional database like Pick. Given that Pick is very
>>> much list-based (unlike SQL which is set-based), why can't I grasp a
>>> list-based language like Scheme? And Pick is very XML-like!
>> Because Scheme (like all LISP variants) does not even have a programming
>> language.  It has a clever way to write down parse trees as a
>> computer-readable data structure, bypassing the step of coding in a
>> programming language.  That makes it brilliant for structure-preserving
>> program manipulation and AI.
>
> But Scheme *IS* a language. Although I do understand exactly what you
> mean - my very first computer was a Jupiter Ace, which used Forth
> instead of BASIC.

No, Forth is a language.  It is compiled into code and the input does
not reflect the structure of the code: there is nothing delimiting a
BEGIN/UNTIL construct.  It cannot be manipulated structure-preserving.

LISP and Scheme have a REPL (read/eval/print loop).  Expressions are
_read_, evaluated, and printed.

(if (= x 3) 7 5)

is read as a list with its first element being the symbol "if", its
second element being the list (= x 3) and its third and fourth elements
being the numbers 7 and 5.  You can manipulate that list before
evaluating it, and macros do exactly that: they manipulate their
arguments into something different before it gets evaluated.

Early variants of Lisp never had a significantly compiled
representation: they just worked off the lists.  It helped that symbols
had value and function cells, rendering any further lookup unnecessary
once you had the symbol.  Guile compiles to varying degrees and does the
module lookup that connects symbols with particular variables (and thus
values) at compile time.

> So I've been exposed to that sort of thing right from the start, but I
> never really used it much.

It's completely different because Forth does not read data structures
but only single words and executes actions right away.  There is no
representation of the input to manipulate and consequently no macros
(the use of IMMEDIATE words within : ... ; sequences is not really
comparable since they do only stack manipulation and don't manipulate
actual input).

> Nothing to do with the distro - as I said I daren't upgrade. Firstly,
> gentoo has dropped KDE4 which means major UI changes which will give
> my wife panic attacks (slight exaggeration, but not much). (Plus a big
> learning curve for me.) And secondly my hardware is not quite
> trustworthy - gcc crashes a lot which I think is down to the CPU
> somewhere :-( Dunno why it's only gcc that seems to suffer (remember,
> the distro is gentoo :-)

Gcc's internal data structures tend to be quite prone to corruption.
I've had flaky memory that had no problems surviving days of elaborate
memory pattern tests but did not survive 20 minutes of kernel
compilation.  Change the memory for known good memory, and the kernel
compiled fine.  No idea what Gcc does that memory test programs fail to
account for.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Anthony Youngman]

On 01/09/17 21:11, Anthony Youngman wrote:
The big problem I can see is if sometimes it occurs at the start of a 
line, in which case the rehearsal mark will naturally move left out of 
the way, and letting lily move stuff around may move it to the middle of 
the line where I get a collision. Saying "move this grob a fixed 
distance" is going to completely mess up if this happens. So I need 
something that stops a collision, not something that moves text/marks 
out of the way.


BINGO!

Not perfect, but it looks a lot better. Dunno why, but I thought 
\markLengthOn affected rehearsal marks. It doesn't, it affects tempo 
marks, and it does exactly what I want, moving them out of the way so 
they don't collide with rehearsal marks! :-) :-) Even better, my tune 
names are aligned on the tempo marks! :-)


I still want some way of making rehearsal marks push notes sideways out 
of the way, as it looks naff and can waste space, but it's much better.


The only thing now is outside-staff-priority doesn't move stuff if 
there's no collision :-) I've told it to put the tune above the tempo, 
but the tempo has been pushed up by an MMR count, and because that's 
left enough space underneath for the tune, it's put it there :-)


Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Anthony Youngman]

On 01/09/17 21:36, David Kastrup wrote:

I find the same thing with databases. So many people have their minds
stuck in the 2-D relational world, and just cannot grasp the concept
of a multi-dimensional database like Pick. Given that Pick is very
much list-based (unlike SQL which is set-based), why can't I grasp a
list-based language like Scheme? And Pick is very XML-like!

Because Scheme (like all LISP variants) does not even have a programming
language.  It has a clever way to write down parse trees as a
computer-readable data structure, bypassing the step of coding in a
programming language.  That makes it brilliant for structure-preserving
program manipulation and AI.


But Scheme *IS* a language. Although I do understand exactly what you 
mean - my very first computer was a Jupiter Ace, which used Forth 
instead of BASIC. So I've been exposed to that sort of thing right from 
the start, but I never really used it much.



Thanks - I'll look up and understand what it does. The only snag is
that I've got 2.18.2, which doesn't like your code. That's the latest
on SuSE, and my gentoo system (which I daren't upgrade at the moment)
is even older - 2.15.12

2.15.12 is stupid: that's an early version in the unstable 2.15 branch.

If your distribution lets you down, you might try installing a binary
from our download page.


Nothing to do with the distro - as I said I daren't upgrade. Firstly, 
gentoo has dropped KDE4 which means major UI changes which will give my 
wife panic attacks (slight exaggeration, but not much). (Plus a big 
learning curve for me.) And secondly my hardware is not quite 
trustworthy - gcc crashes a lot which I think is down to the CPU 
somewhere :-( Dunno why it's only gcc that seems to suffer (remember, 
the distro is gentoo :-)


Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[David Kastrup]

Anthony Youngman  writes:

> On 01/09/17 15:17, Kieren MacMillan wrote:
>> Hi Wol,
>>
>>
>>> While it may sound weird. the reality is you probably didn't find
>>> it too hard to learn Scheme, because you're a composer not a
>>> programmer.
>>
>> Actually, I am a programmer: started with BASIC (and a little
>> assembler language) in the early 1980s, then FORTRAN (including
>> WATFIV) and APL in the late 1980s, then Java in the late 1990s, and
>> a bunch of lesser languages (scripting, etc.) along the way.
>>
>>> Because I'm a procedural (that is. C and Fortran) programmer, it's
>>> a lot harder for me to learn Scheme because it's a completely
>>> different *sort* of language.
>>
>> I agree that it's very difficult for some procedural programmers to
>> learn. I found the same thing when I taught XSL(T), which I find
>> extremely intuitive, but many of my students (and programmer
>> friends) find it impossible to get their mind around.
>
> I find the same thing with databases. So many people have their minds
> stuck in the 2-D relational world, and just cannot grasp the concept
> of a multi-dimensional database like Pick. Given that Pick is very
> much list-based (unlike SQL which is set-based), why can't I grasp a
> list-based language like Scheme? And Pick is very XML-like!

Because Scheme (like all LISP variants) does not even have a programming
language.  It has a clever way to write down parse trees as a
computer-readable data structure, bypassing the step of coding in a
programming language.  That makes it brilliant for structure-preserving
program manipulation and AI.

> Thanks - I'll look up and understand what it does. The only snag is
> that I've got 2.18.2, which doesn't like your code. That's the latest
> on SuSE, and my gentoo system (which I daren't upgrade at the moment)
> is even older - 2.15.12

2.15.12 is stupid: that's an early version in the unstable 2.15 branch.

If your distribution lets you down, you might try installing a binary
from our download page.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Anthony Youngman]

On 01/09/17 15:17, Kieren MacMillan wrote:

Hi Wol,



While it may sound weird. the reality is you probably didn't find it too hard 
to learn Scheme, because you're a composer not a programmer.


Actually, I am a programmer: started with BASIC (and a little assembler 
language) in the early 1980s, then FORTRAN (including WATFIV) and APL in the 
late 1980s, then Java in the late 1990s, and a bunch of lesser languages 
(scripting, etc.) along the way.


Because I'm a procedural (that is. C and Fortran) programmer, it's a lot harder 
for me to learn Scheme because it's a completely different *sort* of language.


I agree that it's very difficult for some procedural programmers to learn. I 
found the same thing when I taught XSL(T), which I find extremely intuitive, 
but many of my students (and programmer friends) find it impossible to get 
their mind around.


I find the same thing with databases. So many people have their minds 
stuck in the 2-D relational world, and just cannot grasp the concept of 
a multi-dimensional database like Pick. Given that Pick is very much 
list-based (unlike SQL which is set-based), why can't I grasp a 
list-based language like Scheme? And Pick is very XML-like!



I want the rehearsal mark sitting above the stave. That's easy (or should be, 
just adjust outside-staff-priority).
Push the music to the right so it doesn't collide with the rehearsal mark


So you literally want a gap under the mark?


Not really. It just feels the easy way to achieve roughly what I'm 
aiming for. As I understand it, the rehearsal mark sits above the bar 
line, while the tempo and melody-name sit above the note? So the easiest 
way (not necessarily the best or neatest) to prevent a collision is to 
push the note sideways out of the way?


The big problem I can see is if sometimes it occurs at the start of a 
line, in which case the rehearsal mark will naturally move left out of 
the way, and letting lily move stuff around may move it to the middle of 
the line where I get a collision. Saying "move this grob a fixed 
distance" is going to completely mess up if this happens. So I need 
something that stops a collision, not something that moves text/marks 
out of the way.



Then use one of the text-alignment functions to place the melody above the tempo


I hope the following helps, or at least points you in the right direction.

Thanks - I'll look up and understand what it does. The only snag is that 
I've got 2.18.2, which doesn't like your code. That's the latest on 
SuSE, and my gentoo system (which I daren't upgrade at the moment) is 
even older - 2.15.12


Cutting and pasting to get a small demo of what lily does by default and 
what I've tried is looking to be a very good idea ... I know the list 
always wants minimal examples and I'm bad at doing it, but I think I'll 
have to. I'll hack at it for a day or so and see where I get ...



Best,
Kieren.


Cheers,
Wol


  SNIPPET BEGINS
\version "2.19.40"

markplusmel =
#(define-music-function
   (marktext melodyname)
   (markup? markup?)
   #{
 \once \override Score.RehearsalMark.break-align-symbols = 
#'(time-signature)
 \once \override Score.RehearsalMark.self-alignment-X = #LEFT
 \mark \markup \override #'(baseline-skip . 2.5) \column { $marktext 
\fontsize #-2 $melodyname }
   #})

testing = {
   \markplusmel "AAA" "All Killer, No Filler"
   \tempo 4=100
   c''1
}

{ \testing }
  SNIPPET ENDS


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info




___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Kieren MacMillan]

Hi Wol,

> Given that I can't even do it ONCE successfully, what makes you think I can 
> write a function to do it automatically?

Fair point.  =)

> While it may sound weird. the reality is you probably didn't find it too hard 
> to learn Scheme, because you're a composer not a programmer.

Actually, I am a programmer: started with BASIC (and a little assembler 
language) in the early 1980s, then FORTRAN (including WATFIV) and APL in the 
late 1980s, then Java in the late 1990s, and a bunch of lesser languages 
(scripting, etc.) along the way.

> Because I'm a procedural (that is. C and Fortran) programmer, it's a lot 
> harder for me to learn Scheme because it's a completely different *sort* of 
> language.

I agree that it's very difficult for some procedural programmers to learn. I 
found the same thing when I taught XSL(T), which I find extremely intuitive, 
but many of my students (and programmer friends) find it impossible to get 
their mind around.

> I want the rehearsal mark sitting above the stave. That's easy (or should be, 
> just adjust outside-staff-priority).
> Push the music to the right so it doesn't collide with the rehearsal mark

So you literally want a gap under the mark?

> Then use one of the text-alignment functions to place the melody above the 
> tempo

I hope the following helps, or at least points you in the right direction.

Best,
Kieren.

  SNIPPET BEGINS
\version "2.19.40"

markplusmel =
#(define-music-function
  (marktext melodyname)
  (markup? markup?)
  #{
\once \override Score.RehearsalMark.break-align-symbols = #'(time-signature)
\once \override Score.RehearsalMark.self-alignment-X = #LEFT
\mark \markup \override #'(baseline-skip . 2.5) \column { $marktext 
\fontsize #-2 $melodyname }
  #})

testing = {
  \markplusmel "AAA" "All Killer, No Filler"
  \tempo 4=100
  c''1
}

{ \testing }
  SNIPPET ENDS


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[David Kastrup]

Anthony Youngman  writes:

> On 19/08/17 15:11, Kieren MacMillan wrote:
>> Hi Wol,
>>
>>> My usual moan about colliding markups :-)
>>
>> Given how usual your moans are…  ;)
>
> Mind you, don't they say moaning customers are the best sort?

Please keep this list safe to read for children.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Anthony Youngman]

On 19/08/17 15:11, Kieren MacMillan wrote:

Hi Wol,


My usual moan about colliding markups :-)


Given how usual your moans are…  ;)


Mind you, don't they say moaning customers are the best sort? They 
*want* the product to succeed.



Can I ask why you don't just write a custom function to deal with the various 
markups automatically?
It really wouldn't be that difficult, and would reduce the moaning to zero (or 
nearly).

Given that I can't even do it ONCE successfully, what makes you think I 
can write a function to do it automatically?


While it may sound weird. the reality is you probably didn't find it too 
hard to learn Scheme, because you're a composer not a programmer. 
Because I'm a procedural (that is. C and Fortran) programmer, it's a lot 
harder for me to learn Scheme because it's a completely different *sort* 
of language.


I really don't fancy trying to write a function that is a superset of 
rehearsal mark, tempo mark, and text markup, all in one ...



As to your precise question:


"what property moves a tempo horizontally?"


The answer is: the same things that move almost any grob horizontally.
X-offset, self-alignment-X, and extra-offset are the main properties to start 
looking at (in that order).

Hope that helps!
Kieren.


I thought it did! EXCEPT. I got self-alignment-X to fix one instance. It 
doesn't work anywhere else! It must be me doing something stupid, but 
why would it work in one instance, and nowhere else? (I'm guessing it's 
working because it's above an MMR, and not working because it's above a 
note.)


And, of course, in successfully moving the tempo (and pushing the melody 
name up above it), because it's at the start of a line and the melody 
name is tied to a null chord, the null chord is placed at the start of 
the line before the clef and time signature! :-(


So what I'm trying to do at the moment is ...
I want the rehearsal mark sitting above the stave. That's easy (or 
should be, just adjust outside-staff-priority).
Push the music to the right so it doesn't collide with the rehearsal 
mark - it looks like \markLengthOn is what I want, except it doesn't 
appear to do anything! :-( That should push the notes, and hence the 
tempo to the right. Unless, of course, it's an MMR ...
Then use one of the text-alignment functions to place the melody above 
the tempo - except trying to understand what the documentation *means* 
is a major exercise (no disrespect to the writers - I'm sure I'm as good 
as they are at writing docu that makes perfect sense to people who 
already understand what it's trying to say :-)


Dunno where to go from here - just tearing my hair out :-) When lily 
works for me it's great - I just don't seem to be able to get to grips 
with anything complicated ... :-(


Cheers,
Wol

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Wols Lists]

On 19/08/17 15:11, Kieren MacMillan wrote:
> Hi Wol,
> 
>> My usual moan about colliding markups :-)
> 
> Given how usual your moans are…  ;)
> Can I ask why you don't just write a custom function to deal with the various 
> markups automatically?
> It really wouldn't be that difficult, and would reduce the moaning to zero 
> (or nearly).

Well, this will probably reduce it a lot too - I'd have the same problem
writing a custom function in that I wouldn't know how to do it :-) If
this works it'll go in my examples file, so when I next want to do it
I'll know how (I did search for it - that's how I found halign - only to
discover that halign doesn't always work).
> 
> As to your precise question:
> 
>> "what property moves a tempo horizontally?"
> 
> The answer is: the same things that move almost any grob horizontally.
> X-offset, self-alignment-X, and extra-offset are the main properties to start 
> looking at (in that order).
> 
> Hope that helps!
> Kieren.

Thanks, I shall have to play. All being well I shall come back with a
"solved, thanks" rather than "I can't get it to work" :-) We shall see.

Thanks again,
Cheers,
Wol


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Kieren MacMillan]

Hi Wol,

> My usual moan about colliding markups :-)

Given how usual your moans are…  ;)
Can I ask why you don't just write a custom function to deal with the various 
markups automatically?
It really wouldn't be that difficult, and would reduce the moaning to zero (or 
nearly).

As to your precise question:

> "what property moves a tempo horizontally?"

The answer is: the same things that move almost any grob horizontally.
X-offset, self-alignment-X, and extra-offset are the main properties to start 
looking at (in that order).

Hope that helps!
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[Pierre Perol-Schneider]

Hi Anthony,

Does that help?

\version "2.19"
\markup\vspace #5
{
  s2.*3 s1*8 \bar "||"
  \tweak outside-staff-priority #0
  \mark \default % 111
  \tempo "Languidly"
  %\once \override TextScript.outside-staff-priority = #2000
  <>^\markup {
%\halign #-1.1
\small "The Last Night Of The World"
  }
  s
}

Cheers,
Pierre

2017-08-19 2:32 GMT+02:00 Anthony Youngman :

> My usual moan about colliding markups :-)
>
> Anyways, I've almost got this bit how I want it ... the following code has
> a rehearsal mark, tempo mark, and melody name all in "the same place".
>
> s2.*3 s1*8 \bar "||" \mark \default % 111
> \tempo "Languidly"
> \once \override TextScript.outside-staff-priority = #2000 <>^\markup
> { \halign #-1.1 \small "The Last Night Of The World" }
>
> The melody name is successfully moved up and to the right such that it no
> longer collides with the rehearsal mark, but the tempo mark still collides.
> The docu for halign says that it doesn't work for some marks (because they
> contain their own alignment code), and it looks like tempo is one of them.
> So how do I move a tempo mark to the right to get rid of the collision?
>
> (Yes I know - there's no "minimal example", but the question basically is
> "what property moves a tempo horizontally?")
>
> Cheers,
> Wol
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Moving a tempo mark to the right

[arnepe]

use the Edition engraver with for e.g.

%% example mock-up %%
\editionMod markmove 1 0/4 my.test.Score.A \once \override
Score.MetronomeMark.extra-offset = #'(2 . 0)

cheers 
Arne



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Moving-a-tempo-mark-to-the-right-tp205173p205174.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user