Re: duration and pitch in a function
Paolo Prete writes: > I need to create a function that > > accepts some_pitch and some_duration as arguments and prints the > following three notes: > > 1) some_pitch with some_duration > 2) some_pitch with some_duration*2 > 3) some_pitch with some_duration*3 > > > Should I use ly:duration as type of the argument two? ly:duration? would be the predicate. And yes, definitely. > I can't find documentation for that. > > I use LilyPond 2.12.3 but I can upgrade it if necessary... If you upgrade, you will find both the functionality itself as well as the documentation. I don't quite remember the version; it might be necessary to take one of the 2.15.x releases. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: duration and pitch in a function
I searched in "extending" manual for 2.15, but I did not find a solution for my
problem.
Shortly, given this fragment of code:
myFunction = #(define-music-function (parser location foobar) (ly:duration?)
#{
a ...how_can_I_use_$foobar_as_duration_??...
#})
\new Staff \myFunction ...how_can_I_pass_duration_??...
-
...which is the right syntax and which version of lilypond could I use?
Thanks
--- Gio 8/12/11, David Kastrup ha scritto:
> Da: David Kastrup
> Oggetto: Re: duration and pitch in a function
> A: lilypond-user@gnu.org
> Data: Giovedì 8 dicembre 2011, 07:59
> Paolo Prete
> writes:
>
> > I need to create a function that
> >
> > accepts some_pitch and some_duration as arguments and
> prints the
> > following three notes:
> >
> > 1) some_pitch with some_duration
> > 2) some_pitch with some_duration*2
> > 3) some_pitch with some_duration*3
> >
> >
> > Should I use ly:duration as type of the argument two?
>
> ly:duration? would be the predicate. And yes,
> definitely.
>
> > I can't find documentation for that.
> >
> > I use LilyPond 2.12.3 but I can upgrade it if
> necessary...
>
> If you upgrade, you will find both the functionality itself
> as well as
> the documentation.
>
> I don't quite remember the version; it might be necessary
> to take one of
> the 2.15.x releases.
>
> --
> David Kastrup
>
>
> ___
> 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: duration and pitch in a function
Paolo Prete writes:
> I searched in "extending" manual for 2.15, but I did not find a
> solution for my problem.
Please, *never*, *never*, *never* send a "courtesy copy" of a public
answer as a private mail when answering on a mailing list unless you
have been _explicitly_ asked to provide such a copy.
Otherwise, you set up _two_ different communication channels that the
person you are showing your "courtesy" then has to answer separately.
It is a great nuisance and additional work and hassle.
Paolo Prete writes:
> I searched in "extending" manual for 2.15, but I did not find a
> solution for my problem.
>
> Shortly, given this fragment of code:
>
>
>
>
> myFunction = #(define-music-function (parser location foobar) (ly:duration?)
> #{
>a ...how_can_I_use_$foobar_as_duration_??...
> #})
>
> \new Staff \myFunction ...how_can_I_pass_duration_??...
>
>
> -
>
>
> ...which is the right syntax and which version of lilypond could I use?
That _is_ the right syntax. $foobar is a duration in #{ ... #}, and you
pass it by writing it down, as 2 or 2.. or 2.*3/2 or any other way of
writing a duration.
The first version where this would have been possible, judging from the
commit logs, would have been 2.15.6. But there is little point in not
getting the current 2.15.x release instead.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: duration and pitch in a function
On 8/12/2011, at 10:48 pm, David Kastrup wrote: > Please, *never*, *never*, *never* send a "courtesy copy" of a public > answer as a private mail when answering on a mailing list unless you > have been _explicitly_ asked to provide such a copy. > > Otherwise, you set up _two_ different communication channels that the > person you are showing your "courtesy" then has to answer separately. > It is a great nuisance and additional work and hassle. Normally I'd agree with you, but in fairness to Paolo I observe that this is the only mailing list I am or ever have been a member of in which the default behaviour is to reply to the sender (only) rather than to the list. I have in consequence more than once unintentionally sent a separate "courtesy copy" message. Best wishes, Matthew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: duration and pitch in a function
Matthew Collett writes: > On 8/12/2011, at 10:48 pm, David Kastrup wrote: > >> Please, *never*, *never*, *never* send a "courtesy copy" of a public >> answer as a private mail when answering on a mailing list unless you >> have been _explicitly_ asked to provide such a copy. >> >> Otherwise, you set up _two_ different communication channels that the >> person you are showing your "courtesy" then has to answer separately. >> It is a great nuisance and additional work and hassle. > > Normally I'd agree with you, but in fairness to Paolo I observe that > this is the only mailing list I am or ever have been a member of in > which the default behaviour is to reply to the sender (only) rather > than to the list. I have in consequence more than once > unintentionally sent a separate "courtesy copy" message. You arae confusing a _separate_ "courtesy copy", namely one for which the _only_ recipient in the headers is the person you are replying to, with _including_ the intended recipient in the list of recipients of the _same_ mail. The latter does _not_ set up a separate communication channel. In fact, since the mailing list server can then _see_ that the recipient is already going to get a separate copy, it does not even bother sending out a copy of its own (unless the recipient unticked the standard "nocopy" option in his personal settings). Including the person in the list of headers you are replying to is normal (unless you are sending the "main" article through a news server like gmane instead of the mailing list server directly). Sending a _separate_ copy without any indication that it _is_ a separate copy (so that either the recipient or the mailing list server can recognize the duplication) isn't. Those _separate_ mails are what is cynically called "courtesy copy" since they, as a rule, cause confusion and irritation, making the same content travel twice, with different reply-to headers, and without an indication of the duplication. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: duration and pitch in a function
On 9/12/2011, at 2:27 pm, David Kastrup wrote: >> On 8/12/2011, at 10:48 pm, David Kastrup wrote: >> >>> Please, *never*, *never*, *never* send a "courtesy copy" of a public >>> answer as a private mail when answering on a mailing list unless you >>> have been _explicitly_ asked to provide such a copy. >> >> Normally I'd agree with you, but in fairness to Paolo I observe that >> this is the only mailing list I am or ever have been a member of in >> which the default behaviour is to reply to the sender (only) rather >> than to the list. I have in consequence more than once >> unintentionally sent a separate "courtesy copy" message. > > You arae confusing a _separate_ "courtesy copy", namely one for which > the _only_ recipient in the headers is the person you are replying to, > with _including_ the intended recipient in the list of recipients of the > _same_ mail. No, I am not: a separate message is what I said, and what I meant. Because the list reply defaults to the sender _only_, unless I remember explicitly to choose "Reply All" (which I otherwise rarely use) any message I mean to send to the list goes instead to just the individual. I then have to send a separate copy to the list (only), making my first reply retrospectively and unintentionally a "courtesy copy". The last occasion that happened was just yesterday. And as I said, I do not have this problem with any other mailing list. Best wishes, Matthew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: duration and pitch in a function
2011/12/9 Matthew Collett : > > On 9/12/2011, at 2:27 pm, David Kastrup wrote: > >>> On 8/12/2011, at 10:48 pm, David Kastrup wrote: >>> Please, *never*, *never*, *never* send a "courtesy copy" of a public answer as a private mail when answering on a mailing list unless you have been _explicitly_ asked to provide such a copy. >>> >>> Normally I'd agree with you, but in fairness to Paolo I observe that >>> this is the only mailing list I am or ever have been a member of in >>> which the default behaviour is to reply to the sender (only) rather >>> than to the list. I have in consequence more than once >>> unintentionally sent a separate "courtesy copy" message. >> >> You arae confusing a _separate_ "courtesy copy", namely one for which >> the _only_ recipient in the headers is the person you are replying to, >> with _including_ the intended recipient in the list of recipients of the >> _same_ mail. > > No, I am not: a separate message is what I said, and what I meant. Because > the list reply defaults to the sender _only_, unless I remember explicitly to > choose "Reply All" (which I otherwise rarely use) any message I mean to send > to the list goes instead to just the individual. I then have to send a > separate copy to the list (only), making my first reply retrospectively and > unintentionally a "courtesy copy". The last occasion that happened was just > yesterday. And as I said, I do not have this problem with any other mailing > list. +1 .. Sorry Matt, I did it again... Jakob. > > Best wishes, > Matthew > > > > ___ > 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: duration and pitch in a function
Hi Paolo,
this compiles in 2.14.2 on my machine:
--snip--
\version "2.14.2"
myFunction = #(define-music-function (parser location foobar) (ly:duration?)
(make-music 'SequentialMusic 'elements (list
(make-music 'EventChord 'elements (list
(make-music 'NoteEvent 'duration foobar 'pitch (ly:make-pitch 1 0 0))
))
))
)
{
\myFunction #(ly:make-duration 2 0 1 1) r4
}
--snip--
In your first message you wrote something about one note, that is repeated 3
times, while augmenting its length - if I did understand your question right.
I recommend the us of \displayMusic, to see, how notes are constructed in
scheme. Then you might have one argument (... foobar) (ly:music?), a function
that copies this note and changes its duration accordingly.
HTH
cheers, Jan-Peter
Am 08.12.2011 um 10:36 schrieb Paolo Prete:
> I searched in "extending" manual for 2.15, but I did not find a solution for
> my problem.
>
> Shortly, given this fragment of code:
>
>
>
>
> myFunction = #(define-music-function (parser location foobar) (ly:duration?)
> #{
> a ...how_can_I_use_$foobar_as_duration_??...
> #})
>
> \new Staff \myFunction ...how_can_I_pass_duration_??...
>
>
> -
>
>
> ...which is the right syntax and which version of lilypond could I use?
>
>
> Thanks
>
>
>
>
> --- Gio 8/12/11, David Kastrup ha scritto:
>
>> Da: David Kastrup
>> Oggetto: Re: duration and pitch in a function
>> A: lilypond-user@gnu.org
>> Data: Giovedì 8 dicembre 2011, 07:59
>> Paolo Prete
>> writes:
>>
>>> I need to create a function that
>>>
>>> accepts some_pitch and some_duration as arguments and
>> prints the
>>> following three notes:
>>>
>>> 1) some_pitch with some_duration
>>> 2) some_pitch with some_duration*2
>>> 3) some_pitch with some_duration*3
>>>
>>>
>>> Should I use ly:duration as type of the argument two?
>>
>> ly:duration? would be the predicate. And yes,
>> definitely.
>>
>>> I can't find documentation for that.
>>>
>>> I use LilyPond 2.12.3 but I can upgrade it if
>> necessary...
>>
>> If you upgrade, you will find both the functionality itself
>> as well as
>> the documentation.
>>
>> I don't quite remember the version; it might be necessary
>> to take one of
>> the 2.15.x releases.
>>
>> --
>> David Kastrup
>>
>>
>> ___
>> 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
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: duration and pitch in a function
Jan-Peter Voigt writes:
> Hi Paolo,
>
> this compiles in 2.14.2 on my machine:
> --snip--
> \version "2.14.2"
>
> myFunction = #(define-music-function (parser location foobar) (ly:duration?)
> (make-music 'SequentialMusic 'elements (list
> (make-music 'EventChord 'elements (list
> (make-music 'NoteEvent 'duration foobar 'pitch (ly:make-pitch 1 0 0))
> ))
> ))
> )
>
> {
> \myFunction #(ly:make-duration 2 0 1 1) r4
> }
Yes, it would. Unfortunately, it would not compile with the current
version since the current version does not allow duration arguments to
be specified in anything but duration syntax (along with pitches, they
are one of two currently remaining special-cased argument types).
I really don't think that it is worth investing work into creating 2.14
sources if you want to have music functions meddling with durations and
other stuff in easily maintainable ways.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: duration and pitch in a function
Thanks for that hint! I will keep that in mind for future development.
I actually use 2.14 for my allday work and create my extensions according to
that syntax, because I want to be able to produce sheets day by day without
stumbling over suprisingly upcoming changes.
I know, I should have a devel (2.15 ... 2.17 ...) on my machine to be prepared
for the next release.
Paolo's excercise would be solved differently by me: I would use a ly:music?
argument and copy and augment that. And I hope, ly:music? arguments will not be
broken in future releases ;-)
Cheers,
Jan-Peter
Am 11.12.2011 um 09:45 schrieb David Kastrup:
> Jan-Peter Voigt writes:
>
>> Hi Paolo,
>>
>> this compiles in 2.14.2 on my machine:
>> --snip--
>> \version "2.14.2"
>>
>> myFunction = #(define-music-function (parser location foobar) (ly:duration?)
>> (make-music 'SequentialMusic 'elements (list
>>(make-music 'EventChord 'elements (list
>> (make-music 'NoteEvent 'duration foobar 'pitch (ly:make-pitch 1 0 0))
>>))
>> ))
>> )
>>
>> {
>> \myFunction #(ly:make-duration 2 0 1 1) r4
>> }
>
> Yes, it would. Unfortunately, it would not compile with the current
> version since the current version does not allow duration arguments to
> be specified in anything but duration syntax (along with pitches, they
> are one of two currently remaining special-cased argument types).
>
> I really don't think that it is worth investing work into creating 2.14
> sources if you want to have music functions meddling with durations and
> other stuff in easily maintainable ways.
>
> --
> David Kastrup
>
>
> ___
> 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: duration and pitch in a function
Jan-Peter Voigt writes: > Thanks for that hint! I will keep that in mind for future development. > I actually use 2.14 for my allday work and create my extensions > according to that syntax, because I want to be able to produce sheets > day by day without stumbling over suprisingly upcoming changes. > I know, I should have a devel (2.15 ... 2.17 ...) on my machine to be > prepared for the next release. > Paolo's excercise would be solved differently by me: I would use a > ly:music? argument and copy and augment that. And I hope, ly:music? > arguments will not be broken in future releases ;-) They will. My preferred newspeak for that is "they will be unbroken", namely become much more consistent and versatile. But that means that there _will_ be changes in semantics for cases that are quite cumbersome to do currently. I manage to get my syntax changes through with very little collateral damage, and convert-ly covers by far the largest portion of it. I don't do disruptive changes without good reason, and not without convert-ly rules where applicable, and as a rule, none of them gets backed out again once it is in. So there are no "surprisingly upcoming changes" that you can avoid in the long run by sticking with 2.14, and there is very little backpedaling in development. There has been quite a bit of heat spent on the developer lists to arrive at semi-automatic procedures that make reasonably sure that the current development master is kept in working state. I can take credit for that only so far as those procedures were partly created to withstand the strain from my flow of patches (and particularly the strain from my accompanying abuse when it got disrupted). But the results naturally made it easier for everyone to contribute exciting and numerous improvements while minimizing disturbances on the development versions' quality. Personally I would not "create my extensions according to 2.14 syntax" because that is so awkward. If you do git diff release/2.14.2-1..origin lily/lily-lexer.cc you'll notice that \grobdescriptions, \key, \mark, \once, \partial, \relative, \skip, \time, \times, \transpose all have disappeared from the lexer. All of those are now music functions instead of being hardwired in the syntax. And that means that your own personal extensions could also provide comparable functionality with comparable syntax. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: duration and pitch in a function
Hello David, thank you for this detailed answer! Well, I don't agree in doing an awkward thing, using 2.14. But I probably should not name shortcuts extensions. When I am working on a collection of pieces to be printed, I am using current *stable* version. While I'm working on them, I sometimes have to repeat a special override or markup. So I create a little music-function or markup-command to save typing. And sometimes those little shortcuts grow to be an extension I use day by day. I still use the current *stable* version - if there is a wrong note, I still want to be able to correct that and compile the file three months later without lilypond-version-issues. But you are absolutely right, saying that creating or developing new features should be done in a development environment. And the changes you named are again great improvements of the sharp knife lilypond! I just downloaded 2.15.21, to see what happens with my work and what needs to be done for that. ... There are a couple of things to be done manually. This is not a problem, but I prefer doing that once for a stable release on all my important files. And I still want to use my recent shortcuts/macros/whatever-you-call-them. But I am going to take care of this version question, when I am answering on the list. Your hint with the ly:duration?-argument is important. @Paolo: you should use current devel-version and look at the docs for that. There are a lot improvements in creating music-functions for your purpose. I sometimes did a user-devel-mashup ... I shouldn't disturb development with issues of the stable version. Sorry for that, list-members! Cheers, Jan-Peter Am 11.12.2011 11:38, schrieb David Kastrup: Jan-Peter Voigt writes: Thanks for that hint! I will keep that in mind for future development. I actually use 2.14 for my allday work and create my extensions according to that syntax, because I want to be able to produce sheets day by day without stumbling over suprisingly upcoming changes. I know, I should have a devel (2.15 ... 2.17 ...) on my machine to be prepared for the next release. Paolo's excercise would be solved differently by me: I would use a ly:music? argument and copy and augment that. And I hope, ly:music? arguments will not be broken in future releases ;-) They will. My preferred newspeak for that is "they will be unbroken", namely become much more consistent and versatile. But that means that there _will_ be changes in semantics for cases that are quite cumbersome to do currently. I manage to get my syntax changes through with very little collateral damage, and convert-ly covers by far the largest portion of it. I don't do disruptive changes without good reason, and not without convert-ly rules where applicable, and as a rule, none of them gets backed out again once it is in. So there are no "surprisingly upcoming changes" that you can avoid in the long run by sticking with 2.14, and there is very little backpedaling in development. There has been quite a bit of heat spent on the developer lists to arrive at semi-automatic procedures that make reasonably sure that the current development master is kept in working state. I can take credit for that only so far as those procedures were partly created to withstand the strain from my flow of patches (and particularly the strain from my accompanying abuse when it got disrupted). But the results naturally made it easier for everyone to contribute exciting and numerous improvements while minimizing disturbances on the development versions' quality. Personally I would not "create my extensions according to 2.14 syntax" because that is so awkward. If you do git diff release/2.14.2-1..origin lily/lily-lexer.cc you'll notice that \grobdescriptions, \key, \mark, \once, \partial, \relative, \skip, \time, \times, \transpose all have disappeared from the lexer. All of those are now music functions instead of being hardwired in the syntax. And that means that your own personal extensions could also provide comparable functionality with comparable syntax. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: duration and pitch in a function
Jan-Peter Voigt writes: > Hello David, > thank you for this detailed answer! > Well, I don't agree in doing an awkward thing, using 2.14. Duration arguments in Lilypond 2.14 are awkward without you being at fault. There is a reason even a very simple command like \skip had to be implemented in the parser in 2.14 rather than as a straightforward music function. > But I probably should not name shortcuts extensions. There is no sharp line between them. > But you are absolutely right, saying that creating or developing new > features should be done in a development environment. And the changes > you named are again great improvements of the sharp knife lilypond! I > just downloaded 2.15.21, to see what happens with my work and what > needs to be done for that. Basically, not much more than final tweaks (the kind of thing you need to redo across the affected pages when adding a single forgotten measure) should be affected once you run convert-ly. > I sometimes did a user-devel-mashup ... I shouldn't disturb > development with issues of the stable version. Sorry for that, > list-members! This is the user list, so it is not like you are being off-topic. But my current work is focused on usability and the programming and extension facilities of Lilypond, and thus the "I will update from 2.12 when Ubuntu does" stance means that there is a time lag of several years between the time I fix a shortcoming to the time users actually start looking at it. That time span is far too long for any kind of useful feedback. Including bug reports, donations and work for hire. If the feedback loop is longer than that for interstellar travel, there is no way that development can be user-driven. So "getting the message out" is important to me. I am also currently in discussions for getting the dormant Lilypond Report revived soonish. It would be a pity if the reason for excitement has long ceased existing by the time the excitement arrives at its target, the user base. All the best -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
