Hi Urs, Thank you for your kind advice. On Fri, 29 Mar 2019 at 00:03, Urs Liska <li...@openlilylib.org> wrote:
> Hi Tsz Kiu, > > I don't know if you intentionally replied personally instead of to the > list, and in general as much communication as possible should be kept > public. But since the nature of what you're writing could be considered > personal to some extent I'll reply in private as well. > Sorry that was a mistake, I will try to keep the communication public from now on. > Am 28.03.19 um 13:28 schrieb Tsz Kiu Pang: > > Hi Urs, > > Sorry for the late reply, has been swamped by school work in the past few > days. > > > OK. I'm in a hurry, so just some short comments where necessary. > > > > On Sat, 23 Mar 2019 at 10:22, Urs Liska <li...@openlilylib.org> wrote: > >> A specific composer's package would be a secondary package built on top >>> of a general package, and I think it would be great to aim at starting >>> one for one specific composer (the one I had always thought of as a >>> basis was Lachenmann, but Xenakis or Carter are equally valid choices), >>> although it is not a requirement to achieve /comprehensive/ coverage of >>> a composer. >>> >> >> Yes, I agree that the secondary package would have to be build on top of >> a general package, and this is great since I hope this project can make >> contemporary notation accessible to LilyPond users in a general sense, but >> not just focusing on one or two composers. >> >> >> The idea (as far as I have thought about it in the past) is to provide >> "building blocks" like functions that help create custom elements that >> behave like slurs ("lines" connecting two notes), elements that use paths >> to draw custom notation elements and more such basics. On top of that >> concrete commands should be built and organized maybe by repertoire or >> composer or whatever. But the building blocks should enable the creation of >> packages supporting something specific or the creation of a personal >> library of one's own notation repertoire. >> >> >> >> >> The Scheme/Guile part has three steps for you to consider: >>> >>> * "Counting parentheses" (i.e. the language basics) >>> Depending on how far you've got https://scheme-book.ursliska.de >>> might be a useful resource for you. It goes only that far but it >>> specifically addresses a) the Scheme language from a dedicated >>> LilyPond perspective and b) users counting parentheses (i.e. giving >>> a pretty slow-paced introduction) >>> * Understanding how Scheme is hooked into LilyPond (on a general level) >>> * (Learning how openLilyLib ist structured) >>> * Learning how to retrieve the relevant information about score >>> elements and how to modify them in appropriate places. >>> >>> The last one is probably the hardest one since it is pretty opaque and >>> terribly documented. But it's the crucial one for a contemporary >>> notation package - and it's the one where such a package will make it >>> hugely easier for people to work with non-standard notation. >>> >> >> They all sound pretty hard, but your website seems like a great resource. >> I will definitely have a look at it. >> Regarding learning how Scheme is hooked into LilyPond, what is some other >> good resource for it, apart from your website? >> >> >> The "official" reference is at >> http://lilypond.org/doc/v2.19/Documentation/extending/index. However, >> one may find it somewhat hard to digest since obviously it is not always >> written with readers in mind who do not already know a lot about it ... >> > I did not have time in the past few days to go through the official > reference yet, but I did find your tutorial on scheme really helpful since > it is given from a Lilypond perspective, rather than a general one. > >> >> Just last week I've decided to start with a new openLilyLib package: >>> https://github.com/openlilylib/grob-tools. The repository on Github is >>> empty, and right now I only have one single uncommited function locally, >>> but the idea is to create building blocks for recurring tasks like >>> getting the exact position of objects relative to the staff or to >>> another object, enumerating all NoteColumns included in a slur or >>> similar things. This will be very much relevant for a contemporary >>> notation package. One could either say that you should put much of your >>> results in that package, or we can try to make development of that >>> package a community effort so that would take work from you, giving you >>> the freedom to go further with the specific challenges. >>> >> >> Making the development as a community effort sounds great, though I >> cannot say for sure until I have a solid proposal. >> >> >> What I mean is that to some extent that package could be developed by >> others ("the community"), relieving you from some of the work. However, I >> absolutely can't make any promise that this would work out with regard to >> the community dynamic. >> >> >> This does sound good, a community effort on this project can probably let > me focus on a more abstract level of things. > >> >> What you should do now is: >>> >>> * [of course dive more into Scheme] >>> * get an understanding of openLilyLib with >>> a) https://github.com/openlilylib/oll-core/wiki >>> b) the code in that repository >>> c) looking at how other openLilyLib packages are built within that >>> infrastructure >>> * Form an idea how a contemporary notation package could be approached >>> and discuss that with us >>> * Find some small things you could do to openLilyLib package(s) to a) >>> practice and b) give us an opportunity to assess your work. If we >>> have some idea about your current familiarity with the matter we can >>> find some suggestions for that. >>> >> >> Thank you for your concrete and useful suggestions. >> I will definitely learn how to count parentheses and all that, and also >> try to familiarise myself with openLilyLib. >> Though if you do not mind, please except a lot of questions from me in >> these couple of weeks. >> >> >> Please don't hesitate! The more you interact with us the more we will get >> to know you. It's also a good way to convince a community of the >> seriousness of your aspirations ;-) >> > > I just have some concerns. > Sorry I might have overestimated myself in the past week, but I realised I > might not be able to commit for 30+ hours per week during May since I am in > Australia, the exams are usually in May-early June. > > > In general "full time" commitment is expected throughout the official > coding period, and we can't make substantial exceptions. However, a) the > coding period only begins May 27, the "bonding period" is explicitly not > included in the full-time commitment. b) it is possible to circumvent the > issue by starting earlier. I have no idea about your workload during and > before exams, but if you should be accepted (which is announced May 6) and > are able to do *some* work in May (not full-time) that would otherwise be > part of your work in June that should be OK. When exactly would your exams > be over? What would be your estimate for being able to do *something* in > May? > > Although it is hard to predict exactly what would be my workload in the next couple of months, I can say I would be able to commit 8-10 hours per week once I've got accepted. Though I have just realised I was mistaken before, that my exams is from 11th to 28th June. I can still commit 8 hours per week during that time. However, considering that it is way into June, I am not sure whether that will fit into the GSoC timeline. Worst scenario is that, I might just try to apply for GSoC next year when I have less study load. Having said that, I am passionate about this project. > I just want to check in what is the expectation from you guys in terms of > commitment? > I might reevaluate myself in these couple of days. > Just in case, if I realise in these few days that I do not have the > capacity for GSoC, would I still be able to contribute to this (or Lilypond > dev in general) in anyway? > I would definitely be keen to contribute to the Lilypond community within > or outside GSoC. > > > Of course that would be great. There's absolutely nothing that speaks > against this. > Thank you for your support. Kind regards, Tsz Kiu > Best > Urs > > > Best >> Urs >> >> >> >> Regards, >> Tsz Kiu >> >> >>> _______________________________________________ >>> 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