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 <gbr...@gmail.com> wrote: > From: Urs Liska<u...@openlilylib.org> >> > > >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
