Google Summer of Code 2020 Ideas

עודכן לפני 4 שנים

    Your idea

    Click the 3 dots button at the top right and "Edit", then copy and paste an idea below and change the text with your new idea for GSoC 2020. Don't forget to remove the mentor's name (unless it's you).

    Anybody is welcome to add an idea to the page, but newcomers are encouraged to discuss their idea on the MuseScore developers Telegram channel or via the developer mailing list first. Also check ideas from previous years.

    Students

    If you are a student keen to take part in GSoC, we strongly believe that the best project for you is the one you are most interested in and therefore most willing to do. It doesn't have to be one of the ones listed on this page; you can suggest your own.

    Whichever idea you choose, you should speak to us first to check that it would be manageable before you go to the effort of writing a proposal. This is particularly important if you want to suggest your own project, as we would have to find a suitable mentor.

    Check out the steps toward successful application.

    Mentors

    If you would like to be a mentor for GSoC then feel free to put your name down next to any projects you are interested in and that you think you are qualified to mentor. In order to meet Google's requirements for mentors, only experienced developers with a high level of familiarity with MuseScore's code are eligible. However, non-developers, and developers new to MuseScore, may be able to assist in an advisory role if they have specialist knowledge relevant to the project in question.

    Community

    Everybody is free to contribute ideas. You are also welcome to follow the progress of the students and offer constructive feedback once the projects are underway.

    Post-its for miscellaneous ideas

    One feature that MuseScore currently lacks is the ability to jot down and attach notes (annotations) to scores. Having the ability to attach little annotations of musical ideas to different parts of the main score may be beneficial for composers and musicians, as they can keep track of their thought process and come back to old ideas at their leisure. Perhaps the composer has some ideas for a section of music that might work in the context of the entire piece, but the composer hasn't gotten around to fleshing out the new ideas yet or likes another idea better at the moment.

    Having the ability to attach little notes at different points in the score is a good way to brainstorm. Also, it could help organize things better than having a new project altogether or keeping a separate music notebook and writing down notes there. The post-its could be color coded, broken down into different sections, etc. Instead of creating scores for performance, musicians could create scores just for brainstorming, and gradually transform the score into a final score when they have enough ideas. The post-its could have the ability to contain text and to test different combinations of chord progressions, voice leading, and instrumentation. There could be bullet points for different musical ideas, color coded as the user desires. With "create post-it" mode enabled, the user could click on a particular point in the score and create a post-it there, and from there the user could write some notes in the little pop-up. The user could then close out and reopen the notes by clicking an icon that been created of a little post-it.

    Difficulty: Medium
    Skills: C++/Qt
    Possible mentor: Marc Sabatella (@MarcSabatella)

    Simplified lyric & chord symbols only

    A simplified pop/rock input method for making lyrics & chord symbol (and/or chord tab) only scores, without worrying about a staff, melody or rhythm initially, but which would still could be easily updated to include notated melody with rhythm. Maybe using a minimal slimmed-down interface. And if could import basic ascii charts of lyrics chord symbols.

    Difficulty: Medium
    Skills: C++/Qt
    Possible mentor: @ericfont

    Diatonic instrument definition

    One of the most common requests that is nearly impossible to implement in current versions of MuseScore is diatonic instruments such as the Shamisen and Appalachian Dulcimer. These instruments have a limited number of notes that can be played on a string due to their fret definitions. Current tablature does allow for the limited notes permitted to be played on a string.

    I would suggest the instrument definitions be expanded to allow for detailed frets that can be applied to a given string. The definition should limit the actual note that can be played by the instrument and indicate an error similar to the current method if an illegal note is entered on both the standard and tablature clefs.

    A possible way to do this is to create an interface that allows for defining new instruments to include string and fret definitions as well as individual notes for instruments such as diatonic harmonicas and accordions among others.

    I am not qualified to be a mentor, but I would be more than willing to be a consultant on this project (@mike320), with programming mentoring from @TheOtherJThistle.

    Difficulty: Hard
    Skills: C++/Qt
    Possible mentor: mike320 + James Thistlewood (JThistle/TheOtherJThistle)

    Ornaments maker

    A common request if for proper playback of ornaments, such as turns and trills with accidentals. There needs to be a framework created to allow the user to define an ornament and have it play back properly in MuseScore. One thing you cannot currently do is apply an accidental to an ornament.

    The interface would allow the user to define the ornament, or line in the case of a trill line or prall line, based upon the key of C on a C note. The actual notes played when the ornament is encountered would be a transposition of these notes. So if the user defined a trill with a sharp above it to be played as D#-C-D#-C... (as was done in the baroque era), a trill on an G in a key with 4 or fewer sharps would result in the trill being played as A#-G-A#-G... The user would also be able to define the duration of each note played, allowing in the case of a trill for the notes played to be defined as a set duration such as 16th or 32nd notes according to the requirements of the music. Turns, pralls and so forth should also allow for accidentals to be added under the ornament to allow for defining proper playback of all ornaments used in western music.

    I am not qualified to be a mentor, but I would be more than willing to be a consultant on this project (@mike320), with programming mentoring from @TheOtherJThistle.

    Difficulty: Hard
    Skills: C++/Qt
    Possible mentor: mike320 + James Thistlewood (JThistle/TheOtherJThistle)

    Keyboard real-time input

    Author: @anatoly-os

    I wish we could use keyboard (not MIDI-keyboard) for convenient real time note input. The focus of the project is composers who create music from scratch.

    I will add the video which show the idea later.

    When creating music, we usually have some melody in mind and want to express it with simple combination of notes and its duration. Real time input starts with the default tempo and fills the rests with notes specified by user. It is not necessary to hold letters (A-G) to enter the duration, the input mode fills the beats with the previously added note until rest or following note key will be pressed.

    You still need to use letters to specify a pitch, but duration is set depending on how long you hold the button. It is like you are playing piano, but playing "keyboard" instead. So, there is a metronome, which counts the rythm. And you press and hold buttons to create a melody.

    Difficulty: Medium
    Skills: C++/Qt
    Possible mentor: anatoly-os

    Lyrics editor

    As described here and partially implemented here, the Lyrics Editor would display all lyrics from the score as plaintext in an editable multiline text field. The contents of the text field would be doubly linked with the score, meaning that a change to lyrics in either the score or the Lyrics Editor would be reflected in the other. Users would be able to search for lyrics online and paste them into the lyrics editor, or copy lyrics from the editor to produce lyric booklets for choirs and church services. A more advanced implementation would use a tree view where each lyrics verse is represented by a branch in the tree.
    Possible extensions: spell-checking, automatic hyphenation, verse extraction.

    • Difficulty: Medium
    • Skills: C++/Qt
    • Possible mentor: Peter Jonas (@shoogle)

    Palette shortcuts

    Another way to improve palette accessibility (and general usability for all users) is to allow the user to define keyboard shortcuts for individual palette elements. For example, the user might want to press Alt+D to enter a key signature of D major, or Ctrl+T to add a trill, etc. There could be an option to set shortcuts in the context menu that appears when you right-click on a palette. If the user tries to set a shortcut that has already be defined for another palette element then a warning should be displayed. An improved implementation would also check for conflicts with the shortcuts set in the main Preferences dialog. An ideal implementation would allow shortcuts defined anywhere in the program to be dynamically registered with the central list of shortcuts displayed in the main Preferences dialog, so that all shortcuts could be set and unset in one place, and to guarantee that conflicts are avoided (c.f. the Plugin Manager allows the user to define shortcuts to run plugins, but there is no collision detection with shortcuts defined elsewhere).

    • Difficulty: Medium
    • Skills: C++/Qt
    • Possible mentor: Peter Jonas (@shoogle)

    Command macros

    In some engraving situations, it is useful to apply several commands to a single object. One case like this is if you want to add a end/begin repeat barline. You want to add an end repeat and a start repeat to the same barline. It could be useful to create a framework to allow users to create their own macros stringing more than one command together. A macro can then be applied with a single click or keyboard shortcut.

    • Difficulty Medium
    • Skills C++/Qt
    • Possible mentor: Louis Cloete (@Louis Cloete)

    Chord symbol style editor

    MuseScore supports the entry of chord symbols like Gm7, C7b9, etc. It has a pretty flexible system for entering the chords, where you can type pretty much a human musician might understand and MuseScore will do its best to understand it as well. However, there are only limited controls for actually displaying the chord symbol. MuseScore provides two preset options - Standard and Jazz - and does not allow you to customize, for instance, how large the "G" should be relative to the "m" or the "7" in Gm7, or how much subscripting should be applied to the "b9" in C7b9. There was some preliminary work done on an editor years ago that could be leveraged in producing a more complete facility. There are also some improvement that could be considered in how chord symbols are handled with respect to transposition, linked parts, fretboard diagrams, capo, Nashville notation, MIDI import, MusicXML, etc.

    • Difficulty: Medium to Hard
    • Skills: C++/Qt
    • Possible mentor: Marc Sabatella (@MarcSabatella)

    Text editing improvements

    Text in frames and elsewhere currently allows for some basic formatting options, but lacks many capabilities one would want in order to do any serious text editing, like to create educational materials with significant text between the musical examples. While we would likely not ever compete with word processors, merely implementing word wrap, justification, and a few other controls could go a long ways toward allowing users to create documents completely within MuseScore.

    • Difficulty: Medium
    • Skills: C++/Qt
    • Possible mentor: Marc Sabatella (@MarcSabatella)

    Page layout controls

    MuseScore provides a number of global controls over page layout - you can set the page size and margins, staff size, control distance between staves, hide empty staves, etc. There are certain overrides possible like staff spacers to change the distance between two staves, and the staff type change element to change certain properties for individual staves mid-score. However, sometimes there is still a need to for more control - override global settings for individual pages, or particular systems. You cannot have the overall staff size or default staff distance slightly smaller on one page than another, or change between percussion and pitched on a single staff, or designate certain systems to not hide empty staves, not fill to the right margin, etc. Also, we provide measure spacing controls per-measure, but no easy way to say "fit the following measures on one system".

    This project would involve an investigation of how we might best expose controls like this to the user and then to design and implement the facility.

    • Difficulty: Hard
    • Skills: C++/Qt
    • Possible mentor: Marc Sabatella (@MarcSabatella)

    Cross-staff notation improvements

    MuseScore can do cross-staff notation by selecting a note/rest and pressing Ctrl+Shift+Up/Down. However, there're a few limitations.

    A complete list of issues related to cross-staff notation can be seen in #285233: [EPIC] Cross-staff notation issues. While working on them, it's necessary to keep backward file compatibility in mind.

    • Difficulty: Medium to Hard, depending on how far you get
    • Skills: C++/Qt (doesn't necessarily involve UI changes, but you have to understand the geometric graphing of score elements)
    • Possible mentor:

    The two-measure repeat sign with working playback has been one of the most-requested features ever, as is evident by the number of forum requests and length of this issue #10220: Add a two and four measure (multi-measure) repeat sign with playback at 164 replies and going back 8 years. This project would involve coding various multi-measure and related features, like

    • Two-measure repeat
    • Old style multi-measure rests
    • Repeat previous bar N times markings

    • Automatic counting of repeated measures

    • Difficulty: Medium

    • Skills: C++/Qt
    • Possible mentor:

    Braille export

    This project would add Braille music notation to the list of formats available via File > Export. Prior knowledge of Braille music notation is not required as the basic rules are fairly straightforward and can be picked up in the early stages of the project. As with everything, the specifics of Braille music notation do get quite complicated and can even vary from country to country, so the student would not be expected to implement more than basic export functionality. However, the project would seek to identify the main hurdles that a full implementation would have to overcome, and potentially begin to explore solutions to these problems in the code. A secondary objective is to raise accessibility awareness in the developer community, and to leave behind a clear roadmap for future Braille development that would build on the foundations laid in this project.

    • Difficulty: Medium
    • Skills: C++/Qt
    • Possible mentor: Peter Jonas (@shoogle)

    More realistic tempo playback

    Having completed single-note dynamics, I've been thinking about ways we can improve playback.

    One thing we could do is to allow the playback of rit. and accel. markings. These would have to be user customisable, for example what tempo to change to and how to interpolate between tempi.

    This isn't just limited to these tempo markings, or even just to tempo markings. If you have any other playback improvement ideas, please let me know. I'm sure we can work to implement them as well.

    I've worked a lot with playback, so I feel like I could mentor this fairly well :)

    • Difficulty: Medium
    • Skills: C++/Qt
    • Possible mentor: James Thistlewood (JThistle/TheOtherJThistle)

    Realistic MIDI sound

    As a composer who would like to use the sounds of MuseScore’s native instruments in the final product, I find it underwhelming that some instruments when transposed become indistinguishable or how multiple percussion instruments share the same sound. Improving and diversifying the sound options of these instrument as well as giving users more freedom to playback with their own sounds would expand music styles used.

    This can be achieved by a small UI window which can read in sound and give the user controls for previewing the sound when it is modulated.

    • Difficulty: Medium
    • Skills: C++/Qt
    • Possible mentor: ???

    Albums

    The one significant feature that MuseScore 2 had and MuseScore 3 lacks are albums. This feature allowed you to build a larger work from multiple smaller ones. It could be used to build a complete sonata, symphony, or suite from several movements, or a songbook from dozens or even hundreds of individual songs. One reason the feature was eliminated is that it was quite limited - for instance, all component scores needed to have the same instrumentation, and the combined score would have only one global style. It was also pretty buggy.

    It's past time to reintroduce this feature into MuseScore 3, and to hopefully improve upon the original implementation.

    Difficulty: Medium
    Skills: C++/Qt
    Possible mentor: Marc Sabatella (@MarcSabatella)

    Tree model for libmscore

    Items in a tree model can have any number of child items, but they always have exactly one parent item (except the root item, which has no parent item by definition). Musical scores follow this model closely: a note's parent is the measure it belongs to, the measure's parent is its staff, and the staff's parent is the score itself. However, the model breaks down for "spanner" elements like ties. Is the tie's parent the note at the start of the tie or the note at the end? This can be resolved by thinking of the tie as two separate elements: a startTie and an endTie, both of which exist in the model, and a link between them that exists outside the model. Sometimes code can ignore the special cases, while at other times it is necessary to check whether an item is a tie before deciding how to handle it.

    Decendants of the "scoreElement" class in libmscore follow the tree model to a certain extent. Every element has a parent element, but there is no generic way to access child elements. For example, you can do element->parent() to get its parent, but you cannot do element->child(n) to get the n-th child. Instead you have to already know what the element and the child are (e.g. chord->stem()). The structure of the score is also different to that described in the previous paragraph. In libmscore, the parent of a measure is the score, not the staff, which limits MuseScore's ability to represent polymeter music (a complex workaround is required). Finally, spanner elements like ties are not treated as described previously, and so fall outside the model. If these issues are corrected then it will massively simplify operations like drawing elements, saving to MSCX (i.e. writing to XML), and handling of polymeter scores. It would also enable us to make use of Qt's item view classes, which provide improved accessibility over the current ScoreView implementation.

    • Difficulty: Medium to Hard (depending on how far you get)
    • Skills: C++/Qt
    • Possible mentor: Peter Jonas (@shoogle)