Re: Efficiency of alist vs. vector/array
Obviously I didn't make myself clear enough and probably I should have invested the time for a minimal example. When sloppily using the word "override" I didn't mean "\override" but applying a value to a grob property in a grob callback function. I have a data structure idTweaks, currently using an alist: idTweaks = #'() This alist gets populated with elements consisting of a key and a #'(property . value) pair with idTweak = #(define-void-function (id prop val)(string? symbol? scheme?) (set! idTweaks (assoc-set! idTweaks id (cons prop val using commands like \idTweak "id-1" color #red \idTweak "id-2" extra-offset #'(2 . -2) In the callback stage the callback function looks up if a grob has an 'id property and if there's a matching entry in idTweaks: #(define (apply-tweaks grob) (let* ((id (ly:grob-property grob 'id)) (tweak (if (null? id) #f (assoc-ref idTweaks id (if tweak (ly:grob-set-property! grob (car tweak) (cdr tweak) Finally in the music the callback is registered and ids assigned to grobs: { \override NoteHead.before-line-breaking = #apply-tweaks \override Script.before-line-breaking = #apply-tweaks \once \override NoteHead.id = "id-1" c' d' -\tweak #'id "id-3" \f e' -\tweak #'id "id-2" -> } In this case three items have an id but only two have a tweak assigned: the c' notehead will be red and the accent on the e will be offset. (With some additional complexity this can be extended to store lists of tweaks to an object (e.g. override both color and extra-offset) and to access the notecolumn, e.g. to shift a note horizontally when still in the before-line-breaking stage). Am 18.07.2017 um 18:52 schrieb David Kastrup: > Urs Liska writes: > >> What I do *not* know is: would that be worth it (apart from the >> educational value) in real life? In that project I had a song of a few >> pages containing about 5.600 IDs. It's not clear how many override >> that would get when finished, but let's assume it'll grow to a few >> hundred and take 100 as a hypothetical reference. > Why? If you do \override without \temporary, any previous alist element > with the given id set in the same context will be removed first. > > So where do you get the 100? The 100 is a hypothetical number of tweaks that I may need to apply when I'm going to bring the score to publication quality. The 5.600 is the actual number of 'id tweaks produced by the external script that has generated the .ly file. My question is: an alist is obviously not the ideal data structure for this setting as it will require 5.600 alist lookups with 555.000 actual comparisons. If idTweaks was something that can be searched binarily it would be 5.500x8 (for the unused ids) + 100x4 (for the actual matches) comparisons, which is significantly less. The question (at my learning stage) is: does it really matter in that order of magnitude or would it be "premature optimization" to look for an improved algorithm/data structure? And how would the perspective of dramatically bigger scores affect that estimate? > >> My gut feeling is that's really a lot of unnecessary stuff, and one >> should try to improve where possible. OTOH I don't really have >> substantial experience wtih this tpic and don't know how that relates >> to what's going on in the whole compilation process. OTOH what would >> be if I consider using such a setting for a full symphony with maybe >> 100.000 grobs and 1.000 overrides? Would I then have to consider a >> better data structure? Would I then have to think about a totally >> different approach? >> >> Any food for thought, educated guesses, advice? > You could use an object property just for storing the id of a grob if > the override machinery (which works in context hierarchies and handles > subproperties) is not needed. > > Check out make-object-property in the manual. This probably doesn't apply to my original use-case but I'll do that anyway, of course. Best Urs -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Efficiency of alist vs. vector/array
Urs Liska writes: > Obviously I didn't make myself clear enough and probably I should have > invested the time for a minimal example. When sloppily using the word > "override" I didn't mean "\override" but applying a value to a grob > property in a grob callback function. > > I have a data structure idTweaks, currently using an alist: > > idTweaks = #'() > > This alist gets populated with elements consisting of a key and a > #'(property . value) pair with > > idTweak = > #(define-void-function (id prop val)(string? symbol? scheme?) >(set! idTweaks (assoc-set! idTweaks id (cons prop val > > using commands like > > \idTweak "id-1" color #red > \idTweak "id-2" extra-offset #'(2 . -2) You are aware that idTweaks.id-1.color = #red idTweaks.id-2.extra-offset = #'(2 . -2) would have done the same? > In the callback stage the callback function looks up if a grob has an > 'id property and if there's a matching entry in idTweaks: > > #(define (apply-tweaks grob) >(let* > ((id (ly:grob-property grob 'id)) > (tweak (if (null? id) > #f > (assoc-ref idTweaks id > (if tweak > (ly:grob-set-property! grob (car tweak) (cdr tweak) At any rate: yes it would make sense to use a hashtable here. It would also make a lot of sense to use 'id-1 (namely a symbol) rather than "id-1" for lookup since symbols are much easier and faster to compare for equality than strings are (and can be compared using eq? rather than equal?). I wouldn't tamper with the alist-based property handling of grobs though. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Efficiency of alist vs. vector/array
Am 19.07.2017 um 10:43 schrieb David Kastrup: > Urs Liska writes: > >> Obviously I didn't make myself clear enough and probably I should have >> invested the time for a minimal example. When sloppily using the word >> "override" I didn't mean "\override" but applying a value to a grob >> property in a grob callback function. >> >> I have a data structure idTweaks, currently using an alist: >> >> idTweaks = #'() >> >> This alist gets populated with elements consisting of a key and a >> #'(property . value) pair with >> >> idTweak = >> #(define-void-function (id prop val)(string? symbol? scheme?) >>(set! idTweaks (assoc-set! idTweaks id (cons prop val >> >> using commands like >> >> \idTweak "id-1" color #red >> \idTweak "id-2" extra-offset #'(2 . -2) > You are aware that > > idTweaks.id-1.color = #red > idTweaks.id-2.extra-offset = #'(2 . -2) > > would have done the same? No! (but only if id-1 were a symbol, right? >> In the callback stage the callback function looks up if a grob has an >> 'id property and if there's a matching entry in idTweaks: >> >> #(define (apply-tweaks grob) >>(let* >> ((id (ly:grob-property grob 'id)) >> (tweak (if (null? id) >> #f >> (assoc-ref idTweaks id >> (if tweak >> (ly:grob-set-property! grob (car tweak) (cdr tweak) > At any rate: yes it would make sense to use a hashtable here. OK, good to know (and be confirmed). > It would > also make a lot of sense to use 'id-1 (namely a symbol) rather than > "id-1" for lookup since symbols are much easier and faster to compare > for equality than strings are (and can be compared using eq? rather than > equal?). In fact in my real example I *do* change the typecheck of the id property to use symbols, but I didn't want to complicate the minimal example :-) > I wouldn't tamper with the alist-based property handling of > grobs though. I didn't think about such a thing. Best Urs -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Efficiency of alist vs. vector/array
Urs Liska writes: > Am 19.07.2017 um 10:43 schrieb David Kastrup: >> Urs Liska writes: >> >>> Obviously I didn't make myself clear enough and probably I should have >>> invested the time for a minimal example. When sloppily using the word >>> "override" I didn't mean "\override" but applying a value to a grob >>> property in a grob callback function. >>> >>> I have a data structure idTweaks, currently using an alist: >>> >>> idTweaks = #'() >>> >>> This alist gets populated with elements consisting of a key and a >>> #'(property . value) pair with >>> >>> idTweak = >>> #(define-void-function (id prop val)(string? symbol? scheme?) >>>(set! idTweaks (assoc-set! idTweaks id (cons prop val >>> >>> using commands like >>> >>> \idTweak "id-1" color #red >>> \idTweak "id-2" extra-offset #'(2 . -2) >> You are aware that >> >> idTweaks.id-1.color = #red >> idTweaks.id-2.extra-offset = #'(2 . -2) >> >> would have done the same? > > No! > (but only if id-1 were a symbol, right? Ouch. I grow old. In Scheme, it is, but of course not in LilyPond. idTweaks.1.color would actually work (but be something different) and idTweaks."id-1".color = #red would work in current versions (and be the same as your code). I had a longstanding idea where LilyPond would accept alists which could use either a hash or vector rather than a pair as element (or even tail?) of an alist. Obviously that could speed up some operations (and at least the default grob properties would not significantly slow down the lookup of either them or unset properties). One would also be able to "compress" such lists on-demand and convert them into hashtables. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
about arabic.ly and hel_arabic_makam.ly
Hello, In 2014 I realized hel_arabic_makam.ly, It turns out that in 2017, Amir Czwink made the same thing, I ask if I was not pirated. In 2014 ,I wanted to send him to the authors of Lilypond,, but I did not know how to make. Moreover I can prove him, with the system unix (Linux) (with the commande ls -l) and impressions of screens. howver my file hel_arabic_makam.ly does not base itself on the file italaniano.ly. It uses the notation c d e f g a b. I carried out hel_arabic_makam.ly in 2013, while basing myself on makam.ly and italiano.ly. It depends neither on italiano.ly nor of makam.ly however my file can be used jointly with arabic.ly. It uses the notation c d e f g a b instead of re mi fa so la si. I have write several versions. I react thus, it is a history of honest intellectual. I can eventually , send you ,hel_arabic_makam.ly what can i do ? Excuse me for my english, i write usually in french . Thank you very match hassan el fatihi ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
about arabic.ly and hel_arabic_makam.ly
Hello, In 2014 I realized hel_arabic_makam.ly, It turns out that in 2017, Amir Czwink made the same thing, I ask if I was not pirated. In 2014 ,I wanted to send him to the authors of Lilypond,, but I did not know how to make. Moreover I can prove him, with the system unix (Linux) (with the commande ls -l) and impressions of screens. howver my file hel_arabic_makam.ly does not base itself on the file italaniano.ly. It uses the notation c d e f g a b. I carried out hel_arabic_makam.ly in 2013, while basing myself on makam.ly and italiano.ly. It depends neither on italiano.ly nor of makam.ly however my file can be used jointly with arabic.ly. It uses the notation c d e f g a b instead of re mi fa so la si. I have write several versions. I react thus, it is a history of honest intellectual. I can eventually , send you ,hel_arabic_makam.ly what can i do ? Excuse me for my english, i write usually in french . Thank you very match hassan el fatihi ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
about arabic.ly and hel_arabic_makam.ly
Hello, In 2014 I realized hel_arabic_makam.ly, It turns out that in 2017, Amir Czwink made the same thing, I ask if I was not pirated. In 2014 ,I wanted to send him to the authors of Lilypond,, but I did not know how to make. Moreover I can prove him, with the system unix (Linux) (with the commande ls -l) and impressions of screens. howver my file hel_arabic_makam.ly does not base itself on the file italaniano.ly. It uses the notation c d e f g a b. I carried out hel_arabic_makam.ly in 2013, while basing myself on makam.ly and italiano.ly. It depends neither on italiano.ly nor of makam.ly however my file can be used jointly with arabic.ly. It uses the notation c d e f g a b instead of re mi fa so la si. I have write several versions. I react thus, it is a history of honest intellectual. I can eventually , send you ,hel_arabic_makam.ly what can i do ? Excuse me for my english, i write usually in french . Thank you very match hassan el fatihi ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: about arabic.ly and hel_arabic_makam.ly
On 7/19/2017 10:18 AM, hassan.elfat...@free.fr wrote: > i write usually in french lilypond-user...@gnu.org https://lists.gnu.org/archive/html/lilypond-user-fr/ -- Karlin High Missouri, USA ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Silencing chordNames
Hi Steve, > Having trouble finding how to silence chordNames while not silencing > the rest of the arrangement. I would have thought it wa easy but can't > spot it. Can someone point me at it. Oh, so many options… 1. Don't include the ChordNames context in your score in the first place…? 2. \layout { \context { \Score \omit ChordNames } } etc. etc. Hope this helps, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Silencing chordNames
Hello all, Having trouble finding how to silence chordNames while not silencing the rest of the arrangement. I would have thought it wa easy but can't spot it. Can someone point me at it. Many thanks Steve ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: [Suspected Spam] about arabic.ly and hel_arabic_makam.ly
> On 19 Jul 2017, at 17:18, hassan.elfat...@free.fr wrote: > I carried out hel_arabic_makam.ly in 2013, while basing myself on makam.ly The file makam.ly does not transpose correctly, cf. the thread [1]. It is possible to typeset correctly in other ETs, for example E53, cf. [2] for Arabic maqam in Helmholtz-Ellis notation. The traditional Arabic notation cannot capture all microtones, cf. [3]. 1. http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00172.html 2. http://lists.gnu.org/archive/html/lilypond-user/2016-02/msg00607.html 3. http://www.maqamworld.com/maqamat/sikah.html#sikah-baladi ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Silencing chordNames
I seem to remember answering this on the forum before, and with information I found on this forum, but not knowing what search terms to suggest right off, here is the code I use in 2.18 (in blissful anticipation of the new stability...): \midi { \context{ \ChordNameVoice \remove Note_performer } } Is that what you need? David -- View this message in context: http://lilypond.1069038.n5.nabble.com/Silencing-chordNames-tp204519p204523.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
hel_arabic_makam.ly
No spam . It works wonderfully. I am a player of oud and classical guitar , 25 years for guitar and 20 years for oud . I know perfectly the Arab makams. And I wrote a lot of scores. , Using hel_arabic_makam.ly for oud of course. look this pdf file music. Thank's HassaMusic.pdf Description: Adobe PDF document ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: hel_arabic_makam.ly
> On 19 Jul 2017, at 23:41, hassan.elfat...@free.fr wrote: > > No spam . Sorry, probably my ISP added it, and I forgot to remove it. > It works wonderfully. I am a player of oud and classical guitar , 25 years > for guitar and 20 years for oud . I know perfectly the Arab makams. What does the MIDI at [1] sound to your ears? Are the microtones too low or too high? 1. http://lists.gnu.org/archive/html/lilypond-user/2016-02/msg00607.html > And I wrote a lot of scores. > , Using hel_arabic_makam.ly for oud of course. > look this pdf file music. I haven't seen the code, but as long as you do not transpose or bother about the MIDI it does not matter. If you want to transpose but do not care about the MIDI, you might try dividing the sharp into 5 instead of dividing the whole tone into 9 as makam.ly does. If you want the tuning to be right, then E53 is merely an equal temperament which is very close to Pythagorean tuning, which is what you get when tuning the oud in fourths. But on [2], the an accordion in E12 with the microtone set rather high, I think, so perhaps it does not matter so much. 2. https://www.youtube.com/watch?v=fvp6fo7tfpk ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user