Musicparrot

Music education platform

Musicparrot homepage

What is it ?

Musicparrot was an idea pitched by Nick van der Wildt, eventually leading to a total of five individuals (including yours truly) excited enough to pursue this idea as a startup. SPOILER: Work on Musicparrot has sadly been abandoned, this page is for historical purposes.

Musicparrot in a nutshell: "An online music education platform. Musicparrot provides video-based lessons to those who are willing to learn to play an instrument.".

Musicparrot would also feature direct student - teacher communication in order to provide personal feedback on a students progress, as well as a gamified part where students could compete with each other for their achievements.

Target audience

Musicparrot was aimed at students who are either unable to take lessons with a physical teacher (e.g. with regards to time schedule) or prefer to learn on their own, in their own time and only pay when they are actually taking a course instead of on a (mostly unused) subscription basis.

Musicparrot also catered to teachers. Teachers would be screened (to ensure quality of both video and lesson) and could enroll in a program in which they would earn money for each lesson a student would watch.

The added benefit of being a platform for teachers is that this allowed the Musicparrot platform to branch out globally by offering content in multiple languages.

Musicparrot fullscreen video lesson

Screenshot of an example guitar lesson, accompanied by animated guitar tab.


A custom music language

Different instruments use different transcriptions: where pianists, woodwind and horn players would be accustomed to reading musical score in musical notation/stave, guitarists and drummers would prefer the format known as tab. As such, can we find a common tuition language that solves the conundrum of being usable for multiple instruments while at the same time not breaking any known convention?

For this purpose, Musicparrot came up with its own (colour coded) schemas that could be used across instruments. This to the advantage of people who are switching/learning new instruments by giving them a visual aid reminiscent of what they already know. New players could quickly adjust to the language and distinguish between notes, chords and chord flavours visually (also see screenshot of guitar lesson above).

Under the hood, the Musicparrot platform would use a single language for all music, regardless of the instrument it was intended for. While you can argue that there are a plethora of universal digital music formats (such as MIDI), for the benefit of visual representation it became apparent that more meta data is required. For this purpose, the "Musicparrot Format" (MPF) was created.

MPF could be converted from a variety of input formats (e.g. MIDI, ABC, ASCII) allowing an immediate import of projects created using standard music notation software. This to allow teachers to export their projects directly onto the Musicparrot platform and have their lesson be accompanied by visual cues automatically.

Multi platform web client

Musicparrots prototype was in an advanced stage and could cater for desktop, tablet and phone platforms with the only requirements being a web browser and a broadband internet connection. Even legacy browsers were supported by the use of Flash shims (you'd be amazed at the need for those in 2015!).

The aforementioned MPF format had been developed, as well as the applications to view either guitar or piano notation next to a video lesson, with the Musicparrot colour coded schema and lookahead.

Musicparrots styleguide had been translated into a reusable component which would ensure that the brand would present appropriately across a large range of configurations.

Musicparrot tablet promo image

Technologies used

Musicparrot was written using .NET, JavaScript, ActionScript 3, PHP, Amazon Web Services (EC2, S3, Cloudfront)

The benefit of starting a venture with software engineers that have been honing their craft for a while, is that you have a great head start in test coverage, build automation and continuous integration/delivery.

Each code change would result in an automated deployment bringing the latest developments live. Whether it is better to actually have a company first and worry about these peculiarities later is a different subject (!).