Google Summer of Code 2019

Päivitetty 3 vuotta sitten

    Selected Ideas

    Plugin manager

    Student: songchaoBlog
    MuseScore functionality can be extended by plugins. Discovering the compatible plugins and installing them however is currently a manual job. The goal is to create an App Store-like Plugin Manager from which it is possible to discover, (un-)install, (auto-)update plugins in an easy manner. The Resource Manager currently used to handle language packs could be extended for this purpose, and indeed already has some bare-bones code for plugins.

    Since many (a little of 40%) of the current 2.x plugins are available on GitHub; we should consider using their releases-API for those plugins. At the same time, locally installed plugins must still be listed and integrated as well.
    Another matter to address is how to know if a plugin is compatible with the current MuseScore version.

    • Difficulty: Medium
    • Skills: C++/Qt
    • Mentor: Joachim Schmitz (@Jojo-Schmitz)

    Chord symbol playback

    Student: Peter Hieu VuBlog

    Playback of chord symbols is a huge can of worms, and MuseScore does not need to be in the business of trying to match the results of iReal Pro or other programs that specialize in generating realistic accompaniment. Still, some basic ability to hear chord symbols would be nice. There has been debate about whether this should actually generate notes on a staff that can be edited or just work in the background, also on what kind of rhythms to use, what kind of voicings, etc. A successful GSoC project would need to be very proactive in getting user input, coming up with a a good design, and then implementing the algorithm.

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

    Improve Instrument Changes

    Student: joshwd36Blog

    The main goal of this project is to streamline the process of adding instrument changes. Currently, most of the functionality does exist in MuseScore, but you have to do every step manually. By the end of the summer, I would like the process changing an instrument to simply be to add an instrument change object, and use the instrument change dialog to select the new instrument.
    The end goal is to handle textual hints, transposition and staff type changes automatically based of the chosen instrument.

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

    Palette accessibility

    Student: AnandHemachandranBlog

    MuseScore's palettes are not accessible to keyboard controls except via the palette search box. This is problematic for users who rely on a screen reader to tell them what is happening on the screen, such as people who are blind or partially sighted. A relatively straightforward solution is to replace each palette with a QListWidget in icon mode, and then enable tab access. However, since each palette is a separate widget, this means a lot of tabbing to get through all of them and back to the searchbox again. A better solution would be to use a QTreeWidget (i.e. a tree view), where the branches are palettes and the leaves are palette elements. However, there is no "icon mode" for tree views in Qt, so there would only be a single column of elements (or a fixed number of columns), which is visually not very efficient. The ideal implementation would make use of Qt's model-view classes, and extend QAbstractItemView to create a "category list view" (i.e. a tree view with an icon mode) where the number of columns is able to change dynamically as the user adjusts the size of the view.

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

    Remaining proposals

    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 2019. 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: Hard
    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)

    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 (coming in 3.1, hopefully), 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)

    Guitar griff

    The idea is simple. We want to improve guitar players experience, so we want to show guitar griff with 6 strings and visualise the frets on it. See an example in GuitarPro or TuxGuitar: https://www.youtube.com/watch?v=NU_FRFmJ3D4.

    Screenshot 2019-03-05 at 22.13.03.png

    • Difficulty: Medium
    • Skills: C++/Qt
    • Possible Mentor: anatoly-os/cadiz1

    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: ???