W3C home > Mailing lists > Public > www-svg@w3.org > November 2010

Re: SVG and MIDI

From: Domenico Strazzullo <nst@dotuscomus.com>
Date: Wed, 3 Nov 2010 10:33:23 +0100
Message-ID: <65D05A40C2B3426790B6FB42AFAB59CD@RAPAX>
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 

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:29 UTC