Re: Co-chair meeting minutes: October 11, 2022 [via Music Notation Community Group]

Hi Daniel,

thanks for your kind and fast response.

I fully understand 1. and 2. I never dived into how OTF and other font 
formats work but already had doubts that complexity such as 2. is 
actually doable with such fonts. After rethinking it is most probably 
impossible after all.

However, just to share still a little bit of disappointment: My vision 
is that simply by switching between SMuFL compatible fonts, I can change 
between "themes" (anchient, modern, handwritten, etc. styles of the 
music notation). While SMuFL really helps great in this regard, I still 
see some drawbacks here: Now, when I have to use low-level line, filled 
rectangle, parallelogram, bezier curves, and the like to render voltas, 
slurs, beams and for beam groups also stems (as their height has to be 
customized) manually myself, then at least some part of that vision does 
not come true.

Anyhow, thanks to all you guys out here creating SMuFL what seems quite 
a complex standard (so in other words lots of effort, sweat and tears - 
hopefully also some fun) addressing many many needs of score music and 
IMHO is a gigantic step ahead compared to plain Unicode Music Block.

Cheers

   Jörg

Am 07.11.2022 um 10:30 schrieb Daniel Spreadbury:
>
> Hi Jörg,
>
> Thanks for your message, and for introducing yourself to the community 
> group. I can provide you with a couple of quick answers:
>
> 1. The brackets and numbers that appear in voltas (or repeat endings) 
> are not encoded by SMuFL; you can end up with quite complex textual 
> instructions tucked into those brackets, so we concluded it is better 
> to simply use regular text from a normal text font to represent those; 
> and we chose not to encode the brackets themselves, since they have 
> many of the same kinds of problems of any “spanning” event that needs 
> to adjust according to the spacing of the music, which is tricky to do 
> purely in a font. It’s therefore recommended to draw repeat endings 
> fully using primitives and strings from regular text fonts.
>
> 2. The slots in SMuFL for encoding slur starts and ends etc. were 
> brought over from the original Music Notation range in Unicode, of 
> which SMuFL is designed to be a superset. To my knowledge, no font has 
> ever attempted an implementation of these characters, whether in their 
> location in the Music Notation range or in their corresponding 
> location in SMuFL. I’m afraid the heavy lifting of calculating and 
> rendering beams, ties and slurs is left to application developers to 
> handle.
>
> In terms of whether your text format might find a home in the W3C 
> Music Notation CG in future, it’s certainly possible: our incoming 
> co-chair Myke Cuthbert has proposed that the CG might be the home for 
> the text format he co-created that represents Roman numeral 
> harmony/chord descriptions, and this is something that we will 
> consider in due course. We haven’t made any further determinations on 
> this subject at the moment, but the door is at least open for the 
> discussion.
>
> All the best,
>
> Daniel
>
> *From: *Hohwiller, Jörg <joerg.hohwiller@googlemail.com>
> *Date: *Monday, 7 November 2022 at 09:22
> *To: *public-music-notation@w3.org <public-music-notation@w3.org>
> *Subject: *Re: Co-chair meeting minutes: October 11, 2022 [via Music 
> Notation Community Group]
>
> Dear music-notation group,
>
> I am an open-source developer (as well as professional software
> developer and architect) and musician and just joined this group to get
> some exchange and help.
>
> After contributing to open source music software like OpenSongTabletApp,
> I decided to implement a true open-source app for android tablet devices
> supporting musicians with full fledged scores and auto-scolling, midi
> playback and so forth. As a fan of simple markup languages like AsciiDoc
> and ChordPro, I stumbled over ABC and did some experiments. However,
> used to the simplicity of ChordPro I wanted use this as a starting point
> but extend it with concepts of ABC. So I created a format called
> MusicDoc and started forming an Open-Source project around it that can
> be found here:
>
> https://musicdoc.github.io/ <https://musicdoc.github.io/>
>
> I already implemented a model for songs and their score with
> stave-systems, staves, clef, metre, voices, rests, notes, all kind of
> decorations, slurs, ties, bars and all the complex things that music has
> to offer. I can already read and write different formats like ABC,
> MusicDoc, OpenSong from/to that model. I also plan to support MusicXML
> as well as Midi what will also keep me busy many weekends in the future.
>
> Currently I am working on rendering the model to graphics (music sheet).
> To make my code re-uasble I started creating a rendering engine that can
> do the complex layout computation as an abstract reusable renderer that
> I can then reuse for Android SDK graphics, JavaFx, or generation of PDF
> or SVG. While I am just starting with this and fortunately stumbled over
> SMuFL that I decided to use, I collected quite some questions that I
> want to ask here and hope to find some answers:
>
> 1. I searched the entire specification of SMuFL but could not find
> anything about a volta. IMHO this is quite a common construct in sheet
> music so I would love to know if I either missed something or if there
> is a reason that SMuFL does not specify anything for it (the volta
> "bracket" or the repeat numbers such as "1.-3., 5." written under that
> "bracket" - I am asking for the latter as there is a glyph for way more
> exotic stuff in in SMuFL - not only for every digit of the metre or a
> tuplet, including inversed notations but also Kahnotation or whatever
> exotic stuff I have never seen in my life and most probably will never
> use in my life as musician)?
>
> 2. Maybe I just scanned the SMuFL specification (but already know a lot
> about Unicode from my work) that is quite complex, but when I found
> things like combining characters to start and end beams or slurs my
> highest expecations came up: I thought that I could use this to delegate
> all the complex computation of rendering beam-groups and slurs to the
> typesetting system by just concatenating according glyphs and rendering
> text. However, when I tried this on Android or other technologies (I
> even used MS word), I never got any effect from these combining
> characters. What are these combining characters for? Can you actually
> use combining characters to raise or lower notes, connect flagged notes
> with beams by just putting beam start and beam end arround them, etc.?
>
> 3. Is there anybody interested in my concrete project? Could a simple
> text based music format also be of interest for W3C?
>
> I would be happy about any feedback - even if just a partial answer to
> one of my questions or any link that might be helpful.
>
> p.s.: Just in case anybody here is a Java developer and wants to have a
> look at my code - I am also happy about any kind of feedback.
>
> Kind regards
>    Jörg
>
>
> Product Marketing Manager
> Phone: +44 20 3696 1811
>
> *Steinberg Media Technologies GmbH*
> Beim Strohhause 31, 20097 Hamburg, Germany
>
> President: Andreas Stelling | Managing Directors: Shinichi Takenaga, 
> Jun Nishimura
> Registration Court: Hamburg HR B 86 534 | VAT ID: DE118677139
>
> Visit the Steinberg website <http://www.steinberg.net> or connect with 
> us on Facebook <http://www.facebook.com/Steinberg>, Twitter 
> <http://twitter.com/steinbergmedia>, Instagram 
> <http://www.instagram.com/steinbergmedia> and SoundCloud 
> <http://www.soundcloud.com/steinbergmedia>.
> Watch our Cubase <https://www.youtube.com/cubase>, Dorico 
> <https://www.youtube.com/dorico>, Mobile Apps 
> <https://www.youtube.com/mobile_apps_steinberg>, Nuendo 
> <https://www.youtube.com/nuendo>, Steinberg 
> <https://www.youtube.com/user/SteinbergSoftware>, Audio Interfaces 
> <https://www.youtube.com/audiointerfaces>, VST Instruments & Plug-Ins 
> <https://www.youtube.com/VSTinstrumentsplugins> and WaveLab 
> <https://www.youtube.com/WaveLab> videos on YouTube.
>