Google Summer of Code 2013

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.

AttachmentSize
gsoc-2013.jpg76.77 KB

Comments

Just curious if we got any

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.

Increasing the odds

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.

Submitted for GSoC 2013

We just applied MuseScore for mentoring organisation for the GSoC 2013 edition. Fingers crossed now.
If any Googler or other mentoring organisation wants to vouch for MuseScore, let us know!

If you are a student and you have a good idea, please post it on our ideas page for 2013 and introduce yourself on the developers mailing list.

Apply your project ideas today!

MuseScore got accepted for Google Summer of Code 2013! Students who have a passion for coding and music, check out one of the open project ideas or submit your own idea. If it gets accepted by Google, you can make $5,000 this summer while coding on MuseScore.

Don't hesitate to talk with us on IRC (#musescore on freenode.net) or email us directly.

I realize it's rather late in

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.

Further on 1)

A couple of other suggestions on 1) in Marc's message above.

- fermatas
- sforzato
- various flavors of turns and trills (?)
- better glissandos and arpeggios (?)

Fifist

FYI, some of that is actually

FYI, some of that is actually already in 2.0. But part of the project would be building a good list of symbols to be tackled.

Thanks for the suggestion. We

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.

Thanks for the feedback. I

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.

I guess it's better to have

I guess it's better to have something big enough to motivate the students. But if a student is already 200% motivated to tackle different issues. Sure, no problem. Also keep in mind that each student will need to be mentored by a developer.

If #3 is really that small,

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.

See

See http://musescore.org/en/developers-handbook/compilation for help on compiling MuseScore development version on your computer.
There are several areas if the code that would be impacted by this feature, the UI, the MIDI rendering, the transposition function etc... Let's discuss this in another thread on the tech preview forum or on the developer mailing list.

Update: 21 proposals are in

We received 21 proposals for GSoC 2013. Read more about http://musescore.org/en/node/20988

Syndicate content