Now that the electronics are operational, the bike built and running, the parts assembled, it comes the time to shape the sound as desired.
I've decided to separate the different pads to different sounds. The drum pads are going to be bass drum and snare, the left button pad should trigger some kind of fat filling ambient bass sounds, the right button pad will be linked to keyboard chords.
These sounds will be rendered from Logic Pro. The PD patch will take the inputs from the bike, turn them into midi signal and send it to Logic. Logic will get the midi in different channels. Each channel will be a software instrument. The specificity of each instrument will be preset to the project. There will be, however, variables to each one. These variables are taken care of via a Lemur patch. Moreover, the variables are not only for the sounds in Logic but as well the signal reception in PD.
Another aspect not yet approached is the sensors and how they will affect the sound. So far, the only affectation roughly made comes from the crank cadence, received via the hall effect switch. Two things were made: an RPM counter with an added 2x multiplier. This will meet more likely the BPM of the listened sound. The reason is that the effort in cycling with equivalence between BPM and RPM is not likely. As a cyclist who listens to music while commuting, I don't find it feasible. On the other hand, BPM=RPM*2 is a common practice. This way every time and foot pushes the pedal equals a beat. This will have several sound affectations and probably other multipliers. However, the only connection I've made so far is to a delay effect on the drum section.
As to the other two hall effect sensors the maths are different and so will be the way they'll affect sounds and the sounds they'll affect. First of, the maths. These sensors don't output signal from 0 to 1 but rather from roughly 0.5 to 1 or 0.5 to 0 depending on the magnet pole approaching it. However the to value also depends on the strength of the magnet. Due to size matters the magnets used only take the value to about 0.85. Therefore, the range of +-0.5/+-0.85 which is about 0.35 will have to be multiplied to meet the range 0/127 equivalent to midi values. Also, due to circuit stabilising, the negative output (0.5/0) is seriously damped, therefore the usage of the positive values. An important note is that once the sensor and corresponding magnet are on the brake levers, meaning that their standby position provides the maximum value and decreases upon usage of the brakes. So, in terms of midi values, it will start at 127 down to 0 rather than the opposite. There is the possibility of creating an equation to invert this, however, the first attempts are going to meet what the sensors provide.
Tuesday 26 March 2013
Wednesday 13 March 2013
Cycle Sound - assembling the electronics on the bike
So, the bike is ready. An excellent ride I should add.
The electronics are ready to assemble. But the bike is not ready to receive them. Simply because there is no place for buttons, sensors and drum pads on a bike!
Well, but I'm making place for it.
Here's some snap shots of what I've done so far. I must say as well that everything I've done is tested and it's working.
Linear hall effect sensor and magnet on the brake levers.
Soon enough the weather will be suitable for proper park testing! Can't wait for the day to come.
The electronics are ready to assemble. But the bike is not ready to receive them. Simply because there is no place for buttons, sensors and drum pads on a bike!
Well, but I'm making place for it.
Here's some snap shots of what I've done so far. I must say as well that everything I've done is tested and it's working.
Linear hall effect sensor and magnet on the brake levers.
Hall effect sensor switch and magnet on crank wheel for cadence computation.
Mini rear rack to hold the arduino, xbee shield, xbee, cyclesound shield, antena and batteries.
Soon enough the weather will be suitable for proper park testing! Can't wait for the day to come.
Monday 11 March 2013
Programming Cycle Sound
This weekend the bicycle became perfectly ready.
Some nice test drives through the city got me really proud about its construction.
Plus, on Friday at the London Hackspace, I made a nice aluminium rack to hold the arduino. It still needs finishing, but it looks promissing.
Also, I assembled half of the interacting elements to the bike (only one side as it is symmetric). However there were some isolation issues that made the system short and therefore Pure Data was getting lots of trash!
I already isolated everything but haven't assembled it back.
Now I am working on the Pure Data patch. Not only that, as I am making a Lemur skin to work with the patch wirelessly on an iPad. It will allow easy multi touch direct access to several parts of the patch to modify elements along the way, such as threshold values, notes and octaves.
The sounds are now coming from Logic Pro. An amazing feature with this is that it allows me to have different instruments assigned to each of the interacting elements of the bike.
Even though the servos are still uncertain, counting on their inclusion, the functionality of this should look something like this:
Some nice test drives through the city got me really proud about its construction.
Plus, on Friday at the London Hackspace, I made a nice aluminium rack to hold the arduino. It still needs finishing, but it looks promissing.
Also, I assembled half of the interacting elements to the bike (only one side as it is symmetric). However there were some isolation issues that made the system short and therefore Pure Data was getting lots of trash!
I already isolated everything but haven't assembled it back.
Now I am working on the Pure Data patch. Not only that, as I am making a Lemur skin to work with the patch wirelessly on an iPad. It will allow easy multi touch direct access to several parts of the patch to modify elements along the way, such as threshold values, notes and octaves.
The sounds are now coming from Logic Pro. An amazing feature with this is that it allows me to have different instruments assigned to each of the interacting elements of the bike.
Even though the servos are still uncertain, counting on their inclusion, the functionality of this should look something like this:
Tuesday 5 March 2013
More developments - moving quickly
Today was a quite intense day for the Cycle Sound project.
Started off with testing the XBee connection. This had been done very softly before and needed deeper understanding and testing.
Four things needed checking: a) all the pins of the XBee shield are sending; b) the analog pins are sending analog signal; c) the remaining pins of the arduino, despite not connected to the XBee, also send signal; d) Pure Data is receiving all signal, parsed as desired.
There is, however, another point to be tested: multiple simultaneous signals being sent and received and respective correct parsing. For this multiple connections to the arduino are needed.
After checking these points I proceeded to designing all the separate PCBs and a shield for connecting them to the arduino. As it was done their production starter: laser printing in photo paper, cutting the prints, cutting the copper board, transferring the prints to the copper board, etching the board, removing the toner, drilling and finally populating the boards.
I made a couple of mistakes on the way. Nothing serious.
1st - I didn't invert the shield drawing for printing. The others weren't important to invert as they were symmetric. And they were all printed in one go. I only realised this when I was already peeling the photo paper after the transfer had been done. Therefore, I had to go back to Illustrator, invert the image, print, cut the print and a new board, make the transfer again and so on...
2nd - the two very small hall effect sensor PCBs for the brake levers take a ratiometric hall effect sensor each. I assumed that it was going to work in the same way as the switch. Clearly I was wrong. But, luckily enough, I didn't have to make new PCBs for this. The problem was that I didn't test the sensors before making the PCBs. Anyway the difference was that they proved stabler without the resistor. I actually didn't test with different resistors but assumed that they would only interfere. Therefore I simply didn't insert the resistor.
The shield was done with surprising accuracy. However, the pin connectors aren't yet in my posetion. As soon as I get them I'll populate the shield. With it done, I can connect all PCBs to the arduino and make a full range test of the XBees, taking it to the park and making its first walk outdoors.
Hopefully, the brake calipers will also arrive soon and the bicycle will be able to join the XBees for a test drive.
Started off with testing the XBee connection. This had been done very softly before and needed deeper understanding and testing.
Four things needed checking: a) all the pins of the XBee shield are sending; b) the analog pins are sending analog signal; c) the remaining pins of the arduino, despite not connected to the XBee, also send signal; d) Pure Data is receiving all signal, parsed as desired.
There is, however, another point to be tested: multiple simultaneous signals being sent and received and respective correct parsing. For this multiple connections to the arduino are needed.
After checking these points I proceeded to designing all the separate PCBs and a shield for connecting them to the arduino. As it was done their production starter: laser printing in photo paper, cutting the prints, cutting the copper board, transferring the prints to the copper board, etching the board, removing the toner, drilling and finally populating the boards.
I made a couple of mistakes on the way. Nothing serious.
1st - I didn't invert the shield drawing for printing. The others weren't important to invert as they were symmetric. And they were all printed in one go. I only realised this when I was already peeling the photo paper after the transfer had been done. Therefore, I had to go back to Illustrator, invert the image, print, cut the print and a new board, make the transfer again and so on...
2nd - the two very small hall effect sensor PCBs for the brake levers take a ratiometric hall effect sensor each. I assumed that it was going to work in the same way as the switch. Clearly I was wrong. But, luckily enough, I didn't have to make new PCBs for this. The problem was that I didn't test the sensors before making the PCBs. Anyway the difference was that they proved stabler without the resistor. I actually didn't test with different resistors but assumed that they would only interfere. Therefore I simply didn't insert the resistor.
The shield was done with surprising accuracy. However, the pin connectors aren't yet in my posetion. As soon as I get them I'll populate the shield. With it done, I can connect all PCBs to the arduino and make a full range test of the XBees, taking it to the park and making its first walk outdoors.
Hopefully, the brake calipers will also arrive soon and the bicycle will be able to join the XBees for a test drive.
Monday 4 March 2013
Bike one step away!
We are getting there!!!
Saturday 2 March 2013
Cycle Sound development
In the last week, great developments have taken place.
1st - The Bicycle. Very few parts are now missing to complete its construction. I am pretty stubborn and the choice I made was to build it from scratch. Piece to piece... Of course, in the end it's a much more expensive bike than it could be, but it is the bike I chose to make. I just need a deraileur, pedals and a saddle. Brake calipers are ordered and should be here by the end of next week. This means that in a couple of weeks it will be ready to ride. I'll spend the weekend assembling the bottom braket and crank. Sunday, I'll get the deraileur and possibly pedals. This means that by monday it will be a moving bike... However, it wont brake yet...
2nd - Electronics. All parts for the bike rigging are either ordered or already in my posetion. Most of the PCBs are made and tested but there are some to be made still. Mostly, what needs to be done is the inter connection of all parts and its assembly to the arduino. Thumbs up!
3rd - Wireless. It was a long frustrating strive to find how to make the XBees work together. Not only that in a simple way, but very specifically: a) making it transmit all the signals desired; b) getting the signals straight into pure data. However, I'm still not too shure about it fully working, whitch still requires some testing. This will take place very soon. One of the question marks I still have wondering around my head is about the transmition of all analog signal.
4th - Pure Data. The patch is pretty simple so far. I'm using FM8 to make notes from the patch. The development of this will be done when the electronics are fully functional and stable. Some things will probably be worked in the meanwhile to test the electronics.
1st - The Bicycle. Very few parts are now missing to complete its construction. I am pretty stubborn and the choice I made was to build it from scratch. Piece to piece... Of course, in the end it's a much more expensive bike than it could be, but it is the bike I chose to make. I just need a deraileur, pedals and a saddle. Brake calipers are ordered and should be here by the end of next week. This means that in a couple of weeks it will be ready to ride. I'll spend the weekend assembling the bottom braket and crank. Sunday, I'll get the deraileur and possibly pedals. This means that by monday it will be a moving bike... However, it wont brake yet...
2nd - Electronics. All parts for the bike rigging are either ordered or already in my posetion. Most of the PCBs are made and tested but there are some to be made still. Mostly, what needs to be done is the inter connection of all parts and its assembly to the arduino. Thumbs up!
3rd - Wireless. It was a long frustrating strive to find how to make the XBees work together. Not only that in a simple way, but very specifically: a) making it transmit all the signals desired; b) getting the signals straight into pure data. However, I'm still not too shure about it fully working, whitch still requires some testing. This will take place very soon. One of the question marks I still have wondering around my head is about the transmition of all analog signal.
4th - Pure Data. The patch is pretty simple so far. I'm using FM8 to make notes from the patch. The development of this will be done when the electronics are fully functional and stable. Some things will probably be worked in the meanwhile to test the electronics.
Sunday 10 February 2013
A little board
After testing the push buttons on the breadboard and making sure that everything was in order, I decided to make a small PCB with the whole circuit.
Designed it in Adobe Illustrator. The reason is that I don't really get anything from EAGLE and also couldn't find the buttons to make the layout!
So, with a bit of old school technique (a ruler) I made it work.
Here it is!
Designed it in Adobe Illustrator. The reason is that I don't really get anything from EAGLE and also couldn't find the buttons to make the layout!
So, with a bit of old school technique (a ruler) I made it work.
Here it is!
Saturday 9 February 2013
Getting stuff together
I think that I'm at the point where I can start doing more with the results I've got. A good reason is that I think that I can't get any further with both the electronics and the programming to sort out the fine issues that I still have. These issues, as far as I can say, are latency and the fact that despite all my ignorant efforts to damp the signal from the piezo transducer in order to get only one signal spike, I'm still getting more than one.
Putting this aside, I got some pushbuttons from a scrap board that I found in the London Hack Space. I desoldered then and am using these recycled buttons to prototype.
So, being more specific, the buttons only have a 2.2kohm resistor between output and circuit ground. The piezo however, has a 5.1v Zener diode, two Schottky diodes (bat85), and an RC (1M.4n7).
In pure data I switch to input the pins where the buttons are connected and to analog the piezo input.
To start simple, you can straight away look at the values coming out when you tap the piezo or push the buttons.
In this case I have the patch in a more advanced state, so I'm using the buttons to change the notes given by the piezo.
Also, yesterday I made the polystyrene bases for the pads on the handlebar of the bike. However, I had forgotten that planned on bedding the pad cases to attenuate more of the bike's input to the e piezos. This means that I have a gap between the pads and the case and therefore will be forced to make the bedding anyway. It is a bit annoying from the point of view of testing, but in the end the results are going to be much better.
I'm mounting this on a breadboard, but the intention is to make a PCB when the testing stage ends. This will make it much more reliable, small and easy to fit on the bike as I can design the PCB however I want and feel appropriate for its function.
Putting this aside, I got some pushbuttons from a scrap board that I found in the London Hack Space. I desoldered then and am using these recycled buttons to prototype.
I
In the end, what I'm doing now is having the piezo and 2 buttons connected to the arduino being read by pure data outputting to FM8. Just to test! And it works!
So, being more specific, the buttons only have a 2.2kohm resistor between output and circuit ground. The piezo however, has a 5.1v Zener diode, two Schottky diodes (bat85), and an RC (1M.4n7).
In pure data I switch to input the pins where the buttons are connected and to analog the piezo input.
To start simple, you can straight away look at the values coming out when you tap the piezo or push the buttons.
In this case I have the patch in a more advanced state, so I'm using the buttons to change the notes given by the piezo.
Also, yesterday I made the polystyrene bases for the pads on the handlebar of the bike. However, I had forgotten that planned on bedding the pad cases to attenuate more of the bike's input to the e piezos. This means that I have a gap between the pads and the case and therefore will be forced to make the bedding anyway. It is a bit annoying from the point of view of testing, but in the end the results are going to be much better.
I'm mounting this on a breadboard, but the intention is to make a PCB when the testing stage ends. This will make it much more reliable, small and easy to fit on the bike as I can design the PCB however I want and feel appropriate for its function.
Tuesday 29 January 2013
Great results in the remake of the Pure Data patch for "When the Doorbell Rings".
Pretty good results for the update of the patch as it became much more user friendly.
Also, included a README to the folder so there is a set of instructions for anyone to follow.
As convenient, all the hardware was operational.
The display was already tested in the spacing camera and it proves efficient.
The patch was tested without the arduino connected.
As it is aimed for the piece to be a stand alone artwork without the need of extra dependencies, the system is going to migrate to a raspberry pi running linux.
Pure Data runs on linux, so the r-pi will deal with all the processing needed for video and audio.
In a few words: this piece get to have its own computer.
Saturday 26 January 2013
Rework to python
Last Saturday I met again with Ricardo Amaro in very fruitfull afternoon towards the making of Cycle Sound.
We spent a lot of time installing libraries and modules and stuff... It pretty time consuming. Anyways, the point being trying to migrate part of the project to python. The language is easier and there is a greater array of possibilities with it than with the Arduino software. Mostly because with the Arduino software we can only work within the Arduino. With python we can work/communicate with Arduino along with being able to control other softwares and/or platforms.
So, towards the programming of Cycle Sound, we got hold of controlling parameters given by Arduino. We are still working our way around the piezoelectric as a sensor. I think we made quite a good progress, however it made me realise that the problems, or most of the problems we are having with the piezoelectric are not from the software domain but rather from the hardware. Electronics!
The information available online of how to go around piezoelectric issues when connecting it to an Arduino is very scarce and hard to find. However I found a great article on it which hopefully is going to get me through the main problem.
The problem is the signal peaks given by the piezoelectric. The point is to make the piezo a clean single "bang" signal containing a value that is to be transformed into midi velocity. There is nothing (or probably not much, very complex and not very effective) that software can do to go around this. So it comes down to a simple small circuit between the output of the piezo and the input of the Arduino. A couple of diodes and an RC are meant to do the job. I haven't fully tested this as I'm still waiting for one of the diodes to be delivered but I have quite high expectations, I must confess.
If the result proves effective, I will be confirming it over here. I will give the different possibilities that I tested and report the best results. I don't have an oscilloscope or anything to measure the signal in a controlled manner, but in the end, it's the results on the project that I'm interested in.
If it all works according to expectation, this is a great step towards any kind of drum machine with a great controll level and sensitivity.
Looking forward to the results!!!
We spent a lot of time installing libraries and modules and stuff... It pretty time consuming. Anyways, the point being trying to migrate part of the project to python. The language is easier and there is a greater array of possibilities with it than with the Arduino software. Mostly because with the Arduino software we can only work within the Arduino. With python we can work/communicate with Arduino along with being able to control other softwares and/or platforms.
So, towards the programming of Cycle Sound, we got hold of controlling parameters given by Arduino. We are still working our way around the piezoelectric as a sensor. I think we made quite a good progress, however it made me realise that the problems, or most of the problems we are having with the piezoelectric are not from the software domain but rather from the hardware. Electronics!
The information available online of how to go around piezoelectric issues when connecting it to an Arduino is very scarce and hard to find. However I found a great article on it which hopefully is going to get me through the main problem.
The problem is the signal peaks given by the piezoelectric. The point is to make the piezo a clean single "bang" signal containing a value that is to be transformed into midi velocity. There is nothing (or probably not much, very complex and not very effective) that software can do to go around this. So it comes down to a simple small circuit between the output of the piezo and the input of the Arduino. A couple of diodes and an RC are meant to do the job. I haven't fully tested this as I'm still waiting for one of the diodes to be delivered but I have quite high expectations, I must confess.
If the result proves effective, I will be confirming it over here. I will give the different possibilities that I tested and report the best results. I don't have an oscilloscope or anything to measure the signal in a controlled manner, but in the end, it's the results on the project that I'm interested in.
If it all works according to expectation, this is a great step towards any kind of drum machine with a great controll level and sensitivity.
Looking forward to the results!!!
Subscribe to:
Posts (Atom)
