Minuet – plugin architecture

Minuet – plugin architecture

Hi everyone!
As the title of this blog post suggests, the first evaluation has been successfully passed, the project accomplishing all the proposed goals. Thus, let me present you the progress I’ve done for the first evaluation.

  • The very first thing I’ve took care was allowing multiple-instrument visualization framework, by modifying the old core architecture of Minuet. Instead of the one and only keyboard instrument, Minuet is now providing an instrument tab bar, enabling the end user select the desired instrument. The tab bar is currently loading the instrument within the first tab as default. After I’ve discussed with my mentor, Sandro, I decided to keep the piano keyboard as the default instrument contained by the first tab. In order to keep all the functionalities available and a simple architecture at the same time, I’ve created an InstrumentView wrapper above all the instruments. Its methods are called by the core ExerciseView, calling in turn the methods that each instrument should implement.

2.gif

  • After changing the Minuet’s core in order to provide a multi-instrument framework, I started refactoring the piano keyboard view as a separate plug-in. Basically, for Minuet, a plug-in is nothing more than a bunch of QML files and a simple JSON file parsed in order to learn about the QML files’ location and load them dynamically in the instrument tab bar.

pi.PNG

The next goal was to install each instrument separately as a plug-in, besides all other Minuet’s plug-ins. Like any other KDE application, Minuet, keeps its data files into /usr/share/ file-system directory. Thus, this was the place where our plug-ins had to be installed; actually, the exact path is /usr/share/minuet/plugins/. Installing a plug-in is simply done by using a CMakeLists.txt file telling the build system where the plug-in files should be installed.

Plug-ins are loaded as follows: firstly Minuet searches for plug-ins location and if the search succeeds, it will iterate through each instrument’s JSON file, building a QJsonArray containing the plugin name and path. This QJsonArray is passed to the InstrumentView, setting the contents of the Instrument Tab Bar. Having all the tabs ready, the TabBar will just wait for a tab to be selected and a QML file to be loaded.

  • Having the multiple instruments framework and piano plug-in ready, the next step was to test and analyze the code for possible technical issues or bugs. Also, a general clean-up was required before submitting the code for the review and first Google Summer of Code evaluation.

 

These are the achievements I’ve met for the first evaluation. Let’s discuss now about the current progress for the next evaluation:

  • I wrote a proper and comprehensive documentation for the piano plug-in, enabling anyone to create his/her own instruments plug-ins and loading them dynamically into Minuet.
  • I started implementing a new instrument from scratch. As I am very passionate about guitar, I chose to integrate it into Minuet’s instruments suite. Thus, I have already designed the visuals for the Guitar plug-in and added it into Minuet’s instrument tab bar. Now, I need to link the GUI to the core, work on the guitar’s specifics and make the plug-in fully functional.

dupa.gif

In conclusion, GSoC proves to be a great experience thus far, being a pleasure to work on a project focused mainly on a subject I’m in love with: music. For further cool news, stay tuned!

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s