Re: Testing requested: new manuscript viewer tool for Frescobaldi
Am 18. Juli 2015 09:11:24 MESZ, schrieb Federico Bruni f...@inventati.org: Il giorno ven 17 lug 2015 alle 16:41, Urs Liska u...@openlilylib.org ha scritto: Before merging it we would like to have a few people test it. If you are running Frescobaldi from its Git repository we'd like to ask you to pull the latest commits and checkout the 'manuscript-viewer' branch. You can then open 'Tools-Display manuscript', click on the help button and start your review from there. Please test the tool, try to crash it and find any inconsistencies in behaviour or interface. Please also see our list of open discussion items at https://github.com/wbsoft/frescobaldi/milestones/Initial%20Manuscript%20Viewer Hi Urs The tool is already great and hope it will be merged soon. I only have a couple of suggestions for future development: Thank you. 1. The session should remember and open the last opened page in the manuscript. Added as https://github.com/wbsoft/frescobaldi/issues/734 2. Any way to collapse/hide the manuscript toolbar to have more space? I had already commented on that inreply to your comment on github. Thanks Federico ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Testing requested: new manuscript viewer tool for Frescobaldi
Hi Urs, thank you for working on that feature. This is something I'm heavily interested in... However, I'm a Windows user with absolutely no knowledge about using github and compiling source code. Is there any chance to get binaries for testing? Cheers, Klaus -- View this message in context: http://lilypond.1069038.n5.nabble.com/Testing-requested-new-manuscript-viewer-tool-for-Frescobaldi-tp178737p178754.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
Re: Testing requested: new manuscript viewer tool for Frescobaldi
Il giorno ven 17 lug 2015 alle 16:41, Urs Liska u...@openlilylib.org ha scritto: Before merging it we would like to have a few people test it. If you are running Frescobaldi from its Git repository we'd like to ask you to pull the latest commits and checkout the 'manuscript-viewer' branch. You can then open 'Tools-Display manuscript', click on the help button and start your review from there. Please test the tool, try to crash it and find any inconsistencies in behaviour or interface. Please also see our list of open discussion items at https://github.com/wbsoft/frescobaldi/milestones/Initial%20Manuscript%20Viewer Hi Urs The tool is already great and hope it will be merged soon. I only have a couple of suggestions for future development: 1. The session should remember and open the last opened page in the manuscript. 2. Any way to collapse/hide the manuscript toolbar to have more space? Thanks Federico ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music function with access to context properties like currentBarNumber?
Am 16.07.2015 um 09:05 schrieb Jan-Peter Voigt:
The problem is, that one has to unfold the music expression during
iteration, so he may need to build a parallel music iterator, that
creates the needed grobs. That sounds misleading.
I don’t understand this completely (never heard of music iterators) but
this does simply mean that it’s hard or impossible to change something
early enough in the compilation process, doesn’t it?
% non-functional example
\version 2.18.2
fun = #(define-music-function (parser location bars)(integer?)
(let ((cbn 0)
(ml (ly:make-moment 4 4))
(rest #{ R1 #}))
#{
\applyContext #(lambda (context)
(set! cbn (ly:context-property context
'currentBarNumber))
(ly:message bar-number: ~A cbn)
(set! ml (ly:context-property context
'measureLength))
(ly:message measure-length: ~A ml)
(ly:music-set-property! rest 'duration ml))
$rest
#}
))
{ \time 3/4 bes'4 a' c''8 b' | \fun 3 | bes'4 a' c''8 b' }
I wrote a very simple engraver today which tries to modify the duration
of rests. It seems to have the same problem: The duration of events can
be changed but it doesn’t shift the following events.
% another non-functional example
\version 2.19.22
#(define Modify_rests_engraver
(make-engraver
(listeners
((rest-event engraver event)
(ly:event-set-property!
event
'duration
(ly:make-duration 3 1 1)) ; 8.*1
(ly:message rest in measure ~A
(ly:context-property
(ly:translator-context engraver)
'currentBarNumber))
\new Voice \with {
\consists #Modify_rests_engraver
} \relative {
r4 g'16
a a a a
b b b b
c c c c |
r2 r16 r
}
If this worked, one could ‘abuse’ fingering numbers for telling the
target bar.
\displayMusic { r-125 }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music function with access to context properties like currentBarNumber?
Malte Meyn lilyp...@maltemeyn.de writes: Am 16.07.2015 um 09:05 schrieb Jan-Peter Voigt: I don’t understand this completely (never heard of music iterators) but this does simply mean that it’s hard or impossible to change something early enough in the compilation process, doesn’t it? [...] I wrote a very simple engraver today which tries to modify the duration of rests. It seems to have the same problem: The duration of events can be changed but it doesn’t shift the following events. Iterators work on music expressions. They are responsible for establishing all of the relative timing. Several iterators will convert music expressions into stream events or produce synthetical stream events. Engravers work on stream events. So engravers work at a layer where messing with the general timing is not an option. While they can change context properties related to timing (like measurePosition, currentBarNumber and similar), they don't change the relative order and sequencing of the general timing. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music function with access to context properties like currentBarNumber?
At 20:20 on 15 Jul 2015, Malte Meyn wrote:
Hello list,
I would like to have somthing like
\version 2.19.22
{
\time 3/4
% bar 1
c'2.
\skipUntil #5 % s2.*4
% bar 5
c'2.
\restUntil #8 % R2.*2
% bar 8
c'2.
}
I use the attached which is from this thread from a couple of years
ago. Thanks to Keith OHara.
https://lists.gnu.org/archive/html/lilypond-user/2013-12/msg01296.html
--
Mark Knoop
alignTo.ily
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music function with access to context properties like currentBarNumber?
Thank you for this explanation. I’ll use Mark’s solution for now but when I have some spare time I’ll come back to this and learn more about music iterators and the compilation process. Am 18.07.2015 um 13:09 schrieb David Kastrup: Malte Meyn lilyp...@maltemeyn.de writes: Am 16.07.2015 um 09:05 schrieb Jan-Peter Voigt: I don’t understand this completely (never heard of music iterators) but this does simply mean that it’s hard or impossible to change something early enough in the compilation process, doesn’t it? [...] I wrote a very simple engraver today which tries to modify the duration of rests. It seems to have the same problem: The duration of events can be changed but it doesn’t shift the following events. Iterators work on music expressions. They are responsible for establishing all of the relative timing. Several iterators will convert music expressions into stream events or produce synthetical stream events. Engravers work on stream events. So engravers work at a layer where messing with the general timing is not an option. While they can change context properties related to timing (like measurePosition, currentBarNumber and similar), they don't change the relative order and sequencing of the general timing. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music function with access to context properties like currentBarNumber?
Thank you for this hint. This doesn’t work with arbitrary bar numbers (‘oboe enters at bar 33’) but with tags at special places (‘oboe enters at second theme’). But that’s perfect for my use case. (I only asked for bar numbers because I thought that this would be easier to implement.) Am 18.07.2015 um 13:27 schrieb Mark Knoop: I use the attached which is from this thread from a couple of years ago. Thanks to Keith OHara. https://lists.gnu.org/archive/html/lilypond-user/2013-12/msg01296.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Extend piano sustain pedal indication to end of bar
Andrew Bernard andrew.bernard at gmail.com writes:
How would one extend the bracket style sustain pedal indication to the end
of a bar or section? I understand from the documentation how to achieve this
for the end of a piece, but can this be done mid-piece?
I might be missing the point, but
\transpose c c' {
\set Staff.pedalSustainStyle = #'bracket
\override Staff.PianoPedalBracket.to-barline = ##t
c4\sustainOn e g b
g1\sustainOff }
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Using force-hshift to create a cross-staff chord
Keith OHara k-ohara5a5a at oco.net writes: Knute Snortum ksnortum at gmail.com writes: I thought the answer would be to force-hshift the lower note but it doesn't seem to move. We should file a bug-report, to at least left-align before applying explicit force-hshifts I submitted a patch to omit the hand-aligned notes from the left-aligning. Another awkward problem is that NoteColumn.force-hshift is ignored when there is only one voice on the staff, because it is only referenced in the code that resolves the meshing or merging of chords. Making force-hshift apply to all NoteColumns is more likely to cause unforeseen problems, so I'm putting that off until a second step. We will get by a little easier after the first step is in the code, using the right force-hshifts on the staff with multiple voices ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Using force-hshift to create a cross-staff chord
I have a situation where I'm creating cross-staff chords. All is well
until the melody note is the same as the top chord note. LilyPond
(correctly) shifts the chord to the right, but now the note in the lower
staff doesn't create a cross-staff chord. I thought the answer would be to
force-hshift the lower note but it doesn't seem to move.
In the example below, the problem is in beat 2 of the first measure. I've
tried force-hshifting the other notes but I haven't been able to get it
working.
\version 2.19.23
\language english
\score {
\new PianoStaff
\new Staff {
\clef treble
\new Voice {
\voiceOne
\relative {
g'4 f4 ~ f2 ~ |
f1 |
}
}
\new Voice {
\voiceTwo
\relative {
\crossStaff {
s4 c' f2 q4 |
s4 c f2 q4 |
}
}
}
}
\new Staff {
\clef bass
\new Voice {
\voiceTwo
\relative {
\crossStaff {
a4\rest \once \override NoteColumn.force-hshift = 1 a2 a4 |
a4\rest a2 a4 |
}
}
}
\new Voice {
\voiceFour
\relative {
f,1 |
f1 |
}
}
}
\layout {
\context {
\PianoStaff
\consists #Span_stem_engraver
}
}
}
Knute Snortum
(via Gmail)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Using force-hshift to create a cross-staff chord
Knute Snortum ksnortum at gmail.com writes:
I thought the answer would be to force-hshift the lower note but it
doesn't seem to move.
Annoyingly, LilyPond left-aligns the groups of clashing chords between
different staves. The code history says the reason was to left-align
\transpose c c''
\new Staff { f4 g } \\ { g f }
\new Staff { c4 c }
This makes force-hshift often useless for making cross-staff chords.
We should file a bug-report, to at least left-align before applying
explicit force-hshifts
For now, you could use a hidden voice
...
a2 \new Voice{\voiceOne \once \hideNotes a4 } a4
...
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Extend piano sustain pedal indication to end of bar
How would one extend the bracket style sustain pedal indication to the end of a bar or section? I understand from the documentation how to achieve this for the end of a piece, but can this be done mid-piece? Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
