Re: SVG and MIDI

Hi Domenico,

Thanks for the welcome! :-)

Following Helder's suggestion, I joined the svg developers group at [1] 
yesterday, and sent my latest contribution there.

However, in reply to your post:

> 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.
Yes.
> If I understand, you are proposing an extension for SVG that would
> graphically render the score from the information in the markup. 
That does not require an extension to SVG. I need extensions describing 
the *meaning* of the graphics (time and MIDI).
(I'm developing these ideas as we go along, so the following is an 
updated version of my post to the svg developers group yesterday.)

I was thinking of defining <g> sub-types like these:
     mus:type="system"
     mus:type="staff"
     mus:type="chord"
     mus:type="rest"
     mus:type="barline"
     etc.
And
     mus:msPos (int)
     mus:msDefaultDuration (int)
     mus:staffName (string)
     mus:midiChannel (int)
     mus:midiPitches (list of ints)

The *system* mus:msPos would be the default number of milliseconds from 
the beginning of the performance.
The *chord* and *rest* mus:msPos would be the default number of 
milliseconds from the beginning of the system.
The *mus:msDefaultDuration* would only be applicable to chords (think 
Mozart staccato).

For example:

<svg ...  xmlns:mus="http://www.james-ingram-act-two/Moritz/svgTypes" ... >
<!-- there will be a sequence of systems in the page -->
<g mus:type="system" mus:msPos="0">
<!-- a sequence of staffs in the system -->
<g mus:type="staff" mus:staffName="Flute" mus:midiChannel="0">

<!-- a sequence of clefs, barlines, rests, chords etc -->

<g mus:type="rest" mus:msPos="0" >
<!-- the rest text character -->
<g mus:type="drawObjects">
<!-- objects associated with the rest -->
</g>
</g> <!-- end of rest -->

<g mus:type="barline">
<!-- the barline line -->
<g mus:type="drawObjects">
<!-- objects associated with the barline -->
</g>
</g> <!-- end of barline -->

<g mus:type="chord" 
mus:msPos="1348"mus:msDefaultDuration="1000"mus:midiPitches="64 67 83 90">
<!-- graphics for the chord symbol -->
<g mus:type="drawObjects">
<!-- control texts and other objects associated with the chord-->
<!-- The control texts can be parsed for things like dynamics
                      or patch changes ->
</g>
</g> <!-- end of chord -->

<!-- etc. more chords, rests, barlines etc. -->

</g> <!-- end of staff -->
<!-- more staves -->
</g> <!-- end of system -->
<!-- more systems -->
</svg>

This has the interesting side effect that there does not have to be a 
rest or chord at the start of every staff. That's very useful, because 
notations should not have to insist on having tied notes where durations 
cross systems. We are not restricted to standard notation. :-) There 
probably has to be a special typemus:tiedChord for chord symbols which 
are continuations.
A mus:chord is where MIDI noteOns get sent...
> 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.
It would of course be very helpful if all score authoring programs could 
export these extensions in a standard way.
> Then comes the question of the execution of the score. You say that your
> Assistant Performer software could easily integrate this new format. 
My Assistant Performer first analyses the information in a (CapXML) 
score to create a "MIDIScore" consisting of all the MIDI messages 
waiting to be played. All the live performer does is trigger those 
messages in real-time. If the original file was not CapXML but extended 
SVG, it would be much easier to construct the MIDIScore.

> 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?
At the moment, its primarily a proof-of-concept - a prototype. It would 
be very nice to make a browser plug-in, or even implement it natively in 
browsers... But doing that would require a team of experienced 
programmers. I'd very much like to be part of such a project.

> 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.
Thanks! Yes, I'm not too happy about the articulations either. Maybe its 
me, maybe its MIDI. :-)

> 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.
Quite! :-))

Another thing I'm developing is the notation itself.
Having a format in which the logical and graphical information is 
clearly separate, means that non-standard notations can be implemented. 
(A chord with mus:midiPitches="64 72 93" could be notated with a single 
red notehead or in any other way...)
And there are situations where it would be preferable to use a 
simplified notation which can easily be generated automatically from an 
audio file. (see [3]). (This is very difficult to do using full 
19th-century notation.)
I can well imagine adding such simple "event-oriented" notations to 
today's post-production software (Cubase, Protools, Ableton etc.). At 
present, the best they have is old-fashioned, analogue, space-time 
notation [4]...
> 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.
Thanks very much! I think you got it (mostly) right. :-)

All the best,
James

[1] http://tech.groups.yahoo.com/group/svg-developers/
[2] http://en.wikipedia.org/wiki/The_ascent_of_man
[3] 
http://james-ingram-act-two.de/writings/DevelopingTraditions/sonalAtoms/sonalAtomsPreface.html
[4] 
http://eastsidetransfers.com/a-liverecording/images/Cubase%20screen%20shot%20large.jpg

Received on Wednesday, 3 November 2010 12:29:44 UTC