Re: Removing 2sd intervals
On Tue, Apr 25, 2017 at 5:21 PM nycgdf <nyc...@gmail.com> wrote:
> Hi everyone,
>
> I would like to write a function (potentially a music-function) that does
> the following task:
> For every set of notes that are played in the same time, if they are
> separated by less than 3 semitones, modal transpose the lower note at a
> given scale to one step lower.
>
> Input:
> musica = { a4 b4 c'4 d'4 }
> musicb = { d'4 c'4 b4 a4 }
>
> both = {
> <<
> \musica
> \musicb
> >>
> }
>
> output:
> <<
> { a4 a4 c'4 d'4 }
> { d'4 c'4 a4 a4 }
> >>
>
> I struggle to find a way to iterate on the note of a music:
> Ideally, I am looking for a 'for-each' function that I could call on 'both'
> that would iterate on the list:
> (list #{ << a4 d'4 >> << b4 c'4 >> << c'4 b4 >> << d'4 a4 >> #})
>
> and then I would use ly:pitch-semitones to calculate the difference and do
> the transpose.
>
> Thank you for your help
Can't you `for-each` this? Or `do` it?
> --
Jeffery Shivers
jefferyshivers.com
soundcloud.com/jefferyshivers
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond Slack channel
On Fri, Apr 21, 2017 at 10:24 PM Jeffery Shivers <jefferyshiv...@gmail.com> wrote: > > So I'd like to know general thoughts about the use of such a system in > the first place, for GSoC, but also if people might see a use for it > outside of the scope of LilyPond. Oops - I mean *outside of the scope of GSoC*. > -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyPond Slack channel
Hi everyone, I thought it might be useful to create a Slack channel for LilyPond, particularly with the advent of another Google Summer of Code term. Most GSoC orgs encourage some sort of IRC or other chat protocol for students / mentors / admins to interact, but of course the downside is that these aren't usually public spaces. However, this paradigm for faster (and probably more casual) communication could be a good way of maintaining students' enthusiasm, productivity, and general *bonding* with each other and the more interested community members. GSoC students shouldn't ever use the channel to ask questions that should be answered by the general community, but it might be the place to ask quick questions that really don't need a whole email dedicated to them. Also, people can arrange times to meet and chat this way, similar to Skype or whatever. So I'd like to know general thoughts about the use of such a system in the first place, for GSoC, but also if people might see a use for it outside of the scope of LilyPond. Other than the tradeoff between (potential) pace/efficiency and permanence/archivability, the only other tricky part of Slack is the way that new members are invited to the channel. Admins for a channel can individually invite anyone, and can also allow anyone whose email belongs to a certain domain (such as *@gnu.org) to find and request to join the channel. But the upside to that is that it is easy to curate membership and to even have private threads (created by admins) within the channel. If you want to have a look and try it out, I'd be happy to invite individuals. Please just let me know - it takes two seconds to send the invitation, and I am hopeful that this is something others are interested in. The Slack channel is: https://lilypond.slack.com/ Looking forward to your thoughts. Best, Jeffery -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google SoC
Hi Charles, On Thu, Mar 30, 2017 at 10:33 AM, Winston, Charles R. <charles.wins...@tufts.edu> wrote: > The list has given me some sad trouble. I am still unable to register. I am > certain that I am not making a mistake in typing in my email because I have > submitted the request multiple times and have been taking to a web page that > reads this message: > > [trimmed] > > I have checked spam folders and still have received no email. I have also > tried this with multiple emails, again with no luck. Jeffery told me the > server dealing with this was down. Is this still the case? Is there some > other way to be added to the list manually? Any help would be greatly > appreciated. Good news! It looks like you are successfully posting to the list now. I see your two most recent posts (the quoted one included) on the public archives, so whatever happened right before then worked. No servers/services were down (I speculated it could have been, but asked and found that this was not the case), so all points to a probably over-protective spam/quarentine situation with the university email you are using. -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Google SoC
On Wed, Mar 29, 2017 at 9:31 PM, Carl Sorensen <c_soren...@byu.edu> wrote: > > On 3/29/17 6:31 PM, "Winston, Charles R." <charles.wins...@tufts.edu> > wrote: >> >>I also understand there is a period of "community bonding" for the GSoC. >>I'd love to hear about that in more detail. > > After students are selected and before coding begins (from May 4 to May > 30), students work to lay the foundation for their success. This means > they are involved in the development community, perhaps submitting bug > fixes or documentation suggestions, reviewing code, and otherwise > participating in the community. But you don't need to wait until May 4 to > start bonding with the LilyPond communityŠ The GSoC website itself also has the comprehensive descriptions of things in the timeline, rules, and other sections: https://summerofcode.withgoogle.com/how-it-works/#timeline If you scroll to the bottom/footer, you'll find those and other helpful links. Also, the last section at: http://lilypond.org/website/google-summer-of-code.html -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: Google SoC
Hi everyone, Please see the forwarded message below. This student (Charles, also CC'd) is interested in participating in GSoC with LilyPond and has been trying for a while to subscribe to the list to post this with no luck so please excuse the lateness. I guess he can't reply back to lilypond-devel still, but can to individuals - so, others, please keep that in mind if it looks like he's not responding. :-) -- Forwarded message -- From: Winston, Charles R. <charles.wins...@tufts.edu> Date: Mon, Mar 27, 2017 at 8:20 PM Subject: Re: Google SoC To: "jefferyshiv...@gmail.com" <jefferyshiv...@gmail.com> Hi LilyPond Team, I recently received information about LilyPond and the Summer of Code from Jeffery Shivers, who participated with LilyPond in the past, and I am extremely interested in applying. I'm a sophomore CS major at Tufts University, where I am also minoring in Music Engineering and Mathematics. I am a passionate musician and programmer, and while I haven't had experience using LilyPond itself, I have a lot of experience using similar softwares—I use Sibelius frequently to arrange acapella music, and I use LaTeX very often for math homework, math research papers, and other miscellaneous documents; since LilyPond is a LaTeX-like music engraving program, I wouldn't have trouble picking it up! I am very excited by this opportunity and wanted to contact you guys and get in touch! The LilyPond community seems great and I really want to be a part of it. The projects I am most interested in pursuing are improving the internal representation of LilyPond chords and improving the MusicXML importing and exporting functions, but I would be happy pursuing any of them. I'd love to hear more about these projects and about LilyPond in general. I'm looking forward to hearing back from you guys! Thanks, Charles Winston ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't post via gmane, and trouble subscribing
Hi James, On Sun, Mar 26, 2017 at 6:07 AM, James <p...@gnu.org> wrote: > Well as far as I am aware gmane is still under going 'new ownership' > and looking at the http://home.gmane.org/ blog from the new owners, > there hasn't been anything significant announced/updated for a few > months, so it is possible that this is all still work-in-progress with > regard to gmane. > > There has been some discussion about removing the gmane references from > our website but because it is/was still all in flux I think some of us > were hoping it would come back soon so that we didn't need to remove > and then have to add back the gmane links. Okay, thanks for the clarification. I must admit, I'm not totally sure how the whole gmane/mailing list framework(s) work since I personally just subscribed originally and from then on have used the gmail web interface for all interactions/posting. (I did read gmane.org/about after writing that, so it's a little less fuzzy now..) >> Possibly related: >> A student at my uni has tried to subscribe to the lilypond-devel list >> but hasn't gotten a confirmation request. Just an email that one is on >> the way: >> [...] > > I am sure he / she will get something soon, but has that student tried > to actually log in since without waiting for the confirmation? Can you point me to where he can do that? The only link I've found is the one that doesn't work. He has tried to post to lilypond-devel from his subscribed email address with no success, but I am unsure how/where to otherwise log in to gmane. Thanks for the help so far, Jeffery -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Can't post via gmane, and trouble subscribing
Hi, Is the gmane server actually down, or is it just me? This link: http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.devel ... provided here: https://lists.gnu.org/mailman/listinfo/lilypond-devel ... says the "site cannot be reached". Also, same for simply gmane.org. Possibly related: A student at my uni has tried to subscribe to the lilypond-devel list but hasn't gotten a confirmation request. Just an email that one is on the way: "Your subscription request has been received, and will soon be acted upon. Depending on the configuration of this mailing list, your subscription request may have to be first confirmed by you via email, or approved by the list moderator. If confirmation is required, you will soon get a confirmation email which contains further instructions." ... with no actual follow-up. Thanks, Jeffery -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contemporary notation (Re: GSoC projects list)
Sorry, I responded to David before reading your response, but I see that we kind of said the same things. > Indeed this should be discussed thoroughly before actually investing > substantial energy in implementation. But for now I'd defer this to a moment > if there should be a student interested in the project. This discussion would > be a very interesting topic for getting familiar with the student, and a good > exercise for the "bonding period". Yes, certainly. And if the project isn't initiated this year, we always have the option of proceeding with discussions / work anyway. This is a project I'd for sure like to see happen. I've recently just had to switch to making my scores entirely in java since it is such a headache to create/edit multi-page projects in inkscape and things are still a stretch with lilypond oftentimes. On Mon, Feb 6, 2017 at 10:51 AM, Jeffery Shivers <jefferyshiv...@gmail.com> wrote: >> Man, that sounds to me like making explosives available to as many users >> as possible. I mean, I recognize that there is a need apparently to be >> served, but this rather sounds like a call to expanding that need. > > Hm, no. There is an absurd amount of weird *needs* from composers > nowadays who aren't working with (any semblance of) conventional > western notation or even whatever people other than them (the > individual) might think "contemporary notation" is. My point: what is > useful to most / in general is what should be prioritized (surely you > would agree...), and since "contemporary notation" is really a vast > abyss of possibilities (composers are inventing unique, radical > notations for use in only single projects), there is no point in > trying to create a starting point as defined as, say, LilyPond itself. > > LilyPond is based on a relatively narrow, rigid perspective of how > music works and is (ahem, "should be") notated; this is completely > valid and works in its/our favor because *most people agree on that as > a starting point*. A contemporary notation library, however, should > not be so specific right out of the gate. The library needs to be > designed *to be extended* out of the box, with the implication that > people build their own specific tools using the more versatile tools > the library provides, and of course those *specific tools* can be > contributed though a kind of package manager if one ever exists, or > whatever other means. We may find that there are certain specific > things that we didn't expect most people to need but they, in fact, do > and thus we add those things to the core contemporary notation > library, but it's just silly and ignorant to assume those things until > we get there. > > But what do I know - I'm only a contemporary composer. :-) > > On Mon, Feb 6, 2017 at 10:03 AM, Urs Liska <u...@openlilylib.org> wrote: >> >> >> Am 06.02.2017 um 15:10 schrieb Jeffery Shivers: >> >> I've thought about this a lot, and I agree that OLL would be the >> obvious means to implement a *contemporary notation* package with >> LilyPond. >> >> A huge problem we will face with doing this, which will always be a >> problem no matter how accessible/robust the library, is that there >> will very often be some unexpected (and probably illogical) way that a >> composer wants to notate their music. So if our software doesn't >> support what they want, or they have to really *stretch* it to >> accomplish their needs, it makes sense for them to turn to something >> like inkscape for faster and more straightforward results, even though >> that process won't carry all the benefits/flexibility of engraving >> with a tool like LilyPond (for example, increasing the horizontal >> spacing between everything in a multi-page score on a big ole inkscape >> document is a much bigger deal than it is in LilyPond). >> >> This is all to say, "contemporary notation" encapsulates so many >> possibilities, it'll be a tricky and probably exhausting process to >> figure out the best way to make its use available to as many users as >> possible. Not saying that to be discouraging, just realistic. >> >> >> Your considerations are reasonable, but I wouldn't see it that much as a >> problem. It's not that we need to create a tool that is as comprehensive as, >> say, LilyPond itself with regard to common notation. What I think would be >> useful (and sufficient in the currently discussed context) is a >> tool/package/infrastructure that >> >> proves that non-standard notation can be made availalbe through convenient >> and flexible (parametrical) commands, >> provides tools to make it easy to build upon,
Re: Contemporary notation (Re: GSoC projects list)
> Man, that sounds to me like making explosives available to as many users > as possible. I mean, I recognize that there is a need apparently to be > served, but this rather sounds like a call to expanding that need. Hm, no. There is an absurd amount of weird *needs* from composers nowadays who aren't working with (any semblance of) conventional western notation or even whatever people other than them (the individual) might think "contemporary notation" is. My point: what is useful to most / in general is what should be prioritized (surely you would agree...), and since "contemporary notation" is really a vast abyss of possibilities (composers are inventing unique, radical notations for use in only single projects), there is no point in trying to create a starting point as defined as, say, LilyPond itself. LilyPond is based on a relatively narrow, rigid perspective of how music works and is (ahem, "should be") notated; this is completely valid and works in its/our favor because *most people agree on that as a starting point*. A contemporary notation library, however, should not be so specific right out of the gate. The library needs to be designed *to be extended* out of the box, with the implication that people build their own specific tools using the more versatile tools the library provides, and of course those *specific tools* can be contributed though a kind of package manager if one ever exists, or whatever other means. We may find that there are certain specific things that we didn't expect most people to need but they, in fact, do and thus we add those things to the core contemporary notation library, but it's just silly and ignorant to assume those things until we get there. But what do I know - I'm only a contemporary composer. :-) On Mon, Feb 6, 2017 at 10:03 AM, Urs Liska <u...@openlilylib.org> wrote: > > > Am 06.02.2017 um 15:10 schrieb Jeffery Shivers: > > I've thought about this a lot, and I agree that OLL would be the > obvious means to implement a *contemporary notation* package with > LilyPond. > > A huge problem we will face with doing this, which will always be a > problem no matter how accessible/robust the library, is that there > will very often be some unexpected (and probably illogical) way that a > composer wants to notate their music. So if our software doesn't > support what they want, or they have to really *stretch* it to > accomplish their needs, it makes sense for them to turn to something > like inkscape for faster and more straightforward results, even though > that process won't carry all the benefits/flexibility of engraving > with a tool like LilyPond (for example, increasing the horizontal > spacing between everything in a multi-page score on a big ole inkscape > document is a much bigger deal than it is in LilyPond). > > This is all to say, "contemporary notation" encapsulates so many > possibilities, it'll be a tricky and probably exhausting process to > figure out the best way to make its use available to as many users as > possible. Not saying that to be discouraging, just realistic. > > > Your considerations are reasonable, but I wouldn't see it that much as a > problem. It's not that we need to create a tool that is as comprehensive as, > say, LilyPond itself with regard to common notation. What I think would be > useful (and sufficient in the currently discussed context) is a > tool/package/infrastructure that > > proves that non-standard notation can be made availalbe through convenient > and flexible (parametrical) commands, > provides tools to make it easy to build upon, that is to a) create > additional libraries for specific purposes and b) to create custom commands > for "local"use > > > > LilyPond's programmability and especially the provision to make enhanced > features available through (more or less) easy-to-use commands is one of > the major features I've been lobbying with over the recent years. And > with regard to contemporary notation this feature outweighs (IMO) the > fact that creating non-standard notation is more complicated than by > using arbitrary drawing tools. > > Yes, my comment above pretty much echoes that. > > > Yes, exactly. And what I have in mind would simply put some weight on one > side of the scale to make it easier to achieve stuff and to make it more > obvious how cool it can be. > > What I'm thinking of is not a flat collection of notation elements but > rather a hierarchy of > building blocks that can be used to easily build concrete notation elements. > > Yes - any thoughts on what the building blocks are yet? This could - > and should - be an extensive discussion for sure. > > > Thoughts, yet, but not too thought-through yet. A category of tools could > for e
Re: Contemporary notation (Re: GSoC projects list)
I've thought about this a lot, and I agree that OLL would be the obvious means to implement a *contemporary notation* package with LilyPond. A huge problem we will face with doing this, which will always be a problem no matter how accessible/robust the library, is that there will very often be some unexpected (and probably illogical) way that a composer wants to notate their music. So if our software doesn't support what they want, or they have to really *stretch* it to accomplish their needs, it makes sense for them to turn to something like inkscape for faster and more straightforward results, even though that process won't carry all the benefits/flexibility of engraving with a tool like LilyPond (for example, increasing the horizontal spacing between everything in a multi-page score on a big ole inkscape document is a much bigger deal than it is in LilyPond). This is all to say, "contemporary notation" encapsulates so many possibilities, it'll be a tricky and probably exhausting process to figure out the best way to make its use available to as many users as possible. Not saying that to be discouraging, just realistic. > LilyPond's programmability and especially the provision to make enhanced > features available through (more or less) easy-to-use commands is one of > the major features I've been lobbying with over the recent years. And > with regard to contemporary notation this feature outweighs (IMO) the > fact that creating non-standard notation is more complicated than by > using arbitrary drawing tools. Yes, my comment above pretty much echoes that. > What I'm thinking of is not a flat collection of notation elements but rather > a hierarchy of > building blocks that can be used to easily build concrete notation elements. Yes - any thoughts on what the building blocks are yet? This could - and should - be an extensive discussion for sure. On Mon, Feb 6, 2017 at 3:15 AM, Urs Liska <u...@openlilylib.org> wrote: > One thing I'm missing about our projects list is actual *notation* > projects. Currently (i.e. when the current wave of purges has been > completed) there is no project that adds to or improves LilyPond's > notation. All projects are important items, but maybe this isn't really > attractive to students. > > I have one suggestion for which I could be a mentor, but I would really > prefer to act as *secondary* advisor only, with someone else being the > primary mentor: creating a library for contemporary notation. Obviously > it would be an openLilyLib project again, and I'm not feeling 100% > comfortable with that, but I'm sure it would be attractive for potential > students, and it would also add some prominently visible new features to > LilyPond. > > LilyPond's programmability and especially the provision to make enhanced > features available through (more or less) easy-to-use commands is one of > the major features I've been lobbying with over the recent years. And > with regard to contemporary notation this feature outweighs (IMO) the > fact that creating non-standard notation is more complicated than by > using arbitrary drawing tools. > > openLilyLib is a suitable framework to build such a contemporary > notation package and making it easily accessible. What I'm thinking of > is not a flat collection of notation elements but rather a hierarchy of > building blocks that can be used to easily build concrete notation elements. > > Feedback for that? Any of the more proficient composers out there > willing to join? > > Urs > > Am 06.02.2017 um 00:24 schrieb Urs Liska: >> >> Hi all, >> >> I'm somewhat worried about LilyPond's GSoC project proposals list. >> Right now I'm purging the web page >> (http://lilypond.org/google-summer-of-code.html) from projects without >> mentors, and I have the feeling when this process is completed we're >> left with an unsatisfactory state. >> >> From the 9 projects that are listed at the time of writing this post >> four are right now scheduled for removal: >> >> * Grace notes >> * Improving default beam positioning >> * Improving compilation behaviour >> * Improve Slurs and Ties >> >> A fifth project, MusicXML export, is still unclear. >> >> So essentially per now we will have only 4/5 projects left: >> >> * Improving internal chord structure >> * Adopting SMuFL >> * Adding glyph variants >> * openLilyLib testing and documentation >> >> I find this list quite disappointing, and I'm afraid it won't be >> terribly attractive to potential students. So I strongly encourage >> anybody to suggest further projects, preferably together with a pledge >> to mentor them. >> >> Best >> Urs >> >> >
Re: GSoC project ideas
This might be selfish, but how about at least one of those ideas be an OLL (or even scholarLY) thing? I can't guarantee what the exact status of scholarLY annotations and the LaTeX package will be by April - therefore I definitely don't suggest a direct extension of *that/those* projects. (Although I can say that I at least will get the ball rolling again in February when I am finally back in the States (if anxiously so) and have the current wave of work behind me.) But it would be nice to see another project emerge from our little corner of the pond again. On Mon, Jan 23, 2017 at 8:06 PM, Urs Liska <u...@openlilylib.org> wrote: > Hi all, > > GSoC has started and the timeline is proceeding quickly > (https://summerofcode.withgoogle.com/). > > GNU is going to apply until February 9, and by February 27 I expect them > to be accepted to the program, which will make LilyPond applicable as well. > > Students will apply between March 20 and April 3, but we expect them to > get in touch with us earlier. This and the fact that the project ideas > list might be relevant for GNU's application as well suggests that we > update our page ASAP, preferably by February 9. I'm quite positive that > having updated the ideas page had its part in having two projects last > year. > > So please everybody think about possible projects we can put on our > ideas list on http://lilypond.org/google-summer-of-code.html. Projects > should be possible to achieve for someone new to LilyPond within three > months of (full-time) work, and it is necessary to have someone ready to > mentor the project. If you make a suggestion it's not necessary to > volunteer for that project at the same time, although it would make > things easier ;-) > > Best > Urs > > PS: > I've also provided a patch containing a section with recommendations to > potential students. They draw from my own experience as a mentor last > year and suggestions discussed both on the mentors' mailing list and the > mentors' summit last year. Please consider these paragraphs too, as they > may need more refinement and discussion. > > -- > u...@openlilylib.org > https://openlilylib.org > http://lilypondblog.org > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel > -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: referencing hash key with music symbol
>
> So you now state that the predicate is
> "symbol-list-or-music?" and a symbol does _not_, I repeat _not_ satisfy
> that predicate. So it is more than likely that you are _not_ looking at
> 'Slur here but rather at '(Slur), namely indeed a symbol _list_.
No, I had already accounted for that. There were no 'wrong type' errors -
but I *was* getting a variation of other errors from just ever-so-slightly
changing the procedure around, so narrowing any of it down wasn't really
possible. Well, or so it seemed.
The problem turned out to be a syntax-ish issue in the lilypond code block
that happened to use the function. LP oddly wasn't pointing to that line
most times though. In any case, my original hope was that I was missing
some kind of obvious/weird rule about using symbols (or symbol lists..) in
lilypond that perhaps could have been answered without anyone feeling the
need to fully dissect my message, but I guess you can't win 'em all. ;-)
On Sat, Jul 9, 2016 at 1:34 PM, David Kastrup <d...@gnu.org> wrote:
> Jeffery Shivers <jefferyshiv...@gmail.com> writes:
>
> > David, thanks for your response.
> >
> >> #(define mytable (make-hash-table))
> >> >
> >> > #(hash-set! mytable 'Slur slurDashed)
> >> >
> >> >
> >> > \score {
> >> >
> >> > \new Staff {
> >> >
> >> > #(let ((func (hash-ref mytable 'Slur)))
> >> >
> >> > #{
> >> >
> >> > #func f'( g')
> >> >
> >> > #})
> >> >
> >> > }
> >> >
> >> > }
> >> Are you sure this works?
> >
> >
> > I have no idea what you're expecting, but yes. Entirely.
>
> Sorry, that was a first edit left in place: I had to double-check that
> \slurDashed was not a music function but a music identifier.
>
> >> And when LilyPond's opinion conflicts with that, your opinion
> >> does not carry the day when you want LilyPond to act on it.
> >
> >
> > Preach.
> >
> > "argument that the symbol satisfies" is gibberish
> >
> >
> > Not sure if this was a comment more on programming semantics or actual
> > sense; in either case, that's unfair. Regardless of what \criticalRemark
> > fully does, it takes some number of arguments: the one of them that 'Slur
> > satisfies in the context of the example I provided (regardless of
> whatever
> > else could be happening with the function) is a `symbol-list-or-music?`
> > predicate.
>
> That is not an "argument that the symbol satisfies" but rather "the
> symbol satisfies the argument predicate". I repeat: you cannot just
> describe things in vague terms when all that you write is the
> description. So you now state that the predicate is
> "symbol-list-or-music?" and a symbol does _not_, I repeat _not_ satisfy
> that predicate. So it is more than likely that you are _not_ looking at
> 'Slur here but rather at '(Slur), namely indeed a symbol _list_.
>
> Your predicate should match your desired use cases.
> >
> > Maybe 4:00am should be my new cutoff time for asking for help.. The
> > following snippet (which I admit could have been provided initially -
> > and that would have saved us all this pointless conversation) does
> > work, and so tells me the question asked here did not need to be asked
> > in the first place.
>
> Depends on what you want the function to be good for. There are good
> and valid reasons for accepting symbol lists as function arguments (see,
> for example, overrideProperty). Whether this is one of those cases is
> something a minimal example will indeed rarely tell since multiple
> symbols tend to be used only in more complex (and thus non-minimal)
> cases.
>
> But yes, it would have made it possible to actually diagnose your
> problem. When writing just "Slur", LilyPond can turn this, depending on
> current mode and the argument predicate, into a string, a symbol, a
> symbol list or a lyric syllable (and I possibly forgot something here).
> That makes it possible to write a lot of stuff in a rather natural
> manner, but it also means that you need to pick suitable predicates for
> matching the expectations of your code.
>
> Particularly when you don't understand why something isn't working, only
> describing in your own words what you think LilyPond must be seeing,
> without double-checking (or posting) at least the error messages is
> going to require a whole lot of second-guessing. If you don't recognize
> the problem, it is unlikely that your high-level description will
> contain a pointer to what goes wrong.
>
> --
> David Kastrup
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: referencing hash key with music symbol
David, thanks for your response.
> #(define mytable (make-hash-table))
> >
> > #(hash-set! mytable 'Slur slurDashed)
> >
> >
> > \score {
> >
> > \new Staff {
> >
> > #(let ((func (hash-ref mytable 'Slur)))
> >
> > #{
> >
> > #func f'( g')
> >
> > #})
> >
> > }
> >
> > }
> Are you sure this works?
I have no idea what you're expecting, but yes. Entirely.
> And when LilyPond's opinion conflicts with that, your opinion
> does not carry the day when you want LilyPond to act on it.
Preach.
"argument that the symbol satisfies" is gibberish
Not sure if this was a comment more on programming semantics or actual
sense; in either case, that's unfair. Regardless of what \criticalRemark
fully does, it takes some number of arguments: the one of them that 'Slur
satisfies in the context of the example I provided (regardless of whatever
else could be happening with the function) is a `symbol-list-or-music?`
predicate.
Maybe 4:00am should be my new cutoff time for asking for help.. The
following snippet (which I admit could have been provided initially - and
that would have saved us all this pointless conversation) does work, and so
tells me the question asked here did not need to be asked in the first
place.
#(define mytable (make-hash-table))
#(hash-set! mytable 'Slur slurDashed)
foo =
#(define-music-function (item mus)
(symbol? ly:music?)
(let ((func (hash-ref mytable item)))
#{ #func #mus #}))
\score {
\new Staff {
\foo Slur a'( g')
}
}
I strongly suggest to use the openLilyLib option handling infrastructure
> where it would look something like
> \registerOption scholarly.editorial-functions.additions #'()
> \setOption scholarly.editorial-functions.addition.slur #some-function
Urs, this group doesn't necessarily know the mechanics of the above, so it
would not have been sensible to utilize it in the question.
Jeffery
On Sat, Jul 9, 2016 at 7:08 AM, Urs Liska <u...@openlilylib.org> wrote:
> Am 09.07.2016 um 10:37 schrieb Jeffery Shivers:
> > #(define mytable (make-hash-table))
> >
> > #(hash-set! mytable 'Slur slurDashed)
> >
>
> Just a thought thrown in (as said I'm basically not available until
> Monday evening/Tuesday):
> I strongly suggest to use the openLilyLib option handling infrastructure
> where it would look something like
>
> \registerOption scholarly.editorial-functions.additions #'()
> \setOption scholarly.editorial-functions.addition.slur #some-function
>
> Don't know if that helps with your problem but please consider using the
> existing infrastructure.
>
> Urs
>
> --
> Urs Liska
> www.openlilylib.org
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
referencing hash key with music symbol
Hi LP team,
I am working on automating editorial commands with ScholarLY, and I am
having some trouble pulling a music function that is stored in a hash
table. If I make a table and assign a key 'Slur to slurDashed, I can use it
successfully in the following example:
#(define mytable (make-hash-table))
#(hash-set! mytable 'Slur slurDashed)
\score {
\new Staff {
#(let ((func (hash-ref mytable 'Slur)))
#{
#func f'( g')
#})
}
}
In that context, "Slur" is of course an arbitrary name. However, when a
symbol is used to indicate what item is being annotated in scholarly, e.g.:
\criticalRemark \with {
message = "my message"
apply = addition
} Slur f'( g') % "Slur" indicated here
... we will use that symbol to determine what function, previously assigned
to the so-named key in the hash table, to apply to the music. However, when
I attempt to do this, Lily (or maybe Guile) doesn't cooperate. I don't have
a very useful way of minimizing this process, since it takes place in one
of the larger chunks of the library's code, but basically `item` is the
argument that the symbol satisfies, and in (sort of) context, the
unsuccessful use of it looks like:
... (let ((func (hash-ref mytable item))) ...
Replacing "item" with 'Slur works like a charm - `func` applies a dashed
slur in a lilypond code block in the local scope. But I can't seem to work
out why using the symbol name doesn't also work.
Hopefully I've explained the issue clearly enough, and I apologize for the
lack of a better non-working example. Any help is very much appreciated.
Best,
Jeffery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
GSoC - ScholarLY
Dear LilyPond team, I'd like to apply for GSoC to contribute to ScholarLY as a student with Urs Liska. I've been a user of LilyPond and LaTeX for a while now, and am intrigued by the ScholarLY/openLilyLib project. I have less familiar, but basic, understandings of Python and Scheme, from recreational practice. I have an open calendar between late April and late August (minus two weeks in early August for the Darmstadt Summer Courses), and would like to commit my summer to pursuing any aspect(s) of the project that would advance its stability/usefulness. I am a composer and graduate student (transitioning from MA to PhD), so my interest in the project is as a user who directly benefits from this. If you could direct my next steps toward creating a proposal and applying, I'd be grateful. Best wishes, Jeffery ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
