Just finished rewiring the internal power lines tonight. I have had some serious problems with digital noise in the headphone stage. The headphone amp drew power from the same board as the midi controller and other digital electronics reside on. I have changed this so that it now draws power from the card closest to the transformator. Also, I have re-added a 5v voltage regulator to the controller board and added a separate ground wire. I hope this fixes some of my problems.
While having the lid off I've also added the missing 500ohm (or actually dual 1k in parallell) pot to BD Accent, so now I thing everything except for the too-low samples/output levels are fixed. Fingers crossed, will test tomorrow!
Showing posts with label controller. Show all posts
Showing posts with label controller. Show all posts
Monday, 26 December 2011
Sunday, 21 June 2009
Better menu labels
Just a thought: What about changing the names of 'Patt' and 'Perf' to 'Steps' and 'Live' ? These are full words, not abbreviations, which I guess is a bit better.
Sunday, 31 May 2009
Finished programming (!?)
This is a great day. The sun is shining, it's about 29 degrees outside (This is Norway and it's not even June yet, so that is pretty good). And the drum machine code is now ready for extensive testing. I guess there are still some small bugs in there, but now all major and minor functionality is finished and the machine is playing cool rythms :-D
Next up will be to get some silk screen equipment and start work on the box. Also I've had to come to terms with a few shortcomings with the current controller design. The LEDs flicker a bit while the sequencer plays, and the encoders are a bit unstable. To overcome this I will have to build a completely new controller again (v5), with a separate led controlling circuit, and with dedicated encoder chips. However, everything works ok, so this wont happen for a while.
I had to re-make the ribbon cables between the controller and the keyboard as well. Half of the numeric keyboard didn't work due to some stupid wiring mishap. Now the only key that doesn't work is the left-key. I'm not sure why yet, have to get my multimeter out and start measuring :-D
I guess this wraps things up for summer, have fun untill the cold winds of fall makes it possible to be inside coding again :-D
Next up will be to get some silk screen equipment and start work on the box. Also I've had to come to terms with a few shortcomings with the current controller design. The LEDs flicker a bit while the sequencer plays, and the encoders are a bit unstable. To overcome this I will have to build a completely new controller again (v5), with a separate led controlling circuit, and with dedicated encoder chips. However, everything works ok, so this wont happen for a while.
I had to re-make the ribbon cables between the controller and the keyboard as well. Half of the numeric keyboard didn't work due to some stupid wiring mishap. Now the only key that doesn't work is the left-key. I'm not sure why yet, have to get my multimeter out and start measuring :-D
I guess this wraps things up for summer, have fun untill the cold winds of fall makes it possible to be inside coding again :-D
Sunday, 8 February 2009
Feature update
I'm closing in on finishing the intended features. Three major things are not yet started: 'File' (pattern saving and loading), 'song' and 'perform'. Setup is almost finished, the same goes for the sequencer features.
Implemented and upcoming features:
Implemented:
- LCD support, inc time, bpm and play mode
- step sequencer
- record mode
- play/pause mode with correct tempo
- tempo adjustment
- clip board (multi track)
- accent
- velocity page
- velocity entry
- settings edit page
- Internal EEprom support (for persisting current setup)
- Flam
- Swap
- Swing
- Mute & Solo
Upcoming
- Song and perform modes
- Flam cut'n'paste
- Tap tempo
- Midi output... (This is almost finished but not tested yet)
- Midi input?
:-D
Implemented and upcoming features:
Implemented:
- LCD support, inc time, bpm and play mode
- step sequencer
- record mode
- play/pause mode with correct tempo
- tempo adjustment
- clip board (multi track)
- accent
- velocity page
- velocity entry
- settings edit page
- Internal EEprom support (for persisting current setup)
- Flam
- Swap
- Swing
- Mute & Solo
Upcoming
- Song and perform modes
- Flam cut'n'paste
- Tap tempo
- Midi output... (This is almost finished but not tested yet)
- Midi input?
:-D
Monday, 26 January 2009
Performance mode - ideas
The intention with performance mode is to load patterns 'on the fly', allowing unique performances to be created from pre-programmed patterns.
Patterns can be loaded by name or number, but it might be a good idea to pre-assign patterns for easier access?
One could, for instance, assign a pattern to each of the 32 steps in the step sequencer. To queue a pattern for the next 'loop', one presses the according step button while in play mode. The assignments should of course be user controllable, and be saved as a 'performance setup'.
In performance mode, a pattern should be played/looped until a new one is selected, and the next pattern should not start before the previous one is finished. Also, it should be possible to add a 'stop' clause at the end of a pattern, automatically stopping playback once the end of that pattern is reached.
Perhaps it also should be possible to link patterns, e.g. group four patterns into a loop?
In song mode, the same patterns should be selectable (and assignable), but no looping is performed as a song is just a list of patterns to play.
Thought: Should it be possible to record a performance as a song, and edit it afterwards?
Patterns can be loaded by name or number, but it might be a good idea to pre-assign patterns for easier access?
One could, for instance, assign a pattern to each of the 32 steps in the step sequencer. To queue a pattern for the next 'loop', one presses the according step button while in play mode. The assignments should of course be user controllable, and be saved as a 'performance setup'.
In performance mode, a pattern should be played/looped until a new one is selected, and the next pattern should not start before the previous one is finished. Also, it should be possible to add a 'stop' clause at the end of a pattern, automatically stopping playback once the end of that pattern is reached.
Perhaps it also should be possible to link patterns, e.g. group four patterns into a loop?
In song mode, the same patterns should be selectable (and assignable), but no looping is performed as a song is just a list of patterns to play.
Thought: Should it be possible to record a performance as a song, and edit it afterwards?
Sunday, 16 November 2008
First keyboard/sequencer integration
For the first time since I began working on the project, the keyboard and leds now integrate with parts of the sequencer software. I've added the possibility to toggle the step leds, and switch between the 12 internal sequencer tracks. It is extremly fast and works incredibly well. I'm so really satisfied with the result! I should put up a video of this to show how cool it really is :-D
Also, I broke my PICFlash2 In-circuit programmer and had to order a new one from Mikroelektronika. Not sure what happened, but I think I put the power to my circuit on the power out pins instead of the power in ones...
Also, I broke my PICFlash2 In-circuit programmer and had to order a new one from Mikroelektronika. Not sure what happened, but I think I put the power to my circuit on the power out pins instead of the power in ones...
Monday, 27 October 2008
Encoder experiences
The encoders on the drum machine keyboard are working now. The missing leads discovered earlier were not the only obstacles I had to overcome. After fixing the circuit, the encoders still didn't work properly. For some reason, I had not thought about what would happen when the encoders stood still and did not have a connection to +5v. This, of course, would lead to floating inputs on the direction-detection flip flops, and no clear readings from the circuit.
I then added 10k pull down resistors to all the inputs, this fixed most of the problems and made it possible to detect encoder clicks.
However, if the encoder is turned slowly, one click of the dial leads to multiple detected clicks, as the circuit keeps outputting clicks, as the flip flops are not reset.
To fix this, I've added a state check in software. Clicks will only lead to events if a 0 has been read in between two reads of 1. This fixes most issues, but quick turns of the dial will in fact give fewer clicks than slowwe turns. Also, I've experienced a few 'backward' clicks in between the forward clicks, not sure what causes this.
But, all in all, things are looking very bright. The mode selection leds light up and respond to the encoder. Now I'll just have to get the rest of the keyboard up and running againg. And fix the head phone amplifier and get a license file for my compiler...
I then added 10k pull down resistors to all the inputs, this fixed most of the problems and made it possible to detect encoder clicks.
However, if the encoder is turned slowly, one click of the dial leads to multiple detected clicks, as the circuit keeps outputting clicks, as the flip flops are not reset.
To fix this, I've added a state check in software. Clicks will only lead to events if a 0 has been read in between two reads of 1. This fixes most issues, but quick turns of the dial will in fact give fewer clicks than slowwe turns. Also, I've experienced a few 'backward' clicks in between the forward clicks, not sure what causes this.
But, all in all, things are looking very bright. The mode selection leds light up and respond to the encoder. Now I'll just have to get the rest of the keyboard up and running againg. And fix the head phone amplifier and get a license file for my compiler...
Monday, 29 September 2008
Quadrature decoder how-to
I am having some problems with the new controller in terms of power consumption. While investigating this I realised that I've forgotten how the decoder for the digital pulse givers works.
Here is the original article describing the circuit:
"The Encoder Decoder Circuit"
Our task this week is to create a circuit to count pulses coming from the encoder and display the count on a dual 7-segment LED display. The circuit should be smart enough to know whether the knob is rotating clockwise or counterclockwise, and increment or decrement the count appropriately. To determine the direction of rotation requires us to build a special quadrature decoder circuit, and for this we need to learn something about computer memory.
Computers store information in millions (sometimes billions) of small devices called “flip-flops”. The purpose of a flip-flop is to store a single bit (either a 1 or 0) until requested to change. One of the simplest types of flip-flops is called a D-type flip-flop, shown in the figure at right. The functioning of a flip-flop is actually pretty simple: a piece of data is stored at (and can be read from) port Q until a clock pulse is received at the CLK port. When a clock pulse is received, whatever data value exists at the D (for data) port is written to Q. Most D-type flip-flops change state only on the rising edge of a clock pulse, hence the name “edge-triggered flip-flop”.
Our quadrature decoder circuit will make use of the data storage capability of the flip-flop. As shown in the figure above we feed the signal from pin A of the decoder into the D port and the B signal into the CLK port. If the pulses from pin A lead those of pin B, the D port will be in a high state whenever the clock port sees a rising edge – hence Q will remain high. Conversely, if the B pulses lead, Q will remain low. In this way the output at Q provides a means of decoding the direction of rotation. The circuit below shows a practical implementation of the quadrature decoder.
The circuit also makes use of two NAND gates in the CD4011 chip. The NAND gates are used to combine the constant high or low signals from Q with the pulse train from the encoder to provide pulses to the counter inputs. If Q1 is high the CLK UP port will receive the pulse train and if Q2 is high the CLK DN port will receive the pulse train.
Here is the original article describing the circuit:
"The Encoder Decoder Circuit"
Our task this week is to create a circuit to count pulses coming from the encoder and display the count on a dual 7-segment LED display. The circuit should be smart enough to know whether the knob is rotating clockwise or counterclockwise, and increment or decrement the count appropriately. To determine the direction of rotation requires us to build a special quadrature decoder circuit, and for this we need to learn something about computer memory.
Computers store information in millions (sometimes billions) of small devices called “flip-flops”. The purpose of a flip-flop is to store a single bit (either a 1 or 0) until requested to change. One of the simplest types of flip-flops is called a D-type flip-flop, shown in the figure at right. The functioning of a flip-flop is actually pretty simple: a piece of data is stored at (and can be read from) port Q until a clock pulse is received at the CLK port. When a clock pulse is received, whatever data value exists at the D (for data) port is written to Q. Most D-type flip-flops change state only on the rising edge of a clock pulse, hence the name “edge-triggered flip-flop”.
Our quadrature decoder circuit will make use of the data storage capability of the flip-flop. As shown in the figure above we feed the signal from pin A of the decoder into the D port and the B signal into the CLK port. If the pulses from pin A lead those of pin B, the D port will be in a high state whenever the clock port sees a rising edge – hence Q will remain high. Conversely, if the B pulses lead, Q will remain low. In this way the output at Q provides a means of decoding the direction of rotation. The circuit below shows a practical implementation of the quadrature decoder.
The circuit also makes use of two NAND gates in the CD4011 chip. The NAND gates are used to combine the constant high or low signals from Q with the pulse train from the encoder to provide pulses to the counter inputs. If Q1 is high the CLK UP port will receive the pulse train and if Q2 is high the CLK DN port will receive the pulse train.
Sunday, 28 September 2008
Midi controller 4 v1.0 PCB received
Resent events: turned 30 yesterday... Sigh. I would have hoped to be finished before turning 30, but noooo.
I also received the new PCB for the controller. I've already populated it, testing starts tonight. I have great expectations for this new version. However, I still haven't tried the digital giver circuits, so perhaps I'm in for a version 1.1 of MC4 as well? Only time will tell.
I also received the new PCB for the controller. I've already populated it, testing starts tonight. I have great expectations for this new version. However, I still haven't tried the digital giver circuits, so perhaps I'm in for a version 1.1 of MC4 as well? Only time will tell.
Tuesday, 11 March 2008
New controller finished
Except for finishing touches and error checking, Midi controller number 4, v1.0 is finished! This uses a single 40 pin mCU instead of two smaller ones, which made it a challenge to route all the paths in the small space available. It looks promising though.
I just tought of another idea for a dual mCU version though. Perhaps it would be possible to use i2c for communication between the devices? In that case, I would be able to use hardware instead of software-emulated com, but I'm not sure about the speed of the i2c bus. Will have to research this later if I get into trouble running everything on a single mCU (It should not be a problem, but who knows...).
Here is a pic of the new PCB:
I just tought of another idea for a dual mCU version though. Perhaps it would be possible to use i2c for communication between the devices? In that case, I would be able to use hardware instead of software-emulated com, but I'm not sure about the speed of the i2c bus. Will have to research this later if I get into trouble running everything on a single mCU (It should not be a problem, but who knows...).
Here is a pic of the new PCB:
Tuesday, 5 February 2008
Success!
Everything works like a dream now :) I've implemented all commands and tested the keyboard using the second controller as a loopback. It looks so good I can hardly stop working on it :-D
I may have to simplify the transfer protocol a bit though, to get increased throughput. Hopefully I can skip some error checking if I just make sure that no invalid state leads to a deadlock.
The remaining work on the keyboard is now:
- Glue some of the perspex pieces in place so they don't obstruct the keys
- Drill holes for the rotary givers and implement the necessary code
- Cut and solder the paths for the second row of instrument select buttons
- Fix the keys on the keypad that are not working (two signal paths)
- Fix a problem with S528 - it seems one of the switches does not work very well (a key release is send immediately after key press). I suspect this is a hardware error.
And then - onto coding the controlling software! Can't wait!
I may have to simplify the transfer protocol a bit though, to get increased throughput. Hopefully I can skip some error checking if I just make sure that no invalid state leads to a deadlock.
The remaining work on the keyboard is now:
- Glue some of the perspex pieces in place so they don't obstruct the keys
- Drill holes for the rotary givers and implement the necessary code
- Cut and solder the paths for the second row of instrument select buttons
- Fix the keys on the keypad that are not working (two signal paths)
- Fix a problem with S528 - it seems one of the switches does not work very well (a key release is send immediately after key press). I suspect this is a hardware error.
And then - onto coding the controlling software! Can't wait!
Inter-mcu communication working
I've finally got the communication working with both mcu's on the controller pcb. I ended up bending away pin 6 on the LCD/midi controller, to prevent it from interfering with the data transfer, and it works very well. finally I can test the transfer protocol :-)
Saturday, 2 February 2008
Keyboard PCB problems
I have made a crucial mistake on the keyboard PCB. The second line of instrument buttons is connected to select line 1 instead of 2, meaning both rows map to the same keys :-( This has to be fixed by cutting a line on the keyboard and connecting it manually to select line 2. Bummer.
Also, SEL9 and 10, going to the keypad, are not working properly. This could be just the cable though.
Also, SEL9 and 10, going to the keypad, are not working properly. This could be just the cable though.
Thursday, 31 January 2008
1 bit! 1 stupid bit!
Finally! I've discovered what has caused all my pain and suffering the last days. It appears that there's some kind of bug in mikroC, in the Soft uart library. This means that I manually have to send a single 1 after transmitting a byte. Doing this, everything works like a charm! Woohoo! I really love mikroC, but it has a few bugs too many. Still, I always get answers from the developers and it has a lot of built in features I would never ever manage to code myself if I had to write in assembler.
I've tried various speeds. It seems that 38400bps works fine, but at 115200 some bytes are dropped. At 38400bps I'm able to transmit 4800bytes/sec, (a bit lower really, there's some overhead), or about 0.2 milliseconds per byte. It could mean a slight delay from pressing a key to the result is received by the second controller, but I guess I just have to try this out. I could also try to up the speed to, say 57600 and see what happens...
Update: 57600 works fine.
Update: 57600 does not work for receiving data when the receiver runs at 8MHz. I have to try this again when both uC's are on the real board.
Update: To use PORTA, it is necessary to add "ADCON1 = 0x07" to turn off analogue inputs.
I've tried various speeds. It seems that 38400bps works fine, but at 115200 some bytes are dropped. At 38400bps I'm able to transmit 4800bytes/sec, (a bit lower really, there's some overhead), or about 0.2 milliseconds per byte. It could mean a slight delay from pressing a key to the result is received by the second controller, but I guess I just have to try this out. I could also try to up the speed to, say 57600 and see what happens...
Update: 57600 works fine.
Update: 57600 does not work for receiving data when the receiver runs at 8MHz. I have to try this again when both uC's are on the real board.
Update: To use PORTA, it is necessary to add "ADCON1 = 0x07" to turn off analogue inputs.
Inter-uC communicatoin
I am having some problems getting the soft-uart from MikroC to work properly. I have been trying to send data from PORTA.F4 for a long time without success. Yesterday, after first having some problems because I didn't connect ground on my prototype card to ground on the EasyPIC3 development board, I managed to use soft-usart-write to send data that could be received with the real uart of the other uC. However, When I send 0x36 using the soft uart, it is received as 0x13 on the other. I have no idea why yet, either the clock frequency is wrong or some interrupt delays the sending. Will have to work on that.
Also, I had to switch to PORTA.F0, not sure if I have broken PORTA.F4 or if I just need to disable something.. not a big deal anyway, but took ages to figure out.
Also, I had to switch to PORTA.F0, not sure if I have broken PORTA.F4 or if I just need to disable something.. not a big deal anyway, but took ages to figure out.
Monday, 5 November 2007
First test of sound circuits + controller PCB populated
p>I've powered up the sound circuits for the first time. Last night I was getting a lot of noise and very low sounds. Today I connected a wire from GND on both PCBs to mains ground, and placed the power cord in the same power board as my line mixer. I also checked all crimps on the potmeters and other wires to make sure they were all connected. I seem to have gotten rid of the noise, but the sound level is still very low. Also, I'm only getting sound in the right channel, and not from all drums. (toms, snare, bass, rim shot, hand clap and ride cymbal seem to be working, I guess it is a problem with the sample/ROM circuits, have to check that.
Top view
Bottom view with reset button and ICP headers
The layout looks like a complete mess at the moment, which could be contributing to my problems. But hey, some sound is better than no sound!
I've also finished populating the controller PCB. It looks great but has not been tested yet (or rather, once I plugged it into the In Circuit Programmer (ICP), the ICP power led went dark. So I decided to work on the sound circuits instead.
Top view
Bottom view with reset button and ICP headers
Subscribe to:
Posts (Atom)