Reflective summary

This project has been an interesting challenge. We were purposely ambitious with our aspirations and pushed ourselves to try and create a product that we were proud of. I have gained several valuable skills throughout, covering each of the learning outcomes I wanted to achieve.

Beginning with market research really helped give an idea of what competing products offer, what customer base they are aiming for and highlighted gaps in the market. We noted that while there are a plethora of high-quality drum suites available, many of them such as Superior Drummer and Slate Drums cater to hi-fi productions. While these plugins contain samples recorded in some of the best studios in the world with world-class microphones and hardware, when trying to create a more lo-fi, gritty sound often found in punk, extreme metal and various other genres, it can feel out of place contrasting super polished high-quality drum recordings with the rest of the mix. One of the few competitors that offers something similar to what we wanted to create is Ugritone’s KVLT drums and while this serves a similar audience as our own, we wanted to make our own take on this. It would have been useful to conduct some primary customer research to inform our feature set, unfortunately, due to time constraints this was not achieved. We referred to various articles and forum discussions to gain an idea of peoples opinions of competitors as well as what features are desired, however creating a survey or offering up our Kontakt instrument for testing as an open beta would have been valuable in the development.

The most challenging aspect of the project was the creation of the Kontakt instrument itself. Recording the drums and editing the samples was relatively straightforward as I have previous experience recording drums and collating sample libraries. Importing the samples into Kontakt and assigning them to the keyboard was somewhat challenging as we had multi-sampled each instrument, meaning we had to assign velocity ranges to each sample on each instrument. This was time-consuming but not too difficult. The real challenge lay in the coding of the GUI. This required me to learn how to use Kontakt’s proprietary language, KSP, in order to create a working user interface. This by far was the hardest part of the project. With limited previous coding experience, there were many teething pains getting to grips with how KSP operated. In addition, being a very niche language, resources online were somewhat limited and much of what was available assumed a far higher level of knowledge than I possess. If I were to approach this again, time spent learning core concepts of scripting in general as well as practising with KSP before undertaking the project proper would have been immensely valuable.

Despite these difficulties, I feel I have gained a solid basic knowledge of how the backend of Kontakt operates and feel that with further practice and research I will be able to implement all our desired features. When planning our project we set out a large set of desired features we wanted to implement. When doing this we organised these by those we wished to have in a working proof of concept and those that would be reserved for future implementation. In hindsight, while this was good foresight of the complexity of development, it would have perhaps been pertinent to aim for an even more restricted feature set for our initial prototype. with further research, it became apparent that some of the key features we wanted such as assignable multi-channel outputs and individual bleed controls for each mic would be far more complex to implement than initially thought. To manage this we further limited our initial feature set to the absolute bare minimum. We created 4 separate groups: kick, snare, toms and cymbals which had volume faders assigned, allowing a basic mix to be created. In addition, we added a global reverb. In later versions, we would like to have reverb assignable to each individual track, but the current state allows the user to use the sample library in their DAW of choice with limited functionality.

With regards to difficulties I had during the coding process, it would have perhaps been better to use a different platform for our sample library like Max For Live. I have some familiarity with Max and the visual aspects of its workflow make it easier to organise the plugin. The main drawback to this and the reason we decided to use Kontakt is Max would make it Ableton exclusive and we wanted it to be useable by as many people as possible.

Project management skills were key to the success of this project and as a whole, I feel I was successful in the management of this. I booked the studio for recording well in advance, allowing us plenty of time to focus on the development side of the project. Working to a deadline meant that decisions had to be made in regards to what features we wished to keep. While this deadline meant we couldn’t submit a product with as much functionality as we had hoped I feel this experience has given me an important insight into the prioritisation of different aspects when undertaking a project as well as being analytical and using previous research to inform decisions that were made.

To conclude, I feel that while several challenges were presented to us during the course of this project I feel that we have been successful in what we set out to achieve. With a clear roadmap of future features and a solid base to work on, this project could potentially become a fully fleshed out drum suite with a wide range of user customisation. I will be continuing with the development of this as it will be a valuable resource for learning as well as an important professional skill. Additionally I feel the research and management skills I have gained will be immensely important going forward with my professional development.