Am 18.01.2016 um 20:20 schrieb Urs Liska: > Am 18.01.2016 um 18:37 schrieb Simon Albrecht: >> On 18.01.2016 18:27, Urs Liska wrote: >>> Am 18.01.2016 um 18:24 schrieb Kieren MacMillan: >>>> Hi Urs, >>>> >>>>> c) >>>>> Take a) as the default and provide a context property >>>> This. >>>> >>>> Thanks, >>>> Kieren. >>>> >>> Any suggestions for a better name than >>> >>> \set subdividedBeamCountAddForShortenedBeam = ##t >> It would almost call for >> \override Beam.subdivide-details.ignore-shortening = ##f >> (this would be the default). Still a bit clumsy, and I don’t want to >> upturn your plans. But the options seem to be complex enough to be >> better stored in an alist. > I find this a very good idea. I don't feel very good with inventing > arbitrary independent context properties. Having a single object and > consistent interface would make it much more consistent to add more > configuration options to the beaming. > > That wouldn't bother my "plans" at all, it's just that I don't know out > of my hat where to define (and initialize) such an alist and how to > access its value from within the C++ beaming code. So any hints welcome ... > > Best > Urs
I am now trying to implement configuration through \override Beam.subdivide-details.beam-count = #'metric \override Beam.subdivide-details.ignore-shortening = ##f etc. but I don't see the proper way of doing so (in C++). I am able to retrieve the property value somewhere in the Beam class (beam.cc), but I don't seem to manage to get that information into Beaming_options or Beaming_pattern. Is it possible that the Beam object is only created when the Beaming_pattern has already been completed? Apart from that question I'd ask more generally: How could I manage to get hold of the values in a Beam.subdivide-details alist from within Beaming_pattern::beamify? Thanks for any pointers Urs > >> Just my 2cts, >> Simon > > > _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user