World Music's DIVERSITY and Data Visualisation's EXPRESSIVE POWER collide. A galaxy of INTERACTIVE, SCORE-DRIVEN instrument model and theory tool animations is born.

Wednesday, September 21, 2016


The Platform Provisioning Process

World music instrumentation and the corresponding theory tools are a vast and (at least superficially) complex field of study, but one that can be dramatically simplified, reconciled and unified using data visualisation techniques.

Keeping in mind our primary goal of generating social value, the full and long-term provisioning of the aggregator platform is only going to be possible with community involvement. Here a short visual guide to the main steps envisioned in this process.

Underpinning provisioning are mechanisms of commons-based peer production (CBPP) as exemplified by Wikipedia, perhaps most important among these the related issues of reward and project success. Big, brave, open-source, non-profit, community-provisioned, cross-cultural and cheerful in the attic crazy. → Like, share, back-link, pin, tweet and mail. Hashtags? For the crowdfunding: #VisualFutureOfMusic. For the future live platform: #WorldMusicInstrumentsAndTheory. Or simply register as a potential crowdfunder..

Provisioning Process

This is an evolving topic. What follows is simply a first cut -a suggestion- as to how community provisioning might function.

Commons based peer production rests on three principles.

  • First, the potential goals of peer production must be modular. In other words, objectives must be divisible into components, or modules, each of which can be independently produced. That allows participants to work asynchronously, without having to wait for each other's contributions or coordinate with each other in person.
  • Second, the granularity of the modules is essential. Granularity refers to the degree to which objects are broken down into smaller pieces (module size).[7] Different levels of granularity will allow people with different levels of motivation to work together by contributing small or large grained modules, consistent with their level of interest in the project and their motivation.
  • Third, a successful peer-production enterprise must have low-cost integration—the mechanism by which the modules are integrated into a whole end product. Thus, integration must include both quality controls over the modules and a mechanism for integrating the contributions into the finished product at relatively low cost.
Foreseen are two more or less parallel processes applying respectively to internal and community-submitted code.

o Platform-internal (closed source), pink in the diagram below
o Community provisioned (open source), blue.

These will be, in all but the degree of platform/framework access, identical, yet for (I hope) obvious reasons separate.

Music Aggregator Platform Visualisation Provisioning Process. #VisualFutureOfMusic #WorldMusicInstrumentsAndTheory
Aggregator Platform Provisioning Process

Animation code (that which runs in the animation window) is de facto open-source. This includes example animation or template code provided by any platform-own development team.

Music Visualisation Aggregator Platform Open Source Animation Panel. #VisualFutureOfMusic #WorldMusicInstrumentsAndTheory
Open Source, Score-Driven Animations Panel

Process Description

It makes sense to approach both planning and cooperation from a visual perspective.

All open source code will be subject to first community and then team/domain expert scrutiny and acceptance prior to it's integration into the platform itself. The primary goal is to bring, under a rigorous reuse regime, robust base instrument models and theory tool versions online which can then be progressively extended and improved on.

Community then Team/Domain Expert Approval. #VisualFutureOfMusic #WorldMusicInstrumentsAndTheory
Community then Team/Domain Expert Approval

Familiarity with in-browser (and hence close-to-DOM) development tools is more or less essential. These are clear, well-documented, free, and powerful. We will be able to make recommendations, but in as far as the results conform to expectations, community members are free to use any development environment they choose.

A simulator (to be provided) is used to feed music data derived from MusicXML (as if from a score during playback) to the new animation at speeds under user control.

Example Git Workflows

Code submissions will be made via open source code repository such as Github using it's git workflows.

These will then run through a secondary, platform test phase check behaviour and performance are acceptable, but also ensure platform and user integrity and security are not compromised.

On passing a module test phase, the code is released for integration test. Here, the primary goal is assuring platform stability under a range of operational conditions. Successfully passed, the code is freed for integration to production and any recovery systems.

In this sense, it is important to see each instrument family as complete ONLY when all possible musical configurations have been incorporated. This is analogous to the mountaineer's goal of arriving not just on the summit, but moreover back at base camp with team and health intact.

Code Templates

Potential Crowdfunder?

Pre-Crowdfunding Registration (* indicates required)
Email Format

Template code will provide the standard interface shared by all animations aspiring to mutual, dynamic configuration via (for example) a radar chart or slider set.

The musical qualities configurable through this interface can be split into two nominal groups: those gravitating towards abstraction (can be directly used in theory tools, no information redundancy), and those associated more with instruments (with possible information redundancy).

To the former belong parameters such as number of notes or tones per octave, and the temperament or intonation system to be used.

To the latter belong the number of channels, rows or courses, general layout, tunings and effective scale length.

Example and/or template animation code will be sufficiently well documented that a developer can use them as a base for own work.

Any community member is free to extend a template for use in a new animation to be submitted by means of an open source code repository. In this way, the code is available for reuse in other contexts, thereby raising it's primary, ie social, value.

Code Expectations

Cross browser compatible (IE 9+, Chrome, Safari, Firefox, Opera) and cross platform compatible (Desktop, Tablet, Smartphone, ER or VR headsets).

A significant challenge, perhaps, but one which is progressively succumbing to advances in web stack standards and technologies.

Buzzwords? Web components, Material Design, Web Animation (new standard), and some well established technologies, such as WebGL and our old friend D3.js.


o Continuous delivery model
o Initially, delivery cycles for each main family of instrument and theory tool

Once the provisioning model has been proven viable, we can move to the parallel production described in the three principles of commons-based peer production.

We can expect one of the first steps to be to identify what modifications are required across various classifications such as genre, instruments and theory groupings, and to cluster these by implementation cycle.
Circular Non-Ribbon Chord Diagram with Categories and Edge Bundling
Non-Ribbon Chord Diagram w. Edge Bundling

Here, for example, we see a series of projects clustered by categories affected (category A, for example, might represent 'Genre').

In this way we have a clear picture of our rollout priorities and (with a little extra labelling) timeline.

This could, indeed, be made dynamic in that projects are progressively added and removed depending on their active status: effectively a continuous release pipeline.

Visualisation Models and Tools

Theory Tools menu. #VisualFutureOfMusic #WorldMusicInstrumentsAndTheoryInstrument Models menu. #VisualFutureOfMusic #WorldMusicInstrumentsAndTheoryTake a look at this blog's Instrument Models and Theory Tools menus (L & R). These will give you some idea of the modelling scope of this project.

o application across the entire spectrum of instrument or theory tool configuration.
o code reuse is paramount.
o code clarity and simplicity. What can be understood can be improved.
o by default, unsupported configurations (instruments or tools) provoke a warning.
o changes at a lower model level cause a refresh at all higher levels.


o Javascript minimum ES5, where possible ES6 compliance.
o given it's flexibility and DOM-affinity, D3.js is the library of choice for data-driven elements
o D3 is not a compatibility layer, so if your browser doesn't support standards, tough shit.
o Compatibility across main platforms and browsers
o In particular, no jQuery, bloatware, unstable and obsolete platforms


Modelling Layer by Layer - as with the Original

o documentation should -as with the animations themselves- primarily be visual/graphical (as a direct aid to cross-cultural understanding). The less text the better.
o these diagrams should mirror the physical layered construction - an 'exploded view' is perfect
o indicated library calls (shown as layer labels) resulting in the modelling of a given layer should correspond 1:1 with the library's API documentation.

o good for first-cut diagrams is the free online tool


As explained elsewhere, I envisage a more or less community managed, moderated and provisioned system with social value, accountability and transparency at centre. With a mix of commons based peer production and community-commissioned work, I hope it will challenge legacy revenue-driven business models with a social value driven one.

This is not to say community commissioned should go unpaid: for challenging implementations, there is a case for staged financing through a combination of crowdfunding, micropayments, grants and donations, with core work carried out contractually by domain experts.

Whatever the route taken, the provisioning process will be well suited as playpen for students of graphical development for the web.


Last but not least, the driver scores. A few observations:

o there are many MusicXML score collections worldwide, covering a large range of open source (cultural heritage) works.

o While the number of cultural works featured is limited, platforms such as Noteflight are helpful in re-democratising music. Open source material is quickly scored and distributed, and the resulting MusicXML as suited as any other to usage within this platform

o it would be helpful if a solid open-source exercise collection applicable to a wide range of instruments were established. These should perhaps emphasise the interval and modal qualities of various world music genres, and act as a stepping stone to musical virtuosity.

o For further information on anything relevant to notation, try this forum.


About Cantillate -

Autodidact. Laird o' the Windy Wa's. Serial Failure with Attitude. Bit of a Dreamer..

Comments, questions and (especially) critique welcome.