Throughout the last 5 weeks, I've spent a multitude of studio hours recording my cello, normalising my samples, editing and exporting them, coding the synth to work, and then finally working on my essay.

As can be seen, I used multiple microphones to record my cello, so as to ensure that I had more than one set of recordings - in case of a bad lead or microphone.

After these samples were recorded and I'd spent time manually exporting them through Ableton, I looked through some of the DS store instruments, as well as the developer manual, to learn the basics of instrument coding, and see what I would have to do.

This is what the coding for the sample group looked like - and this designates the MIDI note that each sample represents - numbering from 1 to 127.

This block of code activates the UI for the amplitude envelope, which allows us to add (shown in the second line) an attack (A) vertical slider, which allows us to modify the attack on the synth UI screen. There were separate blocks of code for each part of the ADSR, as well as the other effects, which is shown below.

This block of code allows us to modify the resonance on the synth UI screen, which is designated as a 'float' bar. This means that as opposed to being a vertical slider, these effects will be shown as a horizontal float. This was important for optimizing space in the home screen, and providing variety.

Over the last 5 weeks, since our study break finalised the first half of our subject content, I've been working towards this final project, delivering a coded cello synth, and this project entry which defines the steps that I've taken along the way. There were a lot of changes that had to be made, errors that were encountered, countless hours of exporting Ableton audio files and assorted head-smashing into the desk, but in the end I believe that I learned an absolute boat-load of information in regards to coding and multi-sampling, as well as microphone specs, research techniques and much more.

Firstly I'll discuss what I learned, and what I could do better next time.

As this was my first time creating a proper, from scratch multi-sampled instrument, I had little idea where to go at the start of the project, and weighed up all of my options. While coding on Decent Sampler would take more time and be a much heavier workload, it would allow me to create something that's entirely mine, and doesn't need other (usually paid) software to be able to use it, e.g. Ableton Live patches, Bitwig synths, etc. Using Decent Sampler, I would be able to choose what effects were built in, what names they had, the colour scheme, and other UI settings that would be otherwise not possible to edit.

The next part that I had trouble with was my recording; I wanted to ensure that my cello sounded like it was recorded professionally and in a well-treated room, however I didn't want to use a contact mic, as I feared it would sound too generic, and too much like software-created cello instruments. I wanted it to have a bit of character, to be able to hear some string noise, a clunk here or there, but not sound too messy that it seems rushed or not done correctly. I researched five different microphone types, taking three into the studio, recording with two, and eventually only using one as my actual recordings that would be loaded into the synth. One thing I noticed in this process, which I've noted in my previous assessments, is that the Rode NT2-A is just a one-of-a-kind microphone, and can record such a wide variety of frequencies and tones. In our previous recording assessment, Loki, Anna and I recorded cello, male and female vocals, percussion, guitar and whistling entirely through the Rode NT2-A, and it always sounded the most clear and precise when we'd test out recording with more than one microphone. This is why I chose to use the Rode, as while the other microphones sound good in theory, and have the correct frequency and transient responses to clearly record strings, the Rode projects such a natural sound back into the DAW.

Moving forward, after the first two sessions I had all of my recordings finalised, and in my next session I exported them all out of Pro Tools, and into Ableton, which I felt I had a bit more technical prowess in, and this would help me work more efficiently. I was able to work extremely fast to manually chop these samples up, which I did in two steps; the first being to roughly chop each sample to the same size, and add a short crossfade at the start, and a decent one at the end, to prevent any spillage from the next note that was recorded, or footsteps or breathing from myself, and the second was going through and speedily exporting them. This is where I made my main mixing mistake, as I was confident that I didn't need to actually listen to the audio all the time, and I knew I would work faster and get less distracted if I put on some ambient music in my headphones, and only made sure every 5 or so notes that I hadn't skipped a note name and was ahead or behind somehow. While in my head this worked well, what I didn't realise is that if I didn't have the track solo'd, it would still export the sound from every single track that was playing at the same time (which was my other velocity layers and pluck filter sampler). Somehow I didn't realise this for almost an entire session, and only when I went back to finally listen to my 'finished' samples did I notice that there was more than one track playing for almost the entirety of two fully exported velocity layers. I left the campus at this point, my brain was mush.

Luckily, it didn't take too much time to fix these mistake, as it was only about 1 in every 6 or 7 that had a mistake, as opposed to almost all of them that I originally thought, and I smashed this out in the next session, before moving onto the coding. The coding proved to be quite fun, and although I made my fair share of mistakes and overlooked a few things, it is definitely something that I would like to pursue in the future. I could immediately relate it to coding in plug-ins or commands to my Minecraft multiplayer server back in the day, in which I would have to write 'code' in order to give people certain playing privileges and permissions, although it was nothing compared to the complexity of what I had to do for this assessment. Attention to detail was really the killer in regards to this, as all it took was one misplaced '>' or '/', or even a space in the wrong spot, and the code would entirely not load, and wouldn't tell you where the mistake was.

It was in the research that I really started to make some connections when it comes to signal flow and the similarities between older techniques of recording and sampling compared to what we do today. When starting this essay, I was unsure of how to relate it to my project, however I realised that as long as the essay was primarily related to the creation of audio recording, it would be perfect. Although this seems extremely broad, there were key points throughout history that got us to where we are today in regards to audio recording and multi-sampling. While I won't go into it as the essay is embedded above, I found it extremely interesting that the Beatles created what we call a 'sound-for-picture' project in the 1960s, 30 years before even the most rudimentary DAW was created. The fact that these huge artists had this vision to try and complete a project in the way they did, using technology far inferior to what we have today, and came out with a finished product that good really makes you wonder what they could've done if they were only up-and-coming in the modern day.

Now I'll talk about some of the mistakes I made throughout the project, and how I (with help from Kevin, online tutorials and the DS manual) managed to work through it.

Initially, when I thought about creating this synth, my mind immediately went to Bitwig, in which I could use the fancy UI to load my samples in, create zones, velocity layers and a pluck filter, and export this into a convertible file that could load straight into Decent Sampler, which would then do the heavy lifting for me by writing the code in the back-end. Once I had recorded my samples, edited and exported them, I was ready to begin with Bitwig, as I was going to purchase the 16-track edition, which was only $150 AUD as opposed to $500 for the full version, which I couldn't really justify spending the money on. However, as I was going to buy it, Loki told me that he'd seen on the website that you couldn't use the poly-grid or the multisampler with just the 16-track version. I was immediately relieved that he'd told me this and I hadn't wasted my money, however I realised now that I had to manually code these samples in myself - which I hadn't entirely ruled out, I was just hoping that I could do a good chunk of it automatically using Bitwig, and clean it up manually by typing in the code. At this point, I downloaded a few Decent Sampler instruments off the DS store, as well as using the developer handbook, and seeing the back-end of some of Kevin's instruments helped me out too.

After two studio sessions in the audient, I was confident that I'd written the basic length of code that I'd need to get the synth loaded, even with only 1 bank of samples, just so that I knew it worked, and when I went to launch it, I received an error that read, "ERROR, XML WAS NOT PARSED FROM CODE", and the app would close down. Kevin and I spent a good chunk of that week's Wednesday lesson trying to work this out, copying part of my code in and out of his instruments code to see if certain parts would launch while certain parts wouldn't, and we narrowed it down to being the chunk of code that made up my sample group. We found this out by copying all of my code (bar the sample group) into the code with Kevin's samples, and launching it, and it worked fine. From here, Kevin was able to take it away from me for a few hours and ping me back later on google chat that he'd managed to load the samples into his Bitwig and spit some out, and I was now at least on the right track with a 'template' for my cello code, in which I could examine what Bitwig had done automatically, and try to reverse engineer that to what I needed. This worked out well, as I was then able to work out some rough group rules that I wanted my samples to follow, e.g. their position in the round robin sequence, the loop start, fade and end, and by the end of that Thursday I had manually coded in two of the round robin sequences, and was ready to give it a whirl through DS and see if it worked. Unfortunately for me, we now faced a second hard error, which read, "ERROR, 114 SAMPLES NOT FOUND", even when directed to the exact folder that the samples were stored in. After messing around for the rest of that day, I was no closer to fixing this problem, even though I had tried changing the naming convention, as well as combing through the entirety of the sample group code. Although I had found a couple of spaces where there weren't meant to be and a few non-closed off lines, the same error still plagued us.

The next week, I reconvened with Kevin to get his assistance with this error, and we were able to work out that there was something specific that we had to do with the round robin sequencing, and this was why the samples would not load. We also thought for a bit that it was not working due to the files being named and transported to windows, before being put back into a mac, and perhaps the directory files that iMac's create automatically to find certain files weren't actually created. However, as we had already seen the back-end code of one of the DS box harp synth's, we knew what had to be done, and were able to put this line into the top of each sample group, which specified which round robin these samples were, what the name of the group was, and how the samples would be randomized. I went away and experimented with this in my own time, and Kevin had a go at seeing what DS would do if the multiple round-robins were coded into Bitwig and then exported, and we had some success at this point! The synth would finally load, the effects worked fine, and the samples actually sounded good, which I was very surprised at, considering the huge mistakes that I made loading them up and exporting them. From here, I spent time in the studio during the last week (week 12) playing the synth, and determining which notes needed to be cut or faded with a finer touch, as opposed to just applying the same group cuts and fades to them. At this point, the Synth was finally complete, and I was able to play a short piece on it to demonstrate what could be done.

In regards to transferrable skills, I believe that this assessment has taught me so much about persisting with the workload, working with deadlines and problem solving. Throughout the project, I've had to work through hurdles, especially relating to the coding, as I had absolutely no idea how to do it when starting, and now I feel as though I've gained permanent knowledge that I can use in the future. While I doubt I'll end up as a coder, I now have the option to make my own instruments, right from the recording samples stage, to the coding stage, and everything in between. Furthermore, I feel as though creating a live instrument as a multi-sampled synth is far more difficult than sampling a drum machine or existing hardware synthesiser, and if I was able to relatively easily finish this project, then I shouldn't struggle so much the next time. On top of this, I was glad to be able to put my researching hat on again, and write a research essay, as Modern History was one of my best classes in High School, and we were constantly writing 50+ page long research booklets, complete with 3000-4000 word essays explaining the topic. Being able to have the freedom to do whatever topic I wanted was extremely helpful too, as I was already planning at some stage in this trimester to get in and record samples of my cello to make into an instrument, so as soon as this assignment presented me with options, I dove into that. Lastly, my constant liaising with Kevin has helped me with my people skills, specifically being able to explain what I want to do even though I don't know how to do it, and Kevin was more than happy to help me with anything that I needed. I was able to talk to him in classes and gain a general idea of what I wanted to do, and then go away and research it, either though the DS manual, YouTube tutorials or in the back-end of other DS instruments. Although I did run into some errors on the way, I was always looking for ways to get myself out of the trouble, before going to Kevin and asking for help.

Ultimately, I believe I've gained such a vast trove of knowledge, and have opened my own eyes towards things that I can do in my spare time, and things that I can work towards as a career. I really enjoyed this task, probably more than I'd care to admit, and will definitely be creating some more instruments before the years done; and my first point of call will be to create a cello plucking instrument, using the samples that I discarded from this projects' recordings.