Google Summer of Code 2021

Aktualizováno před před 3 roky

    How to add an idea to this page

    Click the 3 dots button at the top right and "Edit". Copy a project idea from below and update the text with your new idea. Don't forget to remove the mentor's name (unless it's you).

    Everybody is welcome to ideas to the page, but newcomers are encouraged to discuss their idea with developers in MuseScore's Telegram group first. Also have a look at ideas from previous years.

    • Students
      • You don't have to do one of the ideas listed on this page; you can suggest your own. Always speak to us first to check that it would be manageable before you begin writing the application.
    • Mentors
      • In order to meet Google's requirements, only experienced developers who are familar with MuseScore's code are eligible to mentor projects for GSoC. Please speak to us if you are interested.
    • 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.

    Project Ideas

    Global Shortcuts

    Shortcuts.png

    Currently our shortcut system allows users to assign key combinations to a set number of existing functionalities. We want to expand this capability to enable users to select any item in the interface and assign a shortcut to it immediately.

    As a stretch goal, we would also like to create large shortcut 'sets' to help accommodate new users. For example, if a user is coming from Sibelius or Finale, they should be able to select a set that matches the workflow they are accustomed to.
    We have designed the interface and UX to support this feature already.

    • Difficulty: Easy (unless you propose something more difficult)
    • Skills: C++, Qt, QML, UI design
    • Suggested by: Martin Keary (@Tantacrul)
    • Mentor: Vasily Pereversev
    • Design support: Martin Keary (@Tantacrul) and Jessica Williamson

    Hairpin & Dynamics: UX Improvements

    Hairpins.png

    Hairpins are among the most important features in MuseScore. In MuseScore 3, the experience of adding, lengthening and copying/pasting has been improved but the overall task of finessing them remains unfinished.

    This task involved multiple small UX improvements to dragging and snapping behaviour, as well as stretch goals to develop a system where multiple hairpins can be edited at once, and an even stretchier goal where they can be grouped too. The designs for the expected behaviours have been created for this already by our in-house design team. This is a highly collaborative project that will involve iteration based on user-testing conducted by the design team.

    • Difficulty: Easy (unless you propose something more difficult)
    • Skills: C++, Qt, QML, UI design
    • Suggested by: Peter Jonas (@shoogle)
    • Mentor: Vasily Pereversev
    • Design support: Martin Keary (@Tantacrul)

    Accessibility for low vision impairment

    High_Contrast.png

    It is estimated that one in six adults over age 45 has low vision; one in four adults over age 75 has low vision. For this reason, MuseScore 4 was built with a new UI system that allows for very flexible colour themes. In part, this was done to make way for a highly configurable 'High Contrast' theme which allows users to specify the colours and intensity of the MuseScore interface. This would be largely based on the flexibility of the High Contrast capability seen on Windows 10 devices.

    With any remaining time, this task should include a magnification system that allows the user to scale up the size of the MuseScore interface as well as the ability to invert the colours of the score page itself.

    • Difficulty: Easy (unless you propose something more difficult)
    • Skills: C++, Qt, QML, UI design
    • Suggested by: Martin Keary (@Tantacrul)
    • Mentor: Vasily Pereversev
    • Design support: Martin Keary (@Tantacrul)

    Tours

    MuseScore 3 has a Tours facility, which is basically a series of dialogs that point out different parts of the program and teach people how to use them. However, these dialogs can distract users and get in the way of a normal workflow.

    For MuseScore 4, we'd like to improve the Tours feature to make it more helpful and less annoying. This could mean using tooltip-style popups rather than dialogs, integrating tutorials directly into the interface, or another idea suggested by the student. The student would work with their mentor and the internal design team to come up with the best design, implement it, and update it based on testing and user feedback.

    • Difficulty: Easy (unless you propose something more difficult)
    • Skills: C++, Qt, QML, UI design
    • Suggested by: Martin Keary (@Tantacrul)
    • Mentor: Vasily Pereversev

    AppImage Installer and Updater

    MuseScore's AppImage has command line options to update and install itself, but there is no way to do these things via the GUI. This project would create an update solution for Linux along the lines of the Sparkle and WinSparkle frameworks that MuseScore uses for automatic updates on macOS and Windows respectively. The project would include an install wizard that would offer to integrate the AppImage with the desktop environment (GNOME, KDE, etc.) so that it appears in system menus. While the project would be built primarily for MuseScore, the code would be written and licenced in such a way that other Qt-based AppImage projects could use it too.

    • Difficulty: Medium
    • Skills: C++, Qt, AppImage
    • Suggested by: Peter Jonas (@shoogle)
    • Mentor: Peter Jonas (@shoogle)

    Embed Third-Party Documents

    MuseScore allows users to insert images in SVG, PNG and JPEG formats, which can be useful for adding complex notation that is not natively supported. However, there is no convenient way to make changes to these images after they have been inserted in MuseScore. Instead, users must edit the image in an external program, ideally using the original source file (e.g. Inkscape or Adobe Illustrator project file) rather than the image itself.

    We don't want to add complex image editing features in MuseScore, but it would be great to have the option to right-click on an image and choose "Edit with Program X". MuseScore should allow project files for Program X to be embedded directly in the score along with the corresponding SVG, PNG, or JPEG image. When the user chooses to edit the image, Program X would be launched with the project file open in a temporary folder. MuseScore would monitor the project file for changes, and when it is saved, MuseScore would call Program X on the command line to generate a new SVG, PNG or JPEG image to replace the one currently displayed. The new image would be stored in the MSCZ score file along with the newly updated source file for Program X.

    In the future, this process could be generalised to allow embedding third party audio, video, and rich text documents, as well as images. Advanced users might also like to specify their own custom script as both the embedded project file and as the "Program X" used to launch it. We would need to consider security implications very carefully before enabling that particular use case.

    • Difficulty: Medium
    • Skills: C++, Qt
    • Suggested by: Peter Jonas (@shoogle)
    • Mentor: Peter Jonas

    Lyrics Editor

    As described 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.

    The lyrics editor was partially implemented in PR #2326, but this was using the old Qt Widgets (C++) interface for MuseScore 3 and the design was far from optimal. The student would work with the in-house design team to come up with a improved design, and then implement it in the new Qt Quick (QML / JavaScript) interface for MuseScore 4.

    Possible extensions: spell-checking, automatic hyphenation, verse extraction.

    • Difficulty: Medium
    • Skills: C++, Qt, QML, design
    • Suggested by: Peter Jonas (@shoogle)
    • Mentor: Peter Jonas (@shoogle)

    Select/Copy/Paste Improvements

    One of the most long-standing feature requests is to improve copy/paste to allow key and time signature changes, tempo texts, repeats, and other "system" elements to be copied. This would be optional, as sometimes you don't want those things copied. The actual implementation of this is not necessarily all that difficult, but the project would also involve determining a good design for presenting this to the user. This might involve the selection filter, but this too is in some need of redesign work, perhaps finding a way to combine it with the "Select" right-click menu, integrating the ideas of range and list selections, etc.

    • Difficulty: Medium
    • Skills: C++, Qt, QML, UI design
    • Suggested by: Marc Sabatella (@MarcSabatella)
    • Mentor: Marc Sabatella

    Chord Symbol Style Editor

    MuseScore allows you to select from several different options for the display of chord symbols, with some of the details controlled by an XML file. While custom XML files are supported, the process is cumbersome and not documented and really not an option for the average user. We could really use a WYSIWYG chord symbol style editor to allow a user to specify for herself how various chord symbols should be displayed. One was partially implemented many years ago but never incorporated into the program. It was limited in that you needed to specify each and every chord symbol separately - so C7 and C9 needed different customizations, as did C7b9 and C7b5, etc. A good style editor should be more rule-based, building on the semantic structure of a chord symbol and allowing a user to quickly specify rules to be followed by default but also individual overrides for specific chords. Probably at least some of the previous code could be reused.

    • Difficulty: Medium
    • Skills: C++, Qt, QML, UI design
    • Suggested by: Marc Sabatella (@MarcSabatella)
    • Mentor: Marc Sabatella

    Woodwind fingerings

    While piano and guitar have easy to notate fingerings using only numbers, most wind instruments still use drawings to represent fingerings. There is currently various plugins that implement in a not-so-user-friendly manner that ability for very few instruments. Some free fonts, like the fiati font (source here, demo here, include glyphs for a lot of instruments. These could be used as a basis (exporting the base diagrams as svg and using them as base). This new fingering element would work very similarly to the existing fretboard diagrams, which means keys could be toggled pressed or not pressed with a click.

    • Difficulty: Medium to Hard
    • Skills: C++, Qt, QML, UI design
    • Suggested by: Marr11317
    • Possible mentor: Yet to be determined

    Export Metronome Sound

    There have been user requests dating back some time (https://musescore.org/en/node/154666) to add a feature that allows users to export audio with the metronome sound included. The current workaround is to insert some sort of percussion part (ie. wood block) and use it to make a click track. I'm working on a plugin to automate this process for the 3.6.x versions of MuseScore; however, I think there could be an "Export with metronome sound" checkable option implemented in MuseScore 4 when users go to export a score as mp3, ogg, etc.

    • Difficulty: Easy to medium
    • Skills: C++, Qt, QML, UI design
    • Suggested by: Dominic Occhietti
    • Mentor: TBD

    Smart Tempos

    A tempo element is made up of text and/or a metronome marking. Examples:

    • Allegro
    • ♩. = 120
    • Allegro (♩. = 120)

    In MuseScore 3, the entire tempo element is editable text, including the metronome marking, which makes it very easy to create a corrupt tempo that doesn't work during playback. In addition, the "BPM" field in the Inspector always sets the tempo in terms of quarter-notes-per-minute regardless of time signature, rather than using the natural beat unit (e.g. dotted-quarter in 6/8). When a score is saved in MuseScore's MSCX format, the tempo is converted to quarter-notes-per-second for no apparent reason.

    In MuseScore 4, we would like to make the metronome marking separate from the text part of the tempo. In the example above, users would be able to edit the "Allegro" text by double-clicking on it in the score, but the "(♩. = 120)" metronome marking would have to be edited via the Inspector or a special pop-up that would appear when the user single-clicks on a tempo marking in the score. There would be an option to hide the metronome marking to create a purely textual tempo, but the metronome marking would still be used internally for playback purposes.

    Tempo_popup.png

    The metronome marking would be saved in the MSCX file in the form of an equation, such as:

    <Tempo>
    <equationVisible>1</equationVisible>
    <bracket>auto</bracket>
    <text>Allegro <equation>[4.]=120</equation></text>
</Tempo>

    An advanced implementation would give users the option to edit the equation directly within MuseScore. This could provide a means to enter more exotic tempo markings, such as ones with tuplets in the metronome marking, or multiple notes tied together. This advanced equation syntax could be implemented as an extension if time is available at the end of the project.

    Additional consideration to perhaps support markings as ♩. = ca 100

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

    Rubato: ritardando and accelerando

    There have been user requests dating back 10 years for playback of accelerandode and ritardando (#9383: Rubato: ritardando and accelerando).
    There's currently a plugin for this, https://musescore.org/en/project/tempochanges.
    But this should really be a builtin function, similar to crescendo/diminuando.

    • Difficulty: Easy to medium
    • Skills: C++, Qt, QML, UI design
    • Suggested by: many many users
    • Mentor: TBD

    Mixer & Tracks

    Musescore Folder Idea - Other Track Types and Switches.png

    Hello. A while ago, I created a series of descriptions and illustrations suggesting interesting features that could be implemented into Musescore 4's mixer design; the links to those posts are listed below. Since I am not part of the development of Musescore 4, I want to emphasize some assumption that I made when creating these concepts. These assumption includes that MS4 will eventually allow Audio / Midi recordings, importations, and automations; and it will allow 3rd party plugins such as EQs and Compressors.

    *My apologies for writing this post as first person (if not appropriate for this feed); I couldn't come up a different method to authentically address this.

    Comment Links:
    1. Initial Post - https://musescore.org/en/node/305002#comment-1033813
    2. Grouping - https://musescore.org/en/node/305002#comment-1033860
    3. Mini Mixer and Other Tabs - https://musescore.org/en/node/305002#comment-1034079
    4. FX Control - https://musescore.org/en/node/305002#comment-1034352

    • Difficulty: Medium +
    • Skills: C++, Qt, QML, UI design
    • Suggested by: SketalDaz (@SketalDaz)
    • Mentor: TBD
    • Design support: TBD

    Piano Roll Editor

    Important: The internal team is still considering whether this is viable as a GSoC project. You are allowed to submit multiple proposals, so if you apply for this project idea, we recommend applying for something else too.

    MuseScore 3 has a Piano Roll Editor (PRE) that can be accessed by right-clicking on any staff in the score. A piano roll is a simple graph of pitch against time, which is familiar to users of sequencer-type programs. MuseScore's PRE also includes a graph of velocity against time, which is useful for adjusting dynamics. The PRE allows for detailed control of playback without affecting the appearance of notation in the score. The PRE needs to be reimplemented from scratch in QML before it can be ported to MuseScore 4, where it would become the starting-point for a full sequencer implementation sometime in the future.

    The current Piano Roll Editor is poorly designed and overloaded with functionality that is not strictly necessary. The internal team will assist the student in coming up with a new design for MuseScore 4. At a minimum, the new PRE will simply provide viewing of pitch and velocity graphs against time, but no editing capabilities. Ideally, the student would implement editing at least for velocity. Full editing for note duration and pitch would be enabled only if sufficient time is available at the end of the project.

    • Difficulty: Hard
    • Skills: C++, Qt, QML, UI design
    • Suggested by: Peter Jonas (@shoogle)
    • Mentor: Vasily Pereversev
    • Design support: Martin Keary (@Tantacrul) and Jessica Williamson