MakeMusic
SmartMusic Finale Garritan MusicXML

Instrument taxonomy structure - a first proposal

Moderator: Michael Good

Re: Instrument taxonomy structure - a first proposal

Postby Michael Good » Thu Jan 27, 2011 2:21 pm

Hello all,

Thank you for the great feedback so far! I'd like to address the comments that are assuming we want some type of hierarchical representation here, and then address Joe's level suggestion separately.

Andre has some more great points here about both the need for hierarchy and the questions about organizing it. The ability to reason about similarity and substitution is why this draft has three levels in the hierarchy:

- Family
- Instrument
- Key / size

As Dave and Andre suggest, this draft hierarchy is organized around a combination of factors. Playing technique is important, especially for making realistic substitutions. This is why bowed and plucked string instruments are in separate families. It is also why keyboard is in a separate family, independent of sound production technique.

We tried to make something that could map directly to the taxonomies we had available from General MIDI, Sibelius, Finale, capella, and Noteflight. I also did some library research on previous taxonomy approaches independent of software considerations to get more ideas for classification approaches.

Dave, thank you very much for sharing your Mozart instrument taxonomy work! It is indeed food for thought. My main concern is that going to that level of detail will require a lot of additional work for mapping virtual instruments, beyond what people have already had to do for creating related mappings like Sibelius sound sets.

However, some additional levels of detail might well be useful. Should we add additional distinctions between families? Would an extra level in the hierarchy be helpful?

It would be fine to specify the instrument key with separate pitch and accidental elements like Joe suggests. It was not done that way originally to try to communicate that this is an identifier, not a reference to pitch. I can see that this distinction is not sufficiently useful.

Andreas, if we were starting anew, we might indeed want to include the transpose element in the score-instrument element. However, at this point I think it would be best not to move it. Either way should work fine. We only want to make this type of change when the current MusicXML 2.0 definition is not adequate. (The midi-device element is an example where we'll need to make this type of change; a proposal will be coming later.)

For identifying the size of an instrument via its key, I think either a string or a pitch/accidental combination would be easier to use than a transposition value. If others disagree please let me know!

Best regards,

Michael Good Recordare LLC


Am 27.01.2011 um 16:22 schrieb Reinhold Kainhofer:

Reinhold Kainhofer wrote:I also suppose that "strings" does not mean all string instruments, but rather bowed string instruments (as opposed to plucked string instruments).

This leads to the question that needs to be answered foremost, namely whether the taxonomy should distinguish instruments by

- Timbre
- Physical construction
- Role
- ...

Or a combination of all these, as David suggested. A hierarchy can only represent one dimension at a time. Although, multiple small hierarchies can coexist.

Without a hierarchy or network of any kind, it is impossible for a software to do any reasoning about similarity or potential substitution.

Andre
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: Instrument taxonomy structure - a first proposal

Postby Henry Howey » Thu Jan 27, 2011 3:08 pm

Why re-invent the wheel. What about using Sach's already established taxonomy? Especially regarding "world" instruments.


Andre Schnoor wrote:Am 27.01.2011 um 16:22 schrieb Reinhold Kainhofer:

Reinhold Kainhofer wrote:I also suppose that "strings" does not mean all string instruments, but rather bowed string instruments (as opposed to plucked string instruments).

This leads to the question that needs to be answered foremost, namely whether the taxonomy should distinguish instruments by

- Timbre
- Physical construction
- Role
- ...

Or a combination of all these, as David suggested. A hierarchy can only represent one dimension at a time. Although, multiple small hierarchies can coexist.

Without a hierarchy or network of any kind, it is impossible for a software to do any reasoning about similarity or potential substitution.

Andre
Henry Howey
 
Posts: 26
Joined: March, 2014
Reputation: 0

RE: Instrument taxonomy structure - a first proposal

Postby Michael Cuthbert » Thu Jan 27, 2011 3:47 pm

Dear Michael and List,

I think of the need for more robust instrument specifications as a way of specifying the sound that most closely represents the sound of the instrument but that has a list of fallback sounds in case the original sound is not available. In this way, I think the specification of fonts in HTML CSS is the closest analogy. Thus we might allow something like this pseudo-encoding for a 19th century clarinet in D:

<instrument>
<choice>Romantic D Clarinet
<url>http://trecento.com/romantic_d_clarinet.sfont</url></choice>
<choice>D clarinet</choice>
<choice>E-flat clarinet
<vst-instrument>Solo E-flat Clarinet 2</vst-instrument>
</choice>
<choice>E-flat clarinet</choice>
<choice>clarinet</choice>
<choice>woodwind</choice>
<choice>None</choice>
</instrument>

there are 7 different instrumental sounds specified. The first requires that a particular SoundFont be used (other possibilities could be .wav; specific filepaths on the system, a link to a file embedded in the file, etc.). If that is not possible (because URLs are not supported by the software, sound fonts are not supported, or there's no internet access) then the next choice, a built-in D clarinet sound would be used. If that does not exist then it falls back to the Eb clarinet with the second e-flat clarinet sound (for this part, I have no idea how the encoding should look). If that instrument does not exist then it would fall back to any E-flat clarinet sound on the system. If that doesn't work then any clarinet sound would be used followed by any woodwind sound. The "None" specification at the end says that rather than falling back further to a default sound, the instrument should be omitted (you might imagine that for many obscure electronic samples are better omitted than played by a piano).

A standard musicxml taxonomy could be important because it would have a standard set of implications, such as Harmon-muted trumpet implies muted trumpet implies trumpet implies brass. But maybe such a taxonomy isn't necessary (or isn't necessary as part of the .XSD and just have it as a reference file online... maybe even have the most recent draft version as publically editable and only have the stable version be frozen)

One other thing to consider is that the most similar sound for any instrument might not be in the instrumental taxonomy. You might want the *** stop of the organ to belong to the bassoon taxonomy instead of the organ, for instance.
(brings to mind the old joke, a music student runs into the green room just before a concert, "Maestro! Maestro! Help! Come quickly! The oboe player swallowed her reed and is choking to death!" The reply, "Calm down. Don't worry. We'll just use a muted trumpet instead.")

- Michael

--- --- Michael Scott Cuthbert
Assistant Professor of Music, M.I.T.

4-246 Music and Theater Arts +1-413-575-6024 77 Massachusetts Ave. http://www.trecento.com Cambridge, MA 02139


Hello Andre,

You have indeed hit on the crux of the problem. There is a lot of software infrastructure needed to make a taxonomy work well.

One of the reasons we are doing this project now, and not three years ago with MusicXML 2.0, is that more of this software is in place. Sibelius does some of what you are asking for using their SoundWorld technology. You do have to create
a sound set for Sibelius to do this, but there are many sound sets built-in, and others are available from third parties.

Steinberg is also doing interesting things in this area with VST Expressions and
VST Expressions 2. This applies more to playback techniques than the instrument
taxonomy. However it is another example of the development going on in trying to create higher-level, notation-friendly representations for playback.

At a lower level is the "MIDI Names, Device Types, and Events in XML" specification from the MIDI Manufacturers Association
(http://www.midi.org/dtds/midi_xml.php). This is used in Mac OS X as well as other software.

What we want to do in MusicXML 3.0 is leverage these efforts as much as possible. For instance, Sibelius default sound IDs are accessible to ManuScript plug-ins. We want to make the mapping of Sibelius sound IDs to MusicXML instruments straightforward enough to export the MusicXML instruments in our Dolet plug-in.

The general interest in this type of taxonomy is one reason why we had a very busy schedule at NAMM this year! We cannot solve all these problems in MusicXML 3.0 itself. What we want to do is provide a solid taxonomy *and* some successful
initial implementations. We need those initial implementations both to make sure the taxonomy is technically solid, and to generate interest for creating the general-purpose tools that provide more comprehensive interchange.

Best regards,

Michael Good Recordare LLC


Hello Michael,

in my software I am using an instrument taxonomy too. The design goal was to ensure that a saved project can be loaded at any other studio and then the software would be able to search for matching sounds available there.

This works exactly as intended, but the bottleneck with this approach is that countless plugins and sound libraries need to be categorized in advance (way to many for a small entity to cope with). This is what most users like to avoid.

I wish there was a standard format/representation for sound meta data, that could be aggregated in a collaborative effort, perhaps maintained in an online database:

- Instrument category (taxonomy)
- Playing range (limits)
- Articulations (key switches, for the most part)
- Controllers
- Response curves

This information would certainly be useful for a lot of software. Eventually the
vendors of new libraries could will supply their products with meta data, provided there is enough demand for it.

Imagine a DAW that non-destructively changes dynamics, transposition and CC/KS of midi regions automatically when the target sound is switched. Orchestral parts that make heavy use of articulations and CCs will still work across multiple sound libraries (at least at a "draft" level of quality).

Some of the meta data could even be derived from the sounds automatically by means of an audio analysis plugin.

To summarize: The lack of meta data for sound generators is a real problem. Without it, the user would have to stay with making instrument assignments manually.

Andre
Michael Cuthbert
 
Posts: 70
Joined: March, 2014
Reputation: 0

RE: Instrument taxonomy structure - a first proposal

Postby Michael Good » Thu Jan 27, 2011 3:56 pm

Hi Henry,

Thank you for your comments. The Hornbostel-Sachs taxonomy is certainly one we are considering for the MusicXML 3.0 taxonomy design. For those who haven't seen it, Wikipedia has information about it at:

http://en.wikipedia.org/wiki/Hornbostel-Sachs

However, being initially published almost 100 years ago, this taxonomy was developed long before we had computerized notation software. So it is not optimized for the purposes we have in mind for MusicXML 3.0.

No taxonomy is developed in a vacuum. What you choose to make primary depends on your perspective and intended uses. Emphasizing the source of initial sound production makes terrific sense for ethnomusicology. It is perhaps not ideal for composers, performers, and MIDI software developers.

I could well be mistaken about this. I would be very interested to see examples of music software - especially software for notation or performance - that uses the Hornbostel-Sachs system for instrument classification.

We are not trying to reinvent the wheel. Rather, we are trying to use several different wheels - Hornbostel-Sachs, General MIDI, Sibelius SoundWorld, and more
- to help build a better vehicle for moving digital sheet music between applications.

Best regards,

Michael Good Recordare LLC


Why re-invent the wheel. What about using Sach's already established taxonomy? Especially regarding "world" instruments.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

RE: Instrument taxonomy structure - a first proposal

Postby Michael Good » Thu Jan 27, 2011 4:28 pm

Hi Joe and Michael,

You both raise very interesting points about not building the taxonomy directly into the MusicXML format, but instead taking a more descriptive approach.

The initial proposal built families and instruments into the format because of the persistent calls we have had over the years to allow interchange to be as automated as possible. With the DTD we often took the approach of element values having standard but extensible values. In the XSD, these are often replaced by enumerations that enhance automated quality analysis checking.

For years, people have asked us for a way that they don't have to interpret that
"Tromba" or "Trumpet" or "Trp" part names all refer to a trumpet as the instrument. If we omit standard taxonomies with enumerations, don't we go back to the situation we have now? Where software has to infer the instrument from an arbitrary string, or from an instrument definition (General MIDI then, maybe a VST patch name now)?

I agree that we must somehow build extensibility into the taxonomy. That is why each family has an other- element to handle instruments we miss. We could add an other- element at the family level as well. This is similar to how extensibility is handled for other MusicXML elements.

Joe, could you explain a bit more about why you think the proposed system may be too rigid and awkward? Is there a way that we could make it less brittle, but still make it easier to do automatic checking and mapping?

Are you perhaps thinking of something along the lines of Michael's proposal for a reference file separate from the main XSD / DTD? If so, how might that reference file work for allowing automatic validation when desired?

Michael, thank you for proposing that CSS-like approach. I will have to think about this some more in terms of how that would fit in with current software while making things more future-proof. I could see that working with either a standard taxonomy - allowing choices to cross between families - or with a more descriptive approach.

Thanks again for these very thoughtful suggestions!

Best regards,

Michael Good Recordare LLC


Hi Michael,

Thanks for offering this. I want to think about the taxonomy structure a little more before responding to it, but I have a couple of other thoughts:

- I think it would be best not to burn any instrument taxonomy into the MusicXML schema, but to use a simple list of taxonomic levels, e.g.:

<score-instrument>
<instrument-name>...</instrument-name>
<instrument-type>
<instrument-taxon>brass</instrument-taxon>
<instrument-taxon>standard</instrument-taxon>
<instrument-taxon>trumpet</instrument-taxon>
</instrument-type>
<!-- etc... -->

I think that baking the standard instruments directly into the schema will make the system too rigid, and also is more awkward to generate and parse. The taxonomy is best defined out-of-band from the MusicXML schema, both the standard and the non-standard bits. The schema should merely describe how an instrument's taxonomic levels are to be embedded in the document.

- For regularity I would like the definition of instrument key to use the same approach to notes as other elements of the spec like regular notes, harmony root notes, and so forth: a note name plus an alteration.

...Joe
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: Instrument taxonomy structure - a first proposal

Postby Henry Howey » Thu Jan 27, 2011 4:37 pm

Sorry to sound cute. As I follow the discussion, I am continually amazed at the varieties of music that has been proposed. The Hornbostel-Sachs taxonomy seemed a useful primary system to enclose non-Western musical instruments. Further, its delineation among types of percussion instruments may provide a means of continuous upgrading. The suggestions so far have an occidental bias that is self-limiting.


Michael Good wrote:Hi Henry,

Thank you for your comments. The Hornbostel-Sachs taxonomy is certainly one we are considering for the MusicXML 3.0 taxonomy design. For those who haven't seen it, Wikipedia has information about it at:

http://en.wikipedia.org/wiki/Hornbostel-Sachs

However, being initially published almost 100 years ago, this taxonomy was developed long before we had computerized notation software. So it is not optimized for the purposes we have in mind for MusicXML 3.0.

No taxonomy is developed in a vacuum. What you choose to make primary depends on your perspective and intended uses. Emphasizing the source of initial sound production makes terrific sense for ethnomusicology. It is perhaps not ideal for composers, performers, and MIDI software developers.

I could well be mistaken about this. I would be very interested to see examples of music software - especially software for notation or performance - that uses the Hornbostel-Sachs system for instrument classification.

We are not trying to reinvent the wheel. Rather, we are trying to use several different wheels - Hornbostel-Sachs, General MIDI, Sibelius SoundWorld, and more
- to help build a better vehicle for moving digital sheet music between applications.

Best regards,

Michael Good Recordare LLC


Why re-invent the wheel. What about using Sach's already established taxonomy? Especially regarding "world" instruments.
Henry Howey
 
Posts: 26
Joined: March, 2014
Reputation: 0

Re: Instrument taxonomy structure - a first proposal

Postby Andre Schnoor » Fri Jan 28, 2011 12:42 pm

Am 27.01.2011 um 20:36 schrieb Michael Good:

Michael Good wrote:However it is another example of the development going on in trying to create higher-level, notation-friendly representations for playback.

Not only for notation purposes. I for one am highly interested in using the meta information for automated composition. A "virtual player" needs to know a lot about an instrument in order to compose parts that make sense.

IMO very important is a standard vocabulary for articulations
(http://www.synfire.com/node/1446). I will certainly have a closer look at the MusicXML definitions to make ours as exchangeable as possible.

Michael Good wrote:At a lower level is the "MIDI Names, Device Types, and Events in XML" specification from the MIDI Manufacturers Association
(http://www.midi.org/dtds/midi_xml.php). This is used in Mac OS X as well as other software.

Yes. I am already making use of these.

Michael Good wrote:We need those initial implementations both to make sure the taxonomy is technically solid, and to generate interest for creating the general-purpose tools that provide more comprehensive interchange.

Good move. I think this is a viable strategy.

Andre
Andre Schnoor
 
Posts: 51
Joined: March, 2014
Reputation: 0

Re: Instrument taxonomy structure - a first proposal

Postby Hartmut Lemmel » Sun Jan 30, 2011 1:01 pm

Hello Michael and everybody,

I didn't follow the whole discussion, I just want to draw your attention to the taxonomy I developed for capella-software a year ago. The purpose of our capella genericSound IDs is to find substitute sounds for playback if a certain sound is not available.

First I looked at the *Hornbostel Sachs* system and concluded that
+ it is very comprehensive
- the numerical codes are not directly understandable by readers
- is is very theoretic
-- it is based more on the construction of an instrument than on the sound. As a consequence, guitar and violin are closer related than guitar and mandolin. Piano and cymbal are more or less the same.

Then I looked at *Sibelius*.
+ text instead of numerical IDs
- no distiction between instrument and articulations
-- The system is not strictly based on the sound. For example I don't see the need of the clear distinction between pitched and unpitched percussion. Looking at real instruments there is no clear distinction but rather a continuous transition. Why should the bass drum (unpitched.drum.very low.bass drum) be closer to the triangle (unpitched.metal.bells.high.triangle) than to the timpani (pitched percussion.drum.timpani)? Furthermore the whole root classification "keyboard" has nothing to do with sound. If you want an accordion (keyboard.organ.reed.accordion) and your sound library offers a celesta (keyboard.celesta) and a harmonica (wind.harmonica) the celesta will be chosen to substitute the accordion while the harmonica would be much more adequate. The group "keyboard" might be useful in a menu, where the user wants to find a certain instrument. But that's a different task.

Thus I developed a new taxonomy for capella. In the above examples, the
*capella genericSound IDs* would be:
accordion = wind.lamella.accordion
harmonica = wind.lamella.harmonica
celesta = percussion.metal.celesta
triangle = percussion.metal.triangle
timpani = percussion.drum.timpani
bass drum = percussion.drum.drum.bass

The complete list of root and second level nodes is:
voice
wind.wood
.brass
.lamella
.organ
bow.string
.other
pluck.harp
.zither
.guitar
.lamella
hammer.piano
.clavichord
.dulcimer
percussion.wood
.metal
.bell
.cymbal
.rattle
.ratchet
.drum
.effect
mixed

The ID string defining the instrument can be followed by attributes (separated by ':') and articulations (separated by '+'), e.g.
bow.string.violin:group:soprano+sordino+pizzicato

The attributes distinguish ensemble sound (':group') and solo sound (without
':group') as well as the voice pitch (':piccolo', ':soprano', ':mezzo',
':alto', ':tenor', ':baritone', ':bass', ':contra') which also helps in finding substitutes. The pitch (e.g. of a triangle) can be specified by ':' followed by the MIDI pitch number.

You find the complete list of the capella genericSound IDs (defined so far) at the end of the following document:
http://lemmel.at/captune-VST-config.pdf

In principle we would be very interested to find a common taxonomy used also by the sound providers. Now we are more or less bound to our own system for compatibility reasons, but if the common standard is not too far away we could adapt it.

Best wishes, Hartmut (capella-software)
Hartmut Lemmel
 
Posts: 6
Joined: March, 2014
Reputation: 0

Re: Instrument taxonomy structure - a first proposal

Postby Henry Howey » Sun Jan 30, 2011 1:18 pm

This is very well thought out. I only mentioned Hornbostel-Sachs in light of the concern about non-Western musics. Also, this needs to be an "open" system for it to grow. I guess I need to add Garritan's new soundset for experimentation.


Hartmut Lemmel wrote:Hello Michael and everybody,

I didn't follow the whole discussion, I just want to draw your attention to the taxonomy I developed for capella-software a year ago. The purpose of our capella genericSound IDs is to find substitute sounds for playback if a certain sound is not available.

First I looked at the *Hornbostel Sachs* system and concluded that
+ it is very comprehensive
- the numerical codes are not directly understandable by readers
- is is very theoretic
-- it is based more on the construction of an instrument than on the sound. As a consequence, guitar and violin are closer related than guitar and mandolin. Piano and cymbal are more or less the same.

Then I looked at *Sibelius*.
+ text instead of numerical IDs
- no distiction between instrument and articulations
-- The system is not strictly based on the sound. For example I don't see the need of the clear distinction between pitched and unpitched percussion. Looking at real instruments there is no clear distinction but rather a continuous transition. Why should the bass drum (unpitched.drum.very low.bass drum) be closer to the triangle

(unpitched.metal.bells.high.triangle) than to the timpani (pitched percussion.drum.timpani)?
Hartmut Lemmel wrote:Furthermore the whole root classification "keyboard" has nothing to do with sound. If you want an accordion (keyboard.organ.reed.accordion) and your sound library offers a celesta (keyboard.celesta) and a harmonica (wind.harmonica) the celesta will be chosen to substitute the accordion while the harmonica would be much more adequate. The group "keyboard" might be useful in a menu, where the user wants to find a certain instrument. But that's a different task.

Thus I developed a new taxonomy for capella. In the above examples, the *capella genericSound IDs* would be: accordion = wind.lamella.accordion harmonica = wind.lamella.harmonica celesta = percussion.metal.celesta triangle = percussion.metal.triangle timpani = percussion.drum.timpani bass drum = percussion.drum.drum.bass

The complete list of root and second level nodes is: voice wind.wood
.brass
.lamella
.organ bow.string
.other pluck.harp
.zither
.guitar
.lamella hammer.piano
.clavichord
.dulcimer percussion.wood
.metal
.bell
.cymbal
.rattle
.ratchet
.drum
.effect mixed

The ID string defining the instrument can be followed by attributes (separated by

':') and articulations (separated by '+'), e.g.
Hartmut Lemmel wrote:bow.string.violin:group:soprano+sordino+pizzicato

The attributes distinguish ensemble sound (':group') and solo sound (without

':group') as well as the voice pitch (':piccolo', ':soprano', ':mezzo', ':alto',
':tenor', ':baritone', ':bass', ':contra') which also helps in finding substitutes. The pitch (e.g. of a triangle) can be specified by ':' followed by the MIDI pitch number.
Hartmut Lemmel wrote:You find the complete list of the capella genericSound IDs (defined so far) at the end of the following document:
http://lemmel.at/captune-VST-config.pdf

In principle we would be very interested to find a common taxonomy used also by the sound providers. Now we are more or less bound to our own system for compatibility reasons, but if the common standard is not too far away we could adapt it.

Best wishes, Hartmut (capella-software)
Henry Howey
 
Posts: 26
Joined: March, 2014
Reputation: 0

RE: Instrument taxonomy structure - a first proposal

Postby Michael Good » Mon Jan 31, 2011 2:07 pm

Thank you to everyone for the great discussion and suggestions so far! Thanks especially to Daniel and Hartmut for sharing your instrument taxonomy work.

I think there have been several great points raised here:

1) Daniel's point that the Sibelius taxonomy covers instrument *sounds* rather than instrument themselves is something I think we should adopt for MusicXML 3.0. This would address part of Michael's issue about the most similar sounds crossing instrument families.

2) The Sibelius and capella taxonomies are both rightfully concerned with finding similar sounds for playback if the original instrument is missing. I am not sure this is something we want or need to directly address in MusicXML 3.0. It may be best for applications to use their own interpretation of most similar sounds. However, the sound that is the starting point should be clearly identifiable from the MusicXML file, and easy to map into an application's own taxonomy. If the MusicXML taxonomy can support sound similarity, so much the better, but the primary task is cross-application sound identification.

3) Hartmut raises the point that the SoundWorld taxonomy does not distinguish between instruments and articulations (or, more generally, playback techniques). This is a concern for MusicXML as well. To best integrate into the MusicXML design, it seems we need to separate sound identification into several areas:

- The sound associated with an instrument can be added to the score-instrument element.
- The distinction between a solo instrument sound and an ensemble sound is already represented in MusicXML 2.0 with the solo and ensemble elements. It seems it would be best for our sound identifiers not to duplicate this.
- Playback techniques and articulations can be added to the sound element. It might be desirable for an initial technique setting to be included in the score-instrument element as well. I know this area is of special concern to Andre. We have not discussed it too much yet, but we will soon.

If we do this right, I think we should be able to cleanly map from the MusicXML representation to existing representations in applications like Sibelius and capella, even if the MusicXML representation is split across several different elements vs. one or two strings.

The capella representation seems to map more closely to the existing MusicXML design. The attributes introduced by the : sign correspond to the existing solo/ensemble element and (more roughly) to the proposed instrument-key element, which could be generalized to instrument-size or instrument-attributes. The articulations introduced by the + sign generally correspond to changes in the sound element.

This leads to some fundamental questions about how to represent instrument sound identifications in MusicXML. I will send those questions in a separate email.

Thanks for all the great contributions so far - please keep them coming!

Best regards,

Michael Good Recordare LLC
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

PreviousNext

Who is online

Users browsing this forum: No registered users and 2 guests