Google Summer of Code 2013

• Feb 12, 2013 - 12:44

The 2013 edition of Google Summer of Code has been announced. It's a global program that offers post-secondary student developers ages 18 and older stipends to write code for various open source software projects, and getting paid for it. Read all about it on the GSoC website.

We are going to submit MuseScore again for this edition as we did for previous years. If you have an idea for a summer project, please don't hesitate to post it on our ideas page for 2013. A good GSoC idea is something which can be implemented in 3 months and optionally has a high impact on the MuseScore user experience.

Looking forward to hear about your ideas.

Attachment Size
gsoc-2013.jpg 76.77 KB

Comments

Just curious if we got any feedback why MuseScore wasn't selected last time around? Anything we couold do differently to increase our odds? Not that I contributed any specific proposals last time around, but I definitely have some ideas I'd like to add to that page.

In reply to by Marc Sabatella

We never got any specific feedback why MuseScore wasn't selected. There has been however a precedent of notation software accepted for GSoC.

To increase our odds, we already posted the idea to port a part of MuseScore to Native Client (NaCl) which should be interesting for Google. There is already experimentation going on with Qt and NaCl. It would mean the ability to display, play, transpose MuseScore or MusicXML files in Chromium and Chromium OS. You may know these open source projects under their product: Chrome (the browser) and Chromebook (the netbook). Both are Google products. Christopher J. Russell already blogged about the Chromebook and notation software btw.

In reply to by Thomas

I realize it's rather late in the game for me to finally suggest some ideas, and I apologize for not following through sooner. But if any students are interested, here are some things I think might make decent projects. Should I add these to the main "ideas" page, or wait to see if there is any sort of consensus that these are worth adding? I don't know the code well enough (basically, not at all) to be a primary mentor myself, but I would certainly be willing to be a secondary resource for concepts, usability, etc.

1) Playback of slurs (and other markings)

MuseScore currently plays back a number of markings, but it makes no effort to play slurs, and this significantly limits the realism of playback for wind and stringed instruments. Implementing this could potentially be as simple as having MuseScore sending appropriate MIDI controller messages. But it is possible the synthesizer backend and/or sooundfonts still would not support this, in which case you would have to dig in deeper. Similarly, playback of hairpins (crescendo and diminuendo) also requires use of MIDI controller messages in order to affect single notes - here, there is every reason to assume this would work with no additional backend support. There may also be a few other markings that currently do not playback but could be supported more easily just through adjustments to note velocity, duration, etc.

2) MIDI out and/or VSTi playback

Rather rely on MuseScore's built in synthesizer feature, the ability for it to control other synthesizers - including virtual ones - would open the doors to further playback improvements. This would probably require fairly signifiant work and knowledge of real time programming techniques.

3) Slash notation

Jazz and pop music makes use of "slash notation" - diagonal slashes one per beat used to indicate a measure is open for improvisation, also notes with slash heads used to ondicate specific rhythms to be played with user-chosen pitches. MuseScore can create this type of notation, but it is not ideal - they are just ordinary notes with the note heads and perhaps stems changed. This means they are affected by transposition, which they should not be. This project would have you implement a "true" slash notation that was immune to transposition. A quick-and-dirty way to implement this would be to simply add a "do not transpose" flag to notes the user could set when creating slash notation the current way (via a plugin that alters note properties of ordinary notes to produce the appearance of slash notation). The "better" way is to implement native support for slash notation, ideally using a mechanism similarly to however MusicXML defines this to work.

4) User control over copy & paste

A very common user request is to allow the user to control what gets copied in a copy/paste operation. Currently, it is always notes, chords, articulations, and lyrics only (?), but often, people might want to specify that text is also copied, or note properties, or that chords or lyrics are *not* copied, etc. A "special copy" operation that displayed a dialog with a series of checkboxes allowing the user to select what gets copied would be one approach to solving this.

In reply to by Marc Sabatella

Thanks for the suggestion. We could try to refine the ideas but as it, I don't think they are suitable for GSoC this year.

1/ This is one is too small or too big for 3 months work depending how we look at it. Adding just a way to "play" slurs for flute is too small. A full fledge MIDI editor is too big. It's the long term goal of the pianoroll dialog to give more power to the user, but elaborating the piano roll in 3 month time to have something working is probably too big.

2/ These two topics are a bit different. Both of them would requires a lot of changes in the UI. For some of the changes, I don't think MuseScore is ready for them. It would cluttered the UI. MIDI output is a complex thing to handle in a multiplatform way, 3 months seems a bit short to handle it in a good way. VSTi is a topic on itself. Making MuseScore a VSTi host could sound like an awesome idea, but in practise it could turn out as a nightmare support. There are so many VST instruments out there, a 3 month job would not be enough to provide a solid base for this.

3/ This one is interesting but it's too small. I estimate a week of work for someone enough knowledgeable.

4/ This one is also interesting, and we will make it for sure but it also feel too small for GSoC.

In reply to by Nicolas

Thanks for the feedback. I figured it might come down that way. Although, what about the idea of someone tackling two or three small projects? Benefit would be freater likelihood of at least some of them being completed compared to pickong something that one guesses will take three months but turns out to take longer.

In reply to by Nicolas

If #3 is really that small, can you point me to the relevant parts of the code and give me an outline of an approach to accomplish this? I'm an experienced C++ developer, but haven't worked too much with Qt or GUIs.

This is one area that I really need as everything I do is jazz oriented and proper slash notation is essential.

I can't promise that I'll have the time to get it done (and I have to get MuseScore 2.0 compiling on my machine first), but if I can do it, I will!

- Mike.

Do you still have an unanswered question? Please log in first to post your question.