Re: Stop the resonance of the open hihat in the Midi rendering
On 2020-01-28 1:27 pm, Bric wrote: This might be broadening the scope of the original concern, but as food for thought: One would want to control the timing of the HH closing for *artistic* purposes... the HH closing can make for rhythmic expression (and often does, in live performance) General MIDI is limited in its expressiveness of nearly all instruments, but in particular percussion. The original design was overly simplistic given the variety of drums and cymbals that exist plus the myriad ways to articulate them. That is not to say MIDI drums cannot be useful in their own right; but achieving anything close to a real drummer on a live kit requires careful programming with custom-crafted sound banks which frequently ignore the GM standard's mapping of drum sounds to notes. After all, the synthesizer really does not care whether note 56 actually sounds like a cowbell. If you do not need the sound, use it for something else. I use Reason in my music workflow and have several Refills for drums, many of which substitute the range of supplemental percussion for alternate playing styles of a standard kit. Some of them, for instance, include several degrees of partially open hi-hat. Programming these variations in place of an otherwise fully open hi-hat sound helps to add a more natural sound. That said, however, the automation of the above (in lilypond) may be outside the scope of what the app is intended for (primarily score engraving). Correct me if i'm wrong. It would be a difficult undertaking to support all of the non-standard drum synths and sample banks out there. The principle advantage of the GM standard is that it is a singular, generalized thing to target. I suspect the original intent for MIDI output in LilyPond was to allow users to spot-check their scores, as it may be easier to hear a mistake in engraving that we might not otherwise see during proof-reading. But some folks may be using the MIDI output to generate backing accompaniment or practice tracks. In support of that, the output should be a practical and high-quality rendering of the score. In fact, I would love to see something like articulate.ly that humanizes the performance more so by adding in natural imperfections. Since few performers are machines, it could be beneficial to listen to several "takes" of a complex score to gauge its feasibility. -- Aaron Hill
RE: Error Code
Arron, Thank you for the new methodology. I shall use it in the future. The score is a movement (heavily ornamented) from a Mozart Piano Sonata (K311). It is not much more than 80 measures. The error does seem to come and go, once with the slur notation, once with the beaming notation. It has not appeared in any other of the piano scores that I have coded. Again, many thanks for you care, concern, and thoughtful reponse. Mark -Original Message- From: lilypond-user [mailto:lilypond-user-bounces+carsonmark=ca.rr@gnu.org] On Behalf Of Aaron Hill Sent: Monday, January 27, 2020 9:39 PM To: lilypond-user@gnu.org Subject: Re: Error Code On 2020-01-27 7:07 pm, Mark Stephen Mrotek wrote: > I am still flummoxed by this matter. I have extracted both into small > snippets. In both cases they compile. Yet when I add them to the full > score the one with "(...)" throws the error. > I have removed code to the last known clean complication. Then each > subsequent line was added to confirm compilation. Each time it worked. > It is > only the last line - with the addition of the "(...)" that the error > is thrown. Adding a little in at a time until failure might not be the best way to go about isolating an issue. Think of it like a bridge where you are adding objects one at a time. When the structure finally collapses, you would not normally assign total blame to the last object that was added. Rather it would be the collective weight of all objects that matters. The divide and conquer approach, on the other hand, is often much more useful. Start with a score that fails. Divide the musical content into two halves and compile each individually. If just one half compiles successfully, then you can safely discard that content as not relevant to the issue. For the half that still fails, repeat the same process, further subdividing it. When the two halves both compile successfully on their own, then you know there must be an important interaction between them, so you cannot discard either in its entirety. In that case, put the halves back together and try dividing them in another manner. Sometimes you will have to go line by line, commenting out parts of the score, to determine what matters. This is the opposite of your strategy. We are not slowly adding things until failure, we are slowly removing things until success. Each item that can be removed while still reproducing the failure likely is irrelevant and can be discarded. Ultimately, what you are left with is the minimal working example. How "full" is your full score? There are known limitations with the 32-bit Windows build of LilyPond where the process can run out of memory trying to compile certain scores. This is simply because a 32-bit process can only access up to 2GB* of memory, even when running on a 64-bit operating system with extra physical RAM installed. On Windows, you can use the built-in Task Manager (or better yet Sysinternals' Process Explorer) to monitor the memory usage of a process. (* 32-bit applications that are specifically built as "large address aware" are able to access up to 3.25GB of memory.) If you suspect you might be hitting the memory limit compiling your entire score, try breaking it up into sections and compiling each individually. You should find that each section will compile successfully on its own, then only requiring of you to stitch the results together for the final product. When limited to the 32-bit build of LilyPond, this is the only workaround for large projects. Of course, the 64-bit build of LilyPond likely would be able to compile a large project without manual intervention. On Windows, this could mean running the Linux-64 build of LilyPond either from the Windows Subsystem for Linux (WSL), a Docker container, or a hosted virtual machine running Linux. -- Aaron Hill
Re: Stop the resonance of the open hihat in the Midi rendering
> On January 27, 2020 at 8:45 PM Aaron Hill wrote: > > > On 2020-01-27 12:27 pm, Denis Bitouzé wrote: > > Hello, > > > > the following drum partition has (semi-)opening hihat. In the Midi > > output, the resonance of this hihat is not stopped, even if followed by > > an explicitly closed hihat. > > It is usually expected that synthesizers implement drum note exclusivity > groups, which allow only one of the group to be playing at any given > time. The three standard hi-hat notes (42=closed, 44=pedal, 46=open) > often form one such group. So if the tail of an open hi-hat is not > being cut off by a subsequent closed hi-hat, that may indicate a problem > with the synthesizer itself or whatever patch is loaded. > This might be broadening the scope of the original concern, but as food for thought: One would want to control the timing of the HH closing for *artistic* purposes... the HH closing can make for rhythmic expression (and often does, in live performance) That said, however, the automation of the above (in lilypond) may be outside the scope of what the app is intended for (primarily score engraving). Correct me if i'm wrong.
Re: Draw background lines/grid
On Tue, Jan 28, 2020 at 1:46 AM Kieren MacMillan < kieren_macmil...@sympatico.ca> wrote: > Hi Paolo, > > > is it possible to draw one or more horizontal lines, above/below the > staff, that are completely ignored for collisions with the score's grobs? > > Absolutely: just use \with-dimensions-from \null Thanks! Worked fine, Best, P
Re: beam and partial
Thank you Aaron and Martin.
It's very clear.
Best regards, g.
On Tue, 28 Jan 2020 at 14:25, Aaron Hill wrote:
> On 2020-01-28 4:52 am, Gianmaria Lari wrote:
> > Just a curiosity. Why lilypond engrave this:
> >
> > \version "2.19.83"
> > {\partial 8*7 g8 8 8 8 8 8 8}
> >
> >
> > like
> >
> > g8[ 8 8] 8[ 8 8 8]
> >
> > I would expect:
> >
> > g8[ 8 8 8] 8[ 8 8]
>
> Notes within the anacrusis are adjacent to the end of the measure. To
> beam notes, you would need to consider what the complete measure would
> look like. This could be done by adding in imaginary skips at the
> beginning of the measure.
>
>\partial 8*7 g8 8 8 8 8 8 8
>=> \partial 8*8 s8 g8 8 8 8 8 8 8
>=> \partial 8*8 s8[ g8 8 8] 8[ 8 8 8]
>=> \partial 8*7 g8[ 8 8] 8[ 8 8 8]
>
>
> -- Aaron Hill
>
>
Re: beam and partial
On 2020-01-28 4:52 am, Gianmaria Lari wrote:
Just a curiosity. Why lilypond engrave this:
\version "2.19.83"
{\partial 8*7 g8 8 8 8 8 8 8}
like
g8[ 8 8] 8[ 8 8 8]
I would expect:
g8[ 8 8 8] 8[ 8 8]
Notes within the anacrusis are adjacent to the end of the measure. To
beam notes, you would need to consider what the complete measure would
look like. This could be done by adding in imaginary skips at the
beginning of the measure.
\partial 8*7 g8 8 8 8 8 8 8
=> \partial 8*8 s8 g8 8 8 8 8 8 8
=> \partial 8*8 s8[ g8 8 8] 8[ 8 8 8]
=> \partial 8*7 g8[ 8 8] 8[ 8 8 8]
-- Aaron Hill
beam and partial
Just a curiosity. Why lilypond engrave this:
\version "2.19.83"
{\partial 8*7 g8 8 8 8 8 8 8}
like
g8[ 8 8] 8[ 8 8 8]
I would expect:
g8[ 8 8 8] 8[ 8 8]
Thanks, g.
