music notation at blog.humaneguitarist.org

Archive for the ‘music notation’ Category

a follow up to my MuseScore and LilyPond musings from the previous post

Just a quick follow up to the last post about MuseScore, LilyPond, and my desire to get LilyPond output without entering the music natively as LilyPond syntax.

After some minor tests, it looks like the LilyPond output from MuseScore is far more workable than using "musicXML2ly.py", which comes with LilyPond.

… but it does need some minor clean up, etc.

I'm working on writing four pieces for solo guitar and below I have a snippet from the first piece. Note that I haven't entered fingerings, dynamics, etc. yet. If fact, the two fingerings and the "Adagio" used below are just there to see if they got outputted to LilyPond via MuseScore.

There are three snippets below. The first is the native MuseScore PDF output, followed by MuseScore's LilyPond output, then by MuseScore's LilyPond output after I did some processing on the ".ly" file with a Python script I wrote specifically for this piece. The Python script removes the numbering of every measure and also re-establishes the beaming in voice two which got lost from the direct MuseScore-to-LilyPond output. I probably will also have the script remove the parenthetical metronome marking that is being added to the LilyPond output.

MuseScore and LilyPond snippets

The Python script is also included below for demonstrative purposes. I'll probably work out a way to make the script configurable so that I can re-use the same script to process the other pieces but have a config file per piece that allows for customization.

import re

######################################
##### PART 1: comment out lines. #####
######################################

# comments out a line;
# the argument needs to be the start of a line but not all of it.
def lily_comment(line):
  commented = "%" + line
  return commented

# establish LilyPond file to process.
lily_via_mscore = "No_1c.ly"

# open LilyLond file; read it.
f = open(lily_via_mscore, "r")
new_lily = f.read()
f.close()

# place beginning of lines to comment out in array.
bads = ['\override Score.BarNumber'] # prevent numbering every measure.

# comment out bad lines.
for bad in bads:
  new_lily = new_lily.replace(bad, lily_comment(bad))

#####################################################
##### PART 2: beam all eighth notes in voice 2. #####
#####################################################

# make beams via regex.
output = ""
for line in new_lily.split("\n"):
  m = re.match(r"(.*)~ (<.*>)", line) #ex. changes this: "r8 d~ <d fis> r" to this: "r8 d~ [<d fis>] r".
  if m:
    beams = m.group(2)
    line = line.replace(beams, "[" + beams + "]")
  output = output + line + "\n"

# overwrite LilyPond file with revised version.
f = open(lily_via_mscore, "w")
f.write(output)
f.close()

# fin.

--------------

music notation frustrations and what’s on my programming plate

leave a comment

I haven't been blogging as much lately it seems.

But I probably will be doing more soon as I'm wrapping up a new version of PubMed2XL. And that will also entail updating the documentation and even the video demo/tutorial I have on Vimeo.

I've also been preoccupied with a recent change of apartment and some other stuff, so here's a little on what I'm doing musically and in terms of software projects.

… not that anyone's really reading or cares.

Musically, I've mostly got these four solo guitar pieces I started working on last September entered into MuseScore. I can breath a sigh of relief now that the notes and durations are in and there's no pressure to keep them memorized or rely on snippets of hand-written manuscript. The busy work of adding fingerings, worrying about beaming, etc. remains … as does deciding what I'm going to use to print the music.

I just don't dig the MuseScore output even though it uses the same Feta font as does Lilypond.

Of course, Lilypond is the best output (or at least the best free output) out there. But from day one, I didn't want to enter the music in as Lilypond. I think Lilypond's entry format breaks down after notes and durations start to get entered. It starts to feel like the cryptic markup that, well, it is once fingerings and beamings become cosiderations. Been there, done that.

MuseScore's Lilypond export is really much better than in the early days of MuseScore, but it does some weird things like numbering all the measures so I'd have to write a post-processing script to clean up the Lilypond file after the MuseScore export. Nicely, MuseScore has command line options so I could automate the process of MuseScore -> Lilypond -> post processing -> PDF.

But I'm not sure that's a good solution going forward.

I think – if I remember – that the "musicxml2ly" Python script that comes with Lilypond has a better output. So I might use that in my workflow.

The output from Noteflight is damn good, BTW. It looks like Lilypond but I don't think Noteflight really supports guitar fingerings based on what I've seen through casual investigation.

Anyway, I think my solution involves MuseScore for entry, musicxml2ly.py, and Lilypond. Maybe even a little GIMP to make the output look a little weathered, like a grainy film. I dunno, probably not.

OK, and as to what I'm doing software-wise after I finish PubMed2XL 2.0 …

First, I have to create a webpage for a guitarist/luthier friend of mine to do fret calculations using a particular formula.

That involves the challenge of making it look professional since it'll reflect on him and not just me. I was able to make what I think is a pretty nice looking logo/look using Inkscape. Actually, I used Inkscape to make a logo for PubMed2XL, too.

I'm also going to use the project as a way to finally do some responsive design and also incorporate a JavaScript ~MVC framework. I think KnockoutJS is the one I'm going with. I've already written the PHP/JSON API that does the fret calculations. Yes, there will be an API for luthiers! Could be nice to use in conjunction with Google Chart Tools or something to visualize fret distances …

Anyway, so after that I need to work out a demo for a secure "eBook" reader as I mentioned in a previous post. It should be a soup-to-nuts way to securely deliver ePub and HTML/CSS/JavaScript pages through a desktop application (i.e. a WebKit browser stripped of the ability to save pages) using MySQL, PHP, Python, and password protected ZIP files.

And then, I'd like to explore music notation entry using the Android voice recognition features. That's to say, instead of singing the melody, I would say something like basic Lilypond syntax into my phone a la "C4 D8 E F4 G", etc. and have the application save that to my Dropbox account and/or send it to a Lilypond API and render it as an image, or something. I'm not too sure yet. I just know that I loathe notation entry with a mouse/keyboard. And, no, I'm not buying a MIDI keyboard.

I think there was something else, too. But I can't remember.

Oh well, it probably wasn't that important to me if I forgot.

…

Update, a few hours later: OK. It was something that might be very important to me … and that's some project built around using the IMLSP API to retrieve scores. Not too sure yet as I'd have to explore the API some more.

Anyway, I guess this post is going to serve as my project portfolio for several, several months.

--------------

museline: trying to add support for compressed MusicXML

4 comments

Just a quick follow up to the last post about using Google Chart Tools to outline melodic contours from MusicXML files …

I wanted to add support for compressed MusicXML files in addition to the non-compressed ones. So far, the code I've got seems to be working with the two or three compressed MusicXML files from Wikifonia I tested.

Here's a screenshot below of A-Ha's "Take On Me", one of the best songs from the 80's with one of the absolute best videos, too! To make the graph I passed it to the app a la "http://localhost:8083/?mxml=http://static.wikifonia.org/1934/musicxml.mxl".

Here's the video:

Keep in mind the contour script doesn't take repeats into account and that the entire melody repeats three times in the song.

Also, I don't like to make code downloadable if I'm still working on it because I don't want to junk up my web directory, but I'll paste everything essential below: the Google App Engine YAML file, the Python code, and the Jinja/HTML template.

YAML:

application: museline
version: 1
runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /stylesheets
  static_dir: stylesheets
- url: /.*
  script: museline.app
 
libraries:
- name: jinja2
  version: latest
- name: lxml
  version: latest

Python:

### museline.py
### 2012, Nitin Arora

### import modules
import urllib
from lxml import etree
import math
import re
import webapp2
import jinja2
import os
     
jinja_environment = jinja2.Environment(
  loader=jinja2.FileSystemLoader(os.path.dirname(__file__)))
  
#####
class museline(webapp2.RequestHandler):
  def get(self):
    
    ### read MusicXML file
    try:
      url = self.request.get('mxml')
##      url = 'http://blog.humaneguitarist.org/uploads/i_heart_thee.xml' #test line
      if url[-4:] == '.xml': # uncompressed MusicXML
        readUrl = urllib.urlopen(url).read()
        
      else: # compressed MusicXML
      ### References:
        # http://stackoverflow.com/a/8858735
        # http://stackoverflow.com/questions/1313845/if-i-have-the-contents-of-a-zipfile-in-a-python-string-can-i-decompress-it-with
        from cStringIO import StringIO
        compressed = urllib.urlopen(url)
        compressedString = StringIO(compressed.read())
        import zipfile
        zipped = zipfile.ZipFile(compressedString, "r")

        archiveFiles = zipped.namelist()
##        self.response.out.write(archiveFiles) # test line
        for archiveFile in archiveFiles:
          if archiveFile[-4:] == ".xml" and "/" not in archiveFile:
            realXML = archiveFile
        extracted = zipped.open(realXML,'r')
        readUrl = extracted.read()

##      self.response.out.write(readUrl) # test line
                
    except:
      errorMessage = '''<pre>
You must pass an "mxml" parameter.
If you have but still see this message, then there is a problem accessing/reading the MusicXML file.
</pre>'''
      self.response.out.write(errorMessage)
      return

    ### setup pitch values
    notes = ['C','D','E','F','G','A','B']
    i = 0
    noteVals = {}
    for note in notes:
      if note == 'C' or note == 'F':
        noteVals[note] = i + 1
        i = i + 1
      else:
        noteVals[note] = i + 2
        i = i + 2

    ### parse MusicXML file
    parsed = etree.XML(readUrl)

    ### get basic descriptive metadata
    metadata = []
    elementList = ['work-title',
                   'work-number',
                   'movement-number',
                   'movement-title',
                   'creator[@type="composer"]',
                   'creator[@type="lyricist"]']
    for element in elementList:
      xpath = str(".//%s") %element
      if parsed.find(xpath) !=None:
        found = parsed.find(xpath).text
        att = re.match(r'(.*)type="(.*)\"', element)
        if att:
          element = att.group(2)
        if found:
          metadata.append((element,found))
##    self.response.out.write(metadata) # test line

    ### access part one tree                       
    part = parsed.find('.//part[@id="P1"]')
    pitches = part.findall('.//pitch')
##    self.response.out.write(str(len(pitches)) + " pitches.\n") # test line, number of notes (non-rests)
##    self.response.out.write(str(len(pitches)*.618) + " Golden Ratio.\n") # test line, maybe something for the future.

    ### put pitch values in a list
    pitchList = []
    i = 1
    for pitch in pitches:
      if pitch.find('.//alter') != None:
        alter = int(pitch.find('.//alter').text)
      else:
        alter = 0
      step = pitch.find('.//step')
      octave = int(pitch.find('.//octave').text)
      pitchPos = str('pitch: ' + str(i))
      pitchClassVal = ((int(noteVals[step.text]) + alter)) * .01
      pitchVal = ((int(noteVals[step.text]) + alter) + (octave * 12)) * .01
      label = (pitchPos, pitchVal, pitchClassVal)
      pitchList.append(label)
      i = i + 1

##    for pitch in pitchList: # test block
##      self.response.out.write(str(pitch)+'<br>')
      
    #data for the Jinja template  
    template_values = {
      'pitchList': pitchList,
      'url': url,
      'metadata': metadata}

    template = jinja_environment.get_template('museline.html')
    self.response.out.write(template.render(template_values)) #write data to the html template
  
app = webapp2.WSGIApplication([('/', museline)],
                              debug=True)

Template:

<!DOCTYPE HTML>
<!-- museline.html -->
<html>
  <head>
    <title>
      museline
    </title>
    <link type="text/css" rel="stylesheet" href="/stylesheets/style.css" />
    <script type="text/javascript" src="http://www.google.com/jsapi"></script>
    <script type="text/javascript">
      google.load('visualization', '1', {packages: ['corechart']});
    </script>
    <script type="text/javascript">
      function drawVisualization() {
        // Create and populate the data table.
        var data = google.visualization.arrayToDataTable([
        ['pitch position', 'melodic contour'],
        {% for pitch in pitchList %}
          ['{{ pitch[0] }}', {{ pitch[1] }}],
        {% endfor %}
        ]);
       
        // Create and draw the visualization.
        new google.visualization.LineChart(document.getElementById('visualization')).
        draw(data, {curveType: "function",
          width: 800, height: 400,
        vAxis: {maxValue: 1}}
        );
      }
      google.setOnLoadCallback(drawVisualization);
    </script>
  </head>
  <body>
    <div id="visualization"></div>
    <p>Metadata:</p>
    <ul>
    {% for metadatum in metadata %}
      <li>{{ metadatum[0] }} : {{ metadatum[1] }}</li>
    {% endfor %}
      <li>URL: <a href="{{ url }}">{{ url }}</a></li>
    </ul>
  </body>
</html>

--------------

museline: charting melodic contours via web service

leave a comment

In the last post, I mentioned I was playing with Google App Engine and Google Chart Tools.

Last night, with some silly movie streaming in the background, I was in bed tinkering with a little idea that I'm sure has been done a-thousand times already and that may be built into high end music notation applications. But it hasn't been done by anyone as stoopid as me!

What I did was whip up a little App Engine/Python app where one can pass it a partwise MusicXML file and it will use Google Chart Tools to create a little line chart of the melodic contour of the first <part> element.

Here's a screenshot below of the results using the MusicXML sample file available on the MakeMusic site of Schumann's "Im wunderschönen Monat Mai" from the Dichterliebe. The app has an "mxml" parameter that tells it which MusicXML file to use a la "http://localhost:8083/?mxml=http://downloads2.makemusic.com/musicxml/Dichterliebe01.xml".

I've embedded a really nice performance on YouTube if anyone wants to follow along. The contour graph represents the vocal part only.

Now, this is just a start. There's a lot of work to do if I pursue this. For starters, I'd like to make the chart synced with an audio/video recording. I don't know if I can do that with Chart Tools, but probably with the <canvas> element if nothing else. Also, I haven't tried this yet with any non-homophonic parts. Anyway, it's a start and it's kinda fun.

I tried to add another line for the actual pitch class contour but it wasn't as interesting to look at as the melodic contour so I disabled that "feature". By pitch class, I mean I was using octave equivalency so that all "C" notes, for example, were plotted at the exact same vertical position as opposed to the screenshot above where two "C" notes an octave apart would have different vertical points on the graph to depict the intervallic difference.

As far as plotting the notes, I ignored rests and durations. I just plotted the pitches as below, starting with "C" with a value of "1" and with the "B" a seventh up from that "C" receiving a "12".

C : 1
D : 3
E : 5
F : 6
G : 8
A : 10
B : 12

This way a "C-sharp" and "D-flat" receive a score of "2", for example, because they lie between "C as 1" and "D as 3".

In MusicXML, the <step> element has the note name and the optional <alter> element, which is a number, tells you if it's sharp or flat, etc. The numerical <octave> element tells you what octave range the pitch is in.

So what I'm doing is pulling out the <step> value and converting it to a number as above, adding the <alter> value (a flat is a negative number), and then ~~multiplying~~ adding that sum to 12 times the <octave> value. Then, I multiple the value by ".01" just to reduce the number because I want the graph's vertical limit to be a small number even though this shouldn't change the contour itself.

Last, I'm trying to pull some basic descriptive metadata if they are present in the MusicXML file and show it below the graph.

Maybe I'll do more with this later. Just goofin' for now.

--------------

MXMLiszt article published

leave a comment

If anyone's truly bored, an article of mine about MXMLiszt has been published through OCLC Systems & Services.

Here's the citation:

Nitin Arora, (2011) "MXMLiszt: a preliminary MusicXML digital library platform built on available open-source technologies", OCLC Systems & Services, Vol. 27 Iss: 4, pp.298 – 316.

I need to give a huge shout-out to Dr. Steven MacCall at the University of Alabama under whom I did the research for MXMLiszt which included delivering the software and a paper – that's much longer than the published one! – about libraries and digital sheet music. It was cool to finish up my library degree with stuff that meant more to me than just a means to, well, finishing up the degree.

…

Update, November 26, 2011: I should have mentioned that this article is not openly available. If you want to read the article but can't access it through your institution or local library, please email me at "nitaro74 AT gmail DOT com". Under the publication rules, I am allowed to distribute the version of the article I submitted to the publisher. I don't have any problem doing so if someone is genuinely interested provided you agree not to openly distribute copies and provided you check with your local library first. Most libraries have access to more resources than most of their patrons know!

--------------

MakeMusic makes a great move in hiring Good

leave a comment

MakeMusic, the company behind Finale, has entered into an agreement to purchase Recordare. You can see the press release here but here's the really important part (hyperlinks mine):

Under the terms of the agreement, MakeMusic is purchasing the MusicXML™ open format and Dolet® software technology, including copyrights, source code, and trademarks. MakeMusic also announced that the founder of Recordare and inventor of MusicXML, Michael Good, will be joining MakeMusic as the Director of Digital Sheet Music.

A few people, myself included, were both excited for Recordare/Good but were also wondering what this means for the future of MusicXML in terms of remaining open so here's the scoop – posted on November 2, 2011 – from Michael Good himself on the MusicXML discussion list:

… MusicXML will remain an open format. MusicXML will continue to be licensed under the same open, royalty-free terms it has today. MusicXML's value comes from being an open format that anybody can freely use in their products and services. That will not change. Community development of future versions of the MusicXML format will not change. What will change is that MusicXML will now be supported with a larger company with more resources. There are exciting possibilities ahead!

Personally, I'm not worried.

In terms of XML approaches to music encoding, there's MusicXML and then there's everything else. Mr. Good's known all along that building relationships that ensure software support is a key to success for the format. He's even been kind to the little guys: emailing me and commenting on this blog in regard to some of my work with MusicXML for digital libraries.

So congratulations to Michael Good and MusicXML. I'm looking forward to hearing the next movement.

--------------

thinking about note entry in digital score editors

leave a comment

Good artists borrow, great artist steal.

I've generally heard this quote attributed to Pablo Picasso but also to Igor Stravinsky. It's interesting to think that since they knew each other, one might have stolen it from the other. Related, I glossed over this post on About.com. I didn't read it carefully, but I agree that the quote is misunderstood. I've had discussions in the past with friends who simply invoked the quote to justify lifting parts of someone else's work in the pursuit of trying to create. But as I'd say to them, that isn't stealing, it's only borrowing. If you steal something, you make it yours, making it work so well in your image that it's no longer immediately recognizable as having belonged to another.

Anyway, this post is about digital music notation. Or so says the title.

I've long wondered – even going back to music school in the 1990's – about using a stylus to enter music onto a drawing tablet or what not. And I'm thinking about it more and more. I saw this thread about the possibility of MuseScore on Android tablets, etc. and using the touchscreen interface on a tablet computer as a desktop/mouse replacement, but I keep thinking about the stylus.

Why? Because I hate entering music in score editors. I find it infinitely faster to write music with pencil and paper. I think a large part of this is that there's no translation occurring in my mind between hearing/visualizing what I need to enter and then mapping that into how that gets entered in a score editor. Arguably, some of that irritation would get reduced with practice, but not really in my case because I just don't think that graphical entry via keyboard or a note palette is the way to go.

When I write with pencil, I usually jot down the notes for a small phrase, etc. and then add the stems in afterward. I think that way the part of my brain thinking about notating pitch and duration are slightly separated which for me, at least, makes the process faster. Sometimes I enter each pitch and its duration note-by-note, but it's not conscious and it's still fast. With digital, I find it a royal pain in the ass trying to enter pitches first and then changing their durations. Often, it seems to "break" the measure and cause encoding problems. Going the other route (entering the durations first) doesn't work either. They're both so much more work than the traditional pencil and paper routine. And I end of spending more time thinking about notation entry than Music.

That's what I love about Lilypond. I love how I can just enter into a simple text string just the note names and then go back and add the durations – there's no digital/graphical veil. In terms of computing, it seems a more native and natural approach to use simple text entry than to try and emulate ideas from the pencil and paper world (but do it less efficiently). In fact, Lilypond is the only thing I could use to notate a score as I compose it. That's what I did with this piece for solo guitar. It would be great if MuseScore had something similar to a text-only entry box that rendered as graphical notation after-the-fact, kinda like what happens on weblily.net. I almost want to say Finale does (using some custom text notation syntax) but I can't seem to find a screenshot or anything in the online Finale manual.

I just feel like maybe we're borrowing when we should be thinking about stealing. If we're going to pursue graphical ways of digital notation entry, I think we've got to think about being able to offer users the ability to draw their music with a stylus (more precise than a finger) and having that instantly recognized via OMR. That experience won't be too great on a tablet, but maybe one day with better digital paper and smart pens:

What happens when you have to erase something?

Maybe I'm just an old fogey, but for now I'll stick with pencil and paper and just using a computer to make the music more legible after the fact. There's one enormous advantage to this, too, and it's a musical one: it forces conscious consideration of revision upon me as I "re-notate" the music. Honestly, I doubt I would ever want to not use pencil and paper anyway. Music is the one thing I can do without needing a computer at all.

--------------

MXMLiszt version 0.9.2 released

leave a comment

If anyone's interested, MXMLiszt version 0.9.2 is now available for download.

MXMLiszt is a web-based delivery and search/retrieval environment for MusicXML files and their manifestations.

The documentation and source-code download links are available here.

Here's the changelog:

0.9.2
- included Bach and Schubert MusicXML files from MusicSQL project (http://musicsql.googlecode.com/).
    - For the Bach, cleaned up diacritics (in titles only) and changed "Soprano", etc. to "Soprano", etc.
        - diacritics are still messed up in lyrics. I'm too lazy to fix them. :]
    - For the Schubert, changed "Part_1" through "Part_4" to "Violin 1", "Violin 2", "Viola", and "Cello".
    - original files available here:

http://musicsql.googlecode.com/files/Bach_SATB-1.0.zip


http://musicsql.googlecode.com/files/Schubert_quartets-1.0.zip

- adjusted <hr> rules in style.css to accomodate Internet Explorer 9
    - Removed "optimized for Firefox" in welcome.php since MXMLiszt now works well in IE, Firefox, Chrome, Safari, and Opera (see below).
- fixed generateIndex.php so the <img> tag now closes in this line:
        echo nl2br('<img src="png/' . $filenamePlain . '.pre.png" />'); //line #12
    - This was the only reason the Index view wasn't working in Opera.
        - Opera was the only browser that caught this error. :]
- made "Results" header for search results an <h2>, just as with the MIR results header.
- added two modules: startWatch.php and stopWatch.php to reduce coding redundancy in regard to reporting the time it takes for actions to finish.
- changed mxml2mods.xsl to output the MODS namespace.
    - adjusted mods.xsl, loadMODSasDC.php, and XQuery syntax as needed.
    - Sample XQueries using a namespace prefix:
   
        This is a Faust query example:
                    declare namespace mods = "http://www.loc.gov/mods/v3";
                    for $x in doc("../concat/concatMODS.xml")/hyperMODS/hypoMODS/mods:mods
                    let $x1 := $x//mods:subTitle
                    return $x1
                   
        This is a Dante example:
                    declare namespace mods = "http://www.loc.gov/mods/v3";
                    for $x in doc("../concat/concatMODS.xml")/hyperMODS/hypoMODS
                    let $x1 := $x/mods:mods
                    where $x1//mods:subTitle contains text "You"
                    return data($x/@file)
                   
- simplified some of the built in MODS related XQueries (same functionality, just less wordy).
- changed order of MODS search drop down terms on Search page.
- changed <i> and <b> to <em> and <strong>, respectively.
- replaced "pop1", etc. with better-named CSS variables like stickyNote and IndexPopup, etc. in style.css.
- added a streamed comment in each module with a one or two sentence description of what it does.
- added .htaccess file.
    - to hide root folder.
    - to make the "/~foo.xml" forward (with masking) to:"transmuteMXML.php$fname=musicXML/foo.xml".
        - adjusted mxml2mods.xsl accordingly.
    - to hide directory icons.
    - to use fancy indexing.
- changed displayMODS.php to display MODS files via an <iframe> only as a fallback if PHP XSL processing not available on server.
_______________________________________________________________________
0.9.1
- created mods.css file to display MODS on a transparent background.
- changed displayMODS.php to display MODS files via an <iframe>.
    - The previous version was using the mods.xsl stylesheet to parse the MODS element values in real-time.
_______________________________________________________________________
0.9.0
- this was the first version - that worked!

--------------

Musescore: way better Lilypond export than before

2 comments

When MuseScore first came out, I think a lot of people knew it was going to be great.

And it is. It's also getting better all the time.

One thing that wasn't great initially was the Lilypond export. But MuseScore version 1.0's Lilypond export seems really good from initial experiments I've done.

And let's face it – that's the holy grail of music notation: a GUI score editor with good Lilypond export … AND MusicXML support … and command line options.

So in other words, a one-stop shop for music notation that supports the best tool (Lilypond) for output in terms of aesthetics and the more widely supported XML format in MusicXML … as well as those command line options for using on a server.

Well, well done people.

Keep it up.

--------------

VideoScores from the MuseScore gang

leave a comment

Here's a cool screencast from Thomas on how to create a VideoScore for musescore.com.

I like how easy it is to do the matching of audio to score … I wonder if there's something similar for audio to transcript matching.

--------------

blog.humaneguitarist.org

Archive for the ‘music notation’ Category

a follow up to my MuseScore and LilyPond musings from the previous post

Related Content:

music notation frustrations and what’s on my programming plate

Related Content:

museline: trying to add support for compressed MusicXML

Related Content:

museline: charting melodic contours via web service

Related Content:

MXMLiszt article published

Related Content:

MakeMusic makes a great move in hiring Good

Related Content:

thinking about note entry in digital score editors

Related Content:

MXMLiszt version 0.9.2 released

Related Content:

Musescore: way better Lilypond export than before

Related Content:

VideoScores from the MuseScore gang

Related Content:

Archives

Pages

Categories

Recent Posts

Recent Comments

Tags