W3C home > Mailing lists > Public > www-svg@w3.org > February 2011

Re: SVG and MIDI

From: James Ingram <j.ingram@netcologne.de>
Date: Sun, 27 Feb 2011 13:39:39 +0100
Message-ID: <4D6A460B.2020208@netcologne.de>
To: www-svg@w3.org
Hi,

Continuing the thread I started here last November, I'd like to say that 
I've now completed two experimental scores (Studies 2b2 and 2b3)  and 
uploaded them to [1] and [2]. These scores are written in SVG, and 
include identical timing and MIDI information in a special namespace 
(summarized in [3]).

I'm writing again now, because I think that some aspects of this 
could/should be worked into the SVG standard. (My speciality is music 
notation, not SVG or MIDI, so there's likely to be room for improvement 
in the way I've done some of this...)

There are two levels at which I think the SVG standard needs to be 
extended for writing scores:
1. There should be some way to synchronize non-animated SVG elements 
with timing information inside things like MIDI recordings, wavs, mp3s 
or videos. Maybe there is already some way to do this, but I have been 
unable to find it.
2. There should be a standard way to include MIDI information in music 
scores written in SVG.

[4] and [5] explain some of the background to this project, and where I 
think it ought to go next.
There's a summary below (not easy, its a big subject).

I'm a bit between stools here. It would be great to cooperate with 
people who know more about SVG and MIDI than I do.
It would also be a good idea for the manufacturers of standard music 
notation editors to be involved.
Anyone interested?

All the best,
James Ingram


[1] 
http://james-ingram-act-two.de/compositions/study2/study2b/study2b2.html
[2] 
http://james-ingram-act-two.de/compositions/study2/study2b/study2b3.html
[3] http://james-ingram-act-two.de/svgScoreExtensions.html

[4] http://james-ingram-act-two.de/compositions/study2/aboutStudy2.html
[5] 
http://james-ingram-act-two.de/compositions/study2/study2b/aboutStudy2b.html 


Summary of [4] and [5]:
Neither [1] nor [2] "adds-up" conventionally at the symbol level, even 
though [2] looks at first sight like standard music notation. These 
scores add up at the millisecond level written inside the files. Client 
software can use the temporal and/or MIDI information, and link to the 
symbols, without having to read the details of the graphics.
This means that:
1.  _Any_ graphics can be included in such a format. Even standard 
notation. Any program that can print music, could fairly easily write 
the SVG code, optionally including the extra temporal and MIDI info.
2. Even if the MIDI info is omitted, the timings attached to the symbols 
could be used to synchronize the graphics with recordings of any kind. 
Playing a symbol by clicking on it would be very easy. Useful if you 
happen to be learning Chinese. Synchronizing a score or written text 
with a video ought to be just as easy.
3. The format can also be thought of as a kind of 2-dimensional, 
high-level MIDI file.

A W3C standardization effort could begin with the container hierarchy:
     (page->)system->staff->voice->chord
These should, I think, be standard names. They define a way of wrapping 
parallel time axes into 2-d space, but do not mean anything beyond the 
fact that these objects nest. A "staff" could be drawn vertically as far 
as I'm concerned.

Standards also need to be agreed for the MIDI information (both the 
names themselves, and their arguments) so that the files become 
interoperable. There is probably a lot more MIDI information (than I've 
used in these Studies) that could be included in such a standard.

Apart from MIDI, chords might also be allowed to contain other kinds of 
information. Corresponding graphics could then be developed to make that 
information optimally accessible to human readers (in the way that those 
who can read standard music notation have optimal access to the MIDI 
info). This could be useful in the user interfaces of any kind of 
program doing multi-processing, scheduling.

ji
Received on Sunday, 27 February 2011 12:40:20 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:47 GMT