- From: Domenico Strazzullo <nst@dotuscomus.com>
- Date: Wed, 3 Nov 2010 10:33:23 +0100
- To: "James Ingram" <j.ingram@netcologne.de>, <www-svg@w3.org>
- Cc: <helder.magalhaes@gmail.com>
Hi James, > I'm an expert in music notation with a background in writing music scores. > Briefly: I was Karlheinz Stockhausen's copyist 1974-2000. Pleased to meet you and glad to have you here! The evoked audio extensions which have been proposed or implemented so far relate to sound in the multimedia sense, i.e. dealing with sound formats as packets to be downloaded and then reproduced with some sort of synchronization. The type of extension you are suggesting relates to music and its reproduction using synthesized sounds and/or samples from the sound card's onboard library, through an interface with the system sound driven by MIDI events described in the XML markup. The difference may not be so evident for the non initiated. If I understand, you are proposing an extension for SVG that would graphically render the score from the information in the markup. If you simply define another XML dialect you will have to provide a transformation engine (I'm not fluent with this) and that would necessarily remain rather confidential, while instead I suspect you would like such extension to be implemented natively. If this is right then this is the right place for such a proposal, as all the implementers have a presence here. Then comes the question of the execution of the score. You say that your Assistant Performer software could easily integrate this new format. Do I read you well if I say that you would like this engine to possibly become a plugin or, better, be implemented natively or taken as a model for the reproduction? I checked Assistant Performer and found that its timing controls, pedal marks, dynamics and sliding dynamics are excellent. I'm not crazy about the interpretation of articulations. Overall it's very convincing. Apart from the natural vocation of interpreting scores, this implemented interface would allow native and active control over music (not to be confused with audio) in all the possible situations where it is commonly used, but also allow aleatory composition -I'm sure you're well used to this ;-) - through scripted (ECMAscript) algorithms, interpreted by the computer, that could be used as incidental music. And more. Lots of real fun. If this is the sense of your proposal and if it encounters some expressed interest from officials at this stage I'll be glad to give you some support. If I've got it all wrong please ignore. Best regards, Domenico Strazzullo ----- Original Message ----- From: "James Ingram" <j.ingram@netcologne.de> To: <www-svg@w3.org> Cc: <helder.magalhaes@gmail.com> Sent: Saturday, October 30, 2010 12:20 PM Subject: Re: SVG and MIDI > Hi Helder, > > Thanks for keeping this thread alive. > > I'm an expert in music notation with a background in writing music scores. > Briefly: I was Karlheinz Stockhausen's copyist 1974-2000. Wrote his > published scores in pen and ink until 1992, thereafter using a combination > of Finale and Freehand. In the 1990s I wrote a group of plug-ins [1] for > Freehand to help me create the complex scores I was being asked to create. > I will be referring to their code when creating my SVG graphics. > > Thanks for pointing me at the animation examples, but I'm not currently > interested in animating the graphics. What interests me is real-time user > interaction with fixed, printable scores. > > In my first post, I said >> I need to include logical information about chord symbols, (such as their >> temporal duration and midi pitches) so that these do not have to be >> deduced >> from the (static 2D) graphics when I read and play the file. > > I should have said _default_ duration not 'temporal duration'. The default > duration can be overridden/ignored by any person or program playing the > score. The default duration is related to the logical width of the symbol, > and that's a value which is used to calculate the actual horizontal > position of the symbols on the staff. The logical width can't be > calculated from the graphics, because its only one of the inputs to the > algorithm which justifies the symbols across the staff. But its a value > which is known to the author of the graphics. :-) > > I've already written an Assistant Performer [2] application which does the > kind of user-interaction I have in mind. This currently reads scores in > CapXML format [3], but when I've created some (extended) SVG it will be > easy to make it read that too. > > Currently I'm developing an Assistant Composer application which will > _write_ (extended) SVG. (I'm also working on a long-overdue update of my > website.) The Assistant Composer uses rather personal algorithms [4], but > I could well imagine that _any_ music authoring program could write the > extended SVG I have in mind. My Assistant Performer could play scores > written by _any_ music authoring program if they exported my (extended) > SVG. > > If there's anyone out there working in this area, I'd be very interested > in cooperating. > > My mind has been exploding since Alex's post yesterday. Discovered that > Inkpen preserves custom markup when reading and saving files... :-)) > > All the best, > James > > [1] > http://james-ingram-act-two.de/stockhausen/stockhausenSoftware.freeHandXtras.html > [2] http://james-ingram-act-two.de/moritz/moritzAssistantPerformer.html > [3] http://www.music-notation.info/de/formats/CapXML.html > [4] http://james-ingram-act-two.de/compositions/study2/aboutStudy2.html > > > > > > > -- > www.james-ingram-act-two.de > >
Received on Wednesday, 3 November 2010 09:34:00 UTC