Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
On Sun, 13 Dec 2015 15:55:08 +0100 "N. Andrew Walsh" wrote: > So I've kludged around with Inkscape, and I'm attaching a few .svg files > to show what I'm getting at. These are *very ugly*, and I would want to > spend a good bit of time working on proportion, weighting, etc.. Please, please, use a font editor like fontforge. It has all the tools built in to deal with proportion, weighting, kerning, combining, and so on. Learning how to use fontforge will pay back quickly. If you want you can still export individual glyphs as svg. -- Johan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
So I've kludged around with Inkscape, and I'm attaching a few .svg files to show what I'm getting at. These are *very ugly*, and I would want to spend a good bit of time working on proportion, weighting, etc.. However, these are the components to build any accidental within a 7-limit system: a vertical line, components for the primes 3, 5, and 7, and the unique accidental for the tonic. The vertical is the file "000.svg", and all the rest should be clear. I don't know enough about making fonts to know how these would work as part of a font file. They would need hinting for ordering and collision avoidance, keeping in mind that there could potentially exits ratios requiring many more of each of these modules (for example, 49/45 would have two of the 007 on top, and two of 003 and one of 005 on the bottom. It would thus probably need to expand vertically somewhat). Anyway, now that I have some svg files, I suppose I can get to working with fiddling with the scaling for Lily. Cheers, A On Sun, Dec 13, 2015 at 2:04 PM, Graham Breed wrote: > From: Urs Liska >> > > >Maybe so, but the result is less portable because (if I understand >>> >correctly) you'd have to have a custom font and have it installed >>> >correctly, etc. for anyone to be able to use the glyph... as opposed >>> >to just having the custom glyphs in an include file that you?re going >>> >to be including anyway. >>> > >>> >-Paul >>> >> I think the font idea*may* be an approach worth considering. >> >> Our stuff will reside in a library anyway, and I think it should be >> possible to have that library call a font reliably when it is in the same >> directory IIRC. >> > > I can get fonts from the current directory no problem on Linux. But > there's a problem with Windows that I still haven't looked into. There's > surely a way around it, though. > > We could then have a font with glyphs for each constituent of your >> accidentals and construct the actual accidental as a markup using \combine, >> which should be pretty straightforward. >> > > If the glyphs are pre-built, a font file is the obvious place to store > them. If they have to be combined, it's a bit harder because it has to be > a text font, but this problem is also solved. There's a problem with more > recent Lilyponds where the accidentals can collide with barlines, but if > you can pin it down and report it I'm sure that can be fixed. I think the > rules for combining symbols into glyphs can all be written into the font > files but that may not be the easiest way to do it. > > The nice thing about fonts, though, is that some already exist. The > problems with generating large lookup tables, or multiplying ratios, or > factorizing this or that, can all be solved with the Extended > Helmholtz-Ellis JI system, and when everything's working you can drop the > new glyphs or start drawing them some other way. > > It's nice that you think keeping the primes distinct is straightforward. > I thought it was difficult, especially if you want MIDI playback and > transpositions to be correct, but not impossible. > > A large lookup table, corresponding to a sensible equal temperament for > wraparound, is probably the best way to get started. The system is > potentially infinite, but you can set limits on how far you expect > modulation to go. People keep being pessimistic about Lilypond or Scheme's > performance with large tables but so far nobody's produced a huge table and > demonstrated it to be unacceptably slow. > > > > Graham > > > ___ > 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: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
From: Urs Liska >Maybe so, but the result is less portable because (if I understand >correctly) you'd have to have a custom font and have it installed >correctly, etc. for anyone to be able to use the glyph... as opposed >to just having the custom glyphs in an include file that you?re going >to be including anyway. > >-Paul I think the font idea*may* be an approach worth considering. Our stuff will reside in a library anyway, and I think it should be possible to have that library call a font reliably when it is in the same directory IIRC. I can get fonts from the current directory no problem on Linux. But there's a problem with Windows that I still haven't looked into. There's surely a way around it, though. We could then have a font with glyphs for each constituent of your accidentals and construct the actual accidental as a markup using \combine, which should be pretty straightforward. If the glyphs are pre-built, a font file is the obvious place to store them. If they have to be combined, it's a bit harder because it has to be a text font, but this problem is also solved. There's a problem with more recent Lilyponds where the accidentals can collide with barlines, but if you can pin it down and report it I'm sure that can be fixed. I think the rules for combining symbols into glyphs can all be written into the font files but that may not be the easiest way to do it. The nice thing about fonts, though, is that some already exist. The problems with generating large lookup tables, or multiplying ratios, or factorizing this or that, can all be solved with the Extended Helmholtz-Ellis JI system, and when everything's working you can drop the new glyphs or start drawing them some other way. It's nice that you think keeping the primes distinct is straightforward. I thought it was difficult, especially if you want MIDI playback and transpositions to be correct, but not impossible. A large lookup table, corresponding to a sensible equal temperament for wraparound, is probably the best way to get started. The system is potentially infinite, but you can set limits on how far you expect modulation to go. People keep being pessimistic about Lilypond or Scheme's performance with large tables but so far nobody's produced a huge table and demonstrated it to be unacceptably slow. Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
See the previous message from me, which links to it and provides instructions for its use. Cheers, A On Sun, Dec 13, 2015 at 1:04 PM, Graham Breed wrote: > From: "N. Andrew Walsh" >> > > Actually, coverting between the ratios and semitones has alread been done, >> as there's a simple set of log and mround functions that do it. Have a >> look >> in the OLL repository under notation-tools and you should find the .ily >> files. >> > > What's the OLL repository? > > > Graham > > > ___ > 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: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
From: "N. Andrew Walsh" Actually, coverting between the ratios and semitones has alread been done, as there's a simple set of log and mround functions that do it. Have a look in the OLL repository under notation-tools and you should find the .ily files. What's the OLL repository? Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
sorry. You have to switch to the just-intonation-stub branch, which is here: https://github.com/openlilylib/snippets/tree/just-intonation-stub/notation-snippets Cheers, A On Sun, Dec 13, 2015 at 10:13 AM, wrote: > On Sun, 13 Dec 2015, N. Andrew Walsh wrote: > > Actually, coverting between the ratios and semitones has alread been > done, > > as there's a simple set of log and mround functions that do it. Have a > look > > in the OLL repository under notation-tools and you should find the .ily > > At what URL? I'm looking in https://github.com/openlilylib/openlilylib > and can't find a directory called "notation-tools" at all, nor this kind > of code in the directories that do exist. > > -- > Matthew Skala > msk...@ansuz.sooke.bc.ca People before principles. > http://ansuz.sooke.bc.ca/ > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
On Sun, 13 Dec 2015, N. Andrew Walsh wrote: > Actually, coverting between the ratios and semitones has alread been done, > as there's a simple set of log and mround functions that do it. Have a look > in the OLL repository under notation-tools and you should find the .ily At what URL? I'm looking in https://github.com/openlilylib/openlilylib and can't find a directory called "notation-tools" at all, nor this kind of code in the directories that do exist. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
Actually, coverting between the ratios and semitones has alread been done, as there's a simple set of log and mround functions that do it. Have a look in the OLL repository under notation-tools and you should find the .ily files. Cheers, A On Sun, Dec 13, 2015 at 7:51 AM, wrote: > On Sat, 12 Dec 2015, N. Andrew Walsh wrote: > > accidentals as needed. I suppose, rather than having Lily/Scheme > calculate > > prime factors on the fly at runtime, it would be easier to have a lookup > > table of the prime factorization for each integer up to a certain limit > (but > > that would end up being very high, so maybe not). That's a computational > > problem for further down the road, though. > > For numbers of 32 bits or so, doing prime factorization by simple-minded > trial and error on a present-day computer is cheaper than most people > realize. It's a tight loop that fits in cache; the arithmetic may > actually be faster than a lookup table in main memory, and it's at least > unlikely to be prohibitively slow. > > I think a trickier computational problem may be converting between > LilyPond's "rational number of semitones" and just-intonation's "rational > ratio of frequencies" ways to express pitch. Because of the log function > in between, in general any number that has a representation on one of > those scales will have no exact representation on the other, and you're > forced to do some kind of rounding, or maybe abandon LilyPond's pitch > scheme for something else. Have you decided how you want to deal with > this issue yet? > > -- > Matthew Skala > msk...@ansuz.sooke.bc.ca People before principles. > http://ansuz.sooke.bc.ca/ > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
On Sat, 12 Dec 2015, N. Andrew Walsh wrote: > accidentals as needed. I suppose, rather than having Lily/Scheme calculate > prime factors on the fly at runtime, it would be easier to have a lookup > table of the prime factorization for each integer up to a certain limit (but > that would end up being very high, so maybe not). That's a computational > problem for further down the road, though. For numbers of 32 bits or so, doing prime factorization by simple-minded trial and error on a present-day computer is cheaper than most people realize. It's a tight loop that fits in cache; the arithmetic may actually be faster than a lookup table in main memory, and it's at least unlikely to be prohibitively slow. I think a trickier computational problem may be converting between LilyPond's "rational number of semitones" and just-intonation's "rational ratio of frequencies" ways to express pitch. Because of the log function in between, in general any number that has a representation on one of those scales will have no exact representation on the other, and you're forced to do some kind of rounding, or maybe abandon LilyPond's pitch scheme for something else. Have you decided how you want to deal with this issue yet? -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
Am 12. Dezember 2015 23:08:53 MEZ, schrieb Paul Morris : >> On Dec 12, 2015, at 3:34 PM, Johan Vromans >wrote: >> >> If I understand the procedure correctly, wouldn't it be easier to use >a >> tool like fontforge add/adjust font glyphs? > >Maybe so, but the result is less portable because (if I understand >correctly) you'd have to have a custom font and have it installed >correctly, etc. for anyone to be able to use the glyph... as opposed >to just having the custom glyphs in an include file that you’re going >to be including anyway. > >-Paul I think the font idea *may* be an approach worth considering. Our stuff will reside in a library anyway, and I think it should be possible to have that library call a font reliably when it is in the same directory IIRC. We could then have a font with glyphs for each constituent of your accidentals and construct the actual accidental as a markup using \combine, which should be pretty straightforward. Urs >___ >lilypond-user mailing list >lilypond-user@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-user -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
> On Dec 12, 2015, at 3:34 PM, Johan Vromans wrote: > > If I understand the procedure correctly, wouldn't it be easier to use a > tool like fontforge add/adjust font glyphs? Maybe so, but the result is less portable because (if I understand correctly) you'd have to have a custom font and have it installed correctly, etc. for anyone to be able to use the glyph... as opposed to just having the custom glyphs in an include file that you’re going to be including anyway. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
It would not, because the accidentals I use are in an open system of just intonation (not a fixed scale) in which *any* conceivable ratio can be represented (so long as I have the module for its respective prime factors). This is a serious limitation of a lot of systems, in that the moment you start getting into primes above, say, 17 (or even to certain combinations of them), there are no accidentals to represent them, and you're back to using numbers in markups. My endgame here is to make stencils for each prime factor up to 512 (so, 2^10, thus ten octaves, of which there are about 100 primes [which seems felicitous]), so that you can represent any conceivable fraction up to a ridiculous complexity, on the fly, within Lily. In that context, it makes much more sense (so far as I can tell) to make individual stencils for each prime, and then arrange them for the accidentals as needed. I suppose, rather than having Lily/Scheme calculate prime factors on the fly at runtime, it would be easier to have a lookup table of the prime factorization for each integer up to a certain limit (but that would end up being very high, so maybe not). That's a computational problem for further down the road, though. For now, I'll get to fiddling with Inkscape and trying to make some stencils, so I can at least show what I'm talking about. Cheers, A On Sat, Dec 12, 2015 at 9:34 PM, Johan Vromans wrote: > > Anyway, that’s how I’ve done this kind of thing. It’s not simple but it > > works! > > If I understand the procedure correctly, wouldn't it be easier to use a > tool like fontforge add/adjust font glyphs? > > -- Johan > > ___ > 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: converting svg glyph to path data for use in scheme (was: accidentals for just intonation)
> Anyway, that’s how I’ve done this kind of thing. It’s not simple but it > works! If I understand the procedure correctly, wouldn't it be easier to use a tool like fontforge add/adjust font glyphs? -- Johan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user