Electronic music is sounding less expressive. This is partly due to the tools and techniques we use to make it. We are moving further away from our natural interactions as we are drawn closer to the modern alternatives such as the mouse and touchscreen. This project looks at a tangible solution to strengthen the relationship with the tools we use to create music and the interactions we use to perform it. OCTAVIUS is a wireless performance platform which encapsulates creative software with a physical product. It incorporates basic interactions with minimal design to encourage creative expression.
Password : honors
Firstly, It’s worth mentioning that today I solved the largest issue I had with the network and the product itself. The master device was just receiving too much data from the slaves. It was dropping packets of information and at sometimes rendering the platform unusable. The reasons behind this problem can be found here : Stop Delaying Traffic!.
I coded a way round the problem. This stops the devices sending every data change and only if the sensor changes by more than 2 values (typical jitter amount in the sensor). This means less responsiveness. Thankfully, this was picked up by MAX and I modified the code in MAX to allow for this inconsistency and to update the values accordingly. Whilst not ideal, it’s unlikely this could ever be noticed by the user.Moving forward…
Today I finished assembling all of my devices. This was the first time I was able to test all 8 devices together.
I had a few small parts to print and assemble, the last force sensor for example.
The assembly is very straight forward. I attach a switch to the enclosure then solder the battery into the circuitry and switch lugs. I bring the ‘sandwich’ together and screw fix from the bottom whilst snapping the enclosure into place. This gives solid and flat devices. The battery rests perfectly flat on top of its charger with no for isolation due to the casing of the batteries.
I had 8 solid devices. A celebration in itself.
Here is the initial testing with all 8 devices with all 8 devices.
Password : octaviustesting
A few issues arose during the testing, mostly that some button presses weren’t registering. This issue comes from each slave themselves. I know what is causing this – I’ve boosted the sensitivity too high. This is a simple fix in which I will update on the arduino code tomorrow.
I wish I could update the arduino via the xBee radio. Unfortunately, it means a partial disassembly of each device in order to update them. I have plans for this in the future. The arduino is an excellent prototyping tool, though it has its constraints. A built-in serial USB interface in a small form factor, like what I need for these devices, is one of them.
Another issue was that I found is the devices having difficulty booting up from the battery at times. Even on a full charge I had noticed this behaviour before. This isn’t a huge issue. I can boot them from the power cable, disconnect and then run them from the battery that way.
I’ve been speaking remotely to one of my testing participants (who will also be performing for my video). We were discussing the current interactions with page changes and the separate orientation from each device for each page.
The current software allows 4 pages of 8 assignable controls using the orientation values. This means there is the potential for 32 assignable parameters on synthesisers or music software for examples. This is an incredible amount and in my opinion, overkill. This was apparent when I performed a short demonstration to a group of interested creative students and staff from the university. I built the software from scratch and know all of its functionality inside out, yet I had forgotten I had to change back to the drum page to change a parameter on one of the drum sounds. There was a moment when I was engrossed in the performance that my natural behaviour and assumption was to turn the dial to change said parameter.
When bringing this up with Oliver, he was unsure of what he’d prefer and I don’t think he’ll know until he uses the devices for his own performance.
With this uncertainty, I believe it’ss only fair to offer the user the option. Some may need the 32 assignable parameters, whilst some may prefer the constraint of only using 8. Tonight I am updating the software to allow both to offer that freedom to the user. This also means I can test both will Oliver on Wednesday.
I’ve been working on a ‘push’ or ‘snap’ to fit enclosure for the individual devices. This is to enable quick assembly and a solid tight fit for the individual components. With the addition of the spacer as mentioned in a previous post, this method for assembly is growing closer to its finale. When assembling this enclosure for one of the devices today, I now have an issue with inconsistent readings from the pad sensor. This inconsistency is coming from the pads themselves due to the failed castings of the pads. I’ve had to cut around a 16-grid pad block supplied by Native Instruments. This means that the bottom of the pad has an uneven surface which is knocking the snap to fit faceplate off angle, meaning that if I put pressure onto areas of the faceplate, it will slightly knock out the faceplate and put an uneven amount of strain ont0 certain parts of the pads themselves. I’ve tested several iterations of a new spacer to solve the issue and I’m now looking at a recessed ‘lip’ on the underside of the latest version.
This acts as a brace for the lower pad and creates an even surface meaning that each device will have equal pressure and sensitivity. Once printed I will be able to test this in the enclosure and finalise the physical design.
Whilst testing the assembly of the devices I encountered a problem with responsiveness on the pads.
The current construction of the upper layer of the device is as such –
The pad sits within the faceplate and has a layer of around 2mm underneath of soft silicone. It’s worth noting here that if this underlayer covered the whole of the faceplate,this issue wouldn’t exist. Unfortunately due to the pads being cut from a larger grid of pads (due to the failed casting of my own pads), I’ve had to cut away most of the excess. This means that when the faceplate is fitted into the enclosure, any pressure on the faceplate will cause this underlayer to protrude into the hole, causing no contact with the force sensor.
I knew that in order to solve this Id have to create more space between the faceplate and the sensor. Exactly how much is determined by this underlayer of silicon (around 1.5mm). 3D printing allowed me to quickly print a 1.5mm spacer to fit under the faceplate. This adds another layer of the ‘sandwich’ which counteracts the issue with the button pad itself.
A quick test with this spacer shows that I now have a responsive button pad with adequate spacing for each layer.
And the ‘sandwiched’ upper layer with working pad –
I’ve not written much about the software I’m creating. Initially, it was a side project to compliment the hardware of this project. It began as a simple parser and router for the data. The hardware was intended to be the main product for presenting for my examinations. Either way, here’s an issue that appeared today when doing some testing.
When hitting one of the pads on the devices, I was getting a constant re-trigger until I let go of the pad. To put this in context, I had a rolling kick drum that would repeat itself, even with a tiny and fast hit.
I analysed the code of the hardware to check for and mistakes I had made and I realised what the issue was. The code is set up that if either sensor or pad changes it value or state, then to send a packet.
These packets are all the same, it contains a device identifier, the sensor value, and the button value.
So if the button is pressed but the sensor value is constantly changing, the software will continuously receive a value of one for the button meaning ‘hit’, ‘on’ or ‘play that sound!’.
Thankfully, there is a simple fix for that within MAX. The [change] object will not allow an integer through unless it is different from the last one received. Hooray!
Initially I wanted a simple on and off switch integrated into the circuitry of each device in order to cut power and preserve power when not in use. This is logical and is seen in almost all of our wireless or portable appliances.
Whilst discussing this with Ali Napier at djcadMAKE, he suggested powering down the microcontroller using code to put it into ‘SLEEP’ mode. This was intriguing and also meant looking into ways in which we can wake it up using the interactions possible with the device. I set out to do some research about ‘SLEEP’ mode and found some interesting facts. I would be able to interrupt sleep using the sensor or button pad as mentioned before, and also I can control how long until the device would sleep for. I looked at the code, it was real simple to integrate and there was a library for it! This was exciting and I went ahead and created my circuit boards with the ‘Sleep mode integration’ checkbox low on my todo list.
Fast-forwarding to the present as I reached this checkbox, powering down the arduino into sleep mode wouldn’t save near enough power as I had hoped. It was likely I’d still have to charge the batteries very frequently due to them dying (mostly because of the general power consumption of each component). This means I need to reconsider using a simple switch.
I’ve bought some surface mount switches ( I wanted discreet) and some through hole switches for which Im still waiting to arrive. These can be connected to the + pole of the batteries and will offer a simple solution to my powering down issue. The downside of adding this switch directly to the battery (before it reaches the charging component) is that I cant charge the device whilst it is turned off due to the PCB design. This is a simple fix for post-graduation development and on the next iteration of the PCB design.
Onwards and upwards (or powering downwards?)….