Show Posts
Pages: 1 2 [3] 4 5 ... 56
31  Using Arduino / Audio / Re: Two audio Outputs? on: May 27, 2012, 03:03:06 pm
Or you could check out a more complicated method (using assembler) to get up to 16-note polyphony, from a single Arduino pin on a normal Duemilanove/Uno:

My project: http://arduino.cc/forum/index.php?topic=82475.0
(I arbitrarily chose 8 voice polyphony; it could do more)

Another guy's project, which mine is partially based on: http://www.cs.nott.ac.uk/~jqm/?p=605
(he mentioned in the forums that 16 voices worked perfectly fine on his synth)
32  Using Arduino / Audio / Re: "Click"-noise on note start on: May 27, 2012, 02:58:47 pm
Exactly. 
Looking at your code, you tried to put a simple LPF-like smoothing, which theoretically would work.  But the problem is, even if the PWM carrier ramps up to full volume, the arduino output itself is still jumping directly to 5v.

I had the same problem with my synth.  The problem could be solved by having the output centered on the middle of the output range, rather than just adding waveforms to 0.  Add a capacitor in series to nix the DC offset, and the middle PWM value will become the new "0" point.
This was actually a problem for me, because no analog LPF's can filter out all of the carrier wave.  I ended up getting a nice SPI DAC, since I use my synth for my electronic music-making, and the PWM wave, albeit inaudible, messed up recordings.
33  Using Arduino / Audio / Inline Assembler with SPI DAC on: May 27, 2012, 02:44:33 pm
So I'm working on yet another improvement to my ongoing midi synth project: adding a 12-bit DAC, and reworking all the synthesis code. 
I'm using an MCP4922 SPI DAC.
If I use the normal SPI library functions, I can successfully write values to the DAC.

But I have an interrupt routine running at ~32KHz, so I'm using the GCC inline assembler to code the interrupt in assembly.
Here is the interrupt routine, stripped down to what I believe are the problem sections:

Code:
ISR(TIMER1_OVF_vect)  {                  //ASSEMBLER WOOT


  byte tempOutput;


  __asm__ volatile (
  //some port addresses, to make things easier
  ".equ PORTB,0x05" "\n\t"
    ".equ SPDR,0x2e"  "\n\t"
    ".equ SPSR,0x2d"  "\n\t"
//------------------------------------------------------------------------
"mov %[debugByte],%B[outputA]" "\n\t"
   
    //output first, most significant, byte for DAC thru SPI
  //this variable changes in the first "batch" of oscillators, so a copy must be made
  "mov %[tempOutput],%A[outputA]"                                "\n\t"
    //slave select pin is pin B2, for the DAC
  "cbi PORTB,2"                                                  "\n\t"
    //begin SPI transfer
  "out SPDR,%B[outputA]"                                         "\n\t"

    //reset outputA.  done after transfer, to have a buffer.
  //set all the neccessary config bits.
  //and set the output to the middle value.   0x78 = 0b01111000
  "ldi %B[outputA],0x78"                                         "\n\t"
    //lower bit of output is all data, no config bits
  "ldi %A[outputA], 0x00"                                              "\n\t"

//OSCILLATOR CODE

    //send lower byte, previously moved, since the first "batch" edited the original output byte
  "Wait1:"                                                       "\n\t"
    //wait until bit 7 of SPSR is set, the SPI flag.  SPI should be done by now.  but just in case.
  //annoyingly, SPSR is not usable in the sbis command.  so put in a register first.
  "in r1,SPSR"                                                 "\n\t"
    "sbrs r1,7"                                               "\n\t"
    "rjmp Wait1"                                                 "\n\t"
   

    "out SPDR,%[tempOutput]"                                       "\n\t"

//OSCILLATOR CODE

    "Wait2:"                                                       "\n\t"
    //wait until bit 7 of SPSR is set, the SPI flag.  SPI should be done by now.  but just in case.
  //annoyingly, SPSR is not usable in the sbis command.  so put in a register first.
  "in r1,SPSR"                                                 "\n\t"
    "sbrs r1,7"                                               "\n\t"
    "rjmp Wait2"                                                 "\n\t"
    "rjmp AllDoneYay"                                            "\n\t"




    //--------------------------------------------------------------------
  "AllDoneYay:"                                                "\n\t"
    "sbi PORTB,2"                                              "\n\t"
    //=======================================================================


:  //outputs
  [outputA] "=&d" (outputA),
  [tempOutput] "=&d" (tempOutput),
  [debugByte] "=&d" (debugByte)
 
:  //inputs

:  //clobbered
  );
}

OutputA is a global volatile int declared at the beginning of the program.
DebugByte is a volatile global byte used to monitor the value of outputA.  In loop(), debugByte is sent repeatedly thru serial.
The OSCILLATOR CODE parts are where code would go that would calculate the outputs of each oscillator.  But the problem persists with or without these parts, so they're not relevant.
I interspersed both SPI transfers so that no time is wasted transferring; the oscillator code is executed while the transfer is carried out.  The oscillator code, though, modifies the outputA variable, which is why I had to transfer the low byte of the output to the tempOutput byte.

With the above code, I get loads of garbage.
If I move the debugByte mov instruction to after the ldi's of outputA, I get the expected message "120", or 0x78.
If I move the outputA ldi's to before the SPI transfers, the transfers work fine.  I get the expected ~2.5V output.  (the DAC takes 2 bytes to set one channel.  The first nybble of the high byte is configuration bits for the DAC; they should be 0x7.  the 12 other bits are data bits, so 0x7800 gets an output in the middle of the range)

I want the oscillator code to come after the SPI transfers (and the moves to temporary bytes) so the sample rate is constant regardless of any variation in the speed of the interrupt function.
But something's just getting messed up somewhere.

Any ideas?
34  Community / Exhibition / Gallery / Re: First homemade pcb --> DS8 Analog drumsynth clone! on: May 24, 2012, 10:38:38 am
It's all done, you can see it in the video.  I never got around to putting in the second half of it inside that box (all the extra holes).

And sorry, I had originally posted this NOT in "exhibition", because I didn't want people disappointed it wasn't arduino!  but a mod moved it...   smiley-razz

Though it wouldn't be hard at all to make an arduino version.  I should try it sometime.  Maybe a drum sequencer on my WIP arduino synth.
35  Community / Bar Sport / Re: Your latest purchase on: April 22, 2012, 02:18:44 pm
A sparkfun serial-enabled LCD kit.

I might use it on my forever-a-WIP arduino midi synth, it'll definitely be more readable than an 8x16 LED display.  But the led matrix is cool, I'll probably keep that, and just have a second display.  I dunno.

The extra 328 chip will also be useful; maybe I could modify the code to make the LED matrix also Serial controlled by the master duemilanove.  I've noticed some display flicker above 8 note polyphony right now; it has to constantly scan each row on the display, and the 31250Hz interrupt routine bogs it down enough to be noticeable.
36  Community / Bar Sport / Re: Circuit deliberations - Where to plug in the Arduino ? Help appreciated on: April 18, 2012, 10:56:58 pm
3rd time I've seen this comic linked to on this forum.

Still a funny comic, though.  My favorite is the decoy resistor and "not a resistor" wire.  Oh and definitely the "omit this if you're a WIMP" wire.
37  Using Arduino / Audio / Re: Midi works with one keyboard but not to the other on: January 22, 2012, 01:03:15 pm
Ah, those tricky resistor color bands...

It always happens that you see similar colors, and then don't bother to check carefully.  Glad you got the problem fixed.
38  Using Arduino / Audio / Re: Play MIDI from SD on: January 18, 2012, 11:13:02 pm
The Arduino can get 8 or more note polyphony, with different waveforms and volume control for each note.  So not too limited, it's more than an NES or gameboy!   smiley

Check out my project, and joemarshall's

My synth can already take MIDI input, it shouldn't be hard to adapt it to work from MIDI files.
39  Using Arduino / Audio / Re: Midi works with one keyboard but not to the other on: January 18, 2012, 11:08:30 pm
Ah, okay, my post is then irrelevant if you're using an interface.

I don't see how the FTDI board could interfere when not connected to a computer, but it's easy enough to try disconnecting it, so you might as well.

Just to clarify, the computer does not recieve proper MIDI data either, right?  If so, then it's not a problem specific to the vocal harmonizer.

What version of the arduino IDE are you using?  In 1.0, the serial functions work differently, and that might mess things up.
40  Using Arduino / Audio / Re: Can't Calibrate Pots To Go From 0-127 on: January 18, 2012, 08:31:03 pm
A couple of questions:

1) What type of pots (linear-taper or audio-taper)?
2) Why not use the map() function...?

He's got the problem fixed already.    smiley-razz

But as for not using map(), it makes much more sense to simply divide, since the analogRead range is a power of 2 times the MIDI value range.
41  Using Arduino / Audio / Re: Midi works with one keyboard but not to the other on: January 18, 2012, 08:28:46 pm
The arduino communicates to the computer using a virtual serial connection.  While hardware MIDI can be sent with simply a serial connection, the MIDI over USB protocol is different.  You cannot simply send serial messages and have the computer recognize it as MIDI data.  There is software that converts serial messages to MIDI, like here: http://spikenzielabs.com/SpikenzieLabs/Serial_MIDI.html
42  Using Arduino / Project Guidance / Re: Which Controller on: January 18, 2012, 08:09:35 pm
The Uno is plenty flexible for many applications.

I would only buy a mega if I had a specific need for it, not just as something to tinker with.  (and I personally have never had such a need)
43  General Category / General Discussion / Re: Free software to create circuit diagrams? on: January 18, 2012, 05:40:14 pm
Some people use Fritzing, I personally hate it because when I first used it it was earlier in its development, probably 1.5-2 years ago, and extremely buggy and annoying to use.  I learned Eagle, so obviously I never tried Fritzing again.

It is easier (consequently not as powerful as Eagle) and theoretically less buggy now, but I wouldn't know.


But I'd say it's worth learning Eagle.
44  Community / Bar Sport / Re: Your latest purchase on: January 17, 2012, 08:19:33 pm
A bunch of parts for a robot arm that I have to make for my school's Science Olympiad team.

It's going to be arduino controlled, which should give me an advantage over people who use standard servo remote controllers, since the arduino can be programmed to take input that makes more sense for controlling a robot arm, rather than totally independent control of each motor.  Ease of use is one of the biggest parts of the competition, since it's remote controlled and needs to do stuff within a time constraint.
45  Using Arduino / Audio / Re: MOD Player (not Arduino based) on: January 17, 2012, 07:08:31 am
Pffft, 4 channels? 

How about this guy who does 28 channels?      smiley-grin
 


Here's 8 channels, 22.1KHz:


Pages: 1 2 [3] 4 5 ... 56