Jump to content

AM's revitalized PIC synth project


AndrewMartens
 Share

Recommended Posts

For some unknown reason, my long-neglected Digital PIC Synth project came back to my brain yesterday, and so I stopped by here again.  It got me to thinking that I really should get off my butt and try to finish this thing - if nothing else, someone might be able to make some cool sounds with it.

The quick summary of its current incarnation is as follows.  Heck, I'll even just use the introduction from my preliminary datasheet - http://www.andrewmartens.com/files/DPS-224-r0.1.pdf.  There's lots of good feature info in the datasheet, I recommend reading it.

The Digital PIC Synth (or DPS) is a 2-oscillator 8-bit digital monosynth that is implemented as the firmware of a PIC18F-series microcontroller.  The initial incarnation of this synth design is the DPS-224.  Future DPS releases will use a similar naming scheme, which follows:

DPS – (A)(B)©(Z)

(A) = number of oscillators

(B) = number of sub-oscillators

© = number of modulators

(Z) = optional special feature code; B = boost, F = filter, etc.

Note that just because I have a ridiculous naming scheme doesn't mean that I'm going to ever get around to implementing more oscillators / modulators / a filter / etc.  But just because it doesn't have a filter doesn't mean that you shouldn't get excited.

The overall output frequency will most likely be in the range of 8 – 16 kHz.  This has yet to be finalized, and depends on the amount of cycles required to process the final feature set.  The audio output will most likely be through an 8-bit R2R ladder (cheap, yay!), though I am also looking at other options.  The main consideration here is making it easy and cheap to procure parts, possibly at the expense of quality – though only if it is a minor impact.

The first release of the DPS is intended to be used with a MBHP_CORE module as the primary controller, running MIOS by Thorsten Klose.  Again, the idea is to connect to the core over some kind of serial link.  The original plan was SPI, but there appears to be a growing number of modules that are using IIC – so that's probably what I'll go with.  For early debugging I will most likely just send it bytes over RS-232, but that's neither here nor there.

So, uhh, yeah.  I'm going to try to work a bit on this thing each week, to make some progress.  The actual hardware for one of these is going to be ridiculously simple:  one 28-pin (SPDIP) 18F-series PIC, resistor ladder output, opamp.  Maybe a transistor.  And some jumpers.  It should be easy to make a single 8-voice board... it would have 8 PICs on it, but we might be able to get away with something like the 18F25J10, which costs about 1/3rd of a 18F252.  Anyways, that's TBD.  All this post is really intended as is a teaser...

Link to comment
Share on other sites

Okay, let's answer a few questions...:

@DrBunsen:  the Parallax Propeller seems quite interesting.  I'll have to keep that in mind for future projects. 

I've been pretty much set on the PIC18F-series from the get-go, because (a) they have an 8x8 multiplier, and (b) I know PIC ASM.  As to the specific chip, that will be determined mostly by the size of the wavetable that I cram into there.  Or wavetable(s).  When I left the project before, I had the oscillators prototyped in Labview (which would now need some revising), and had just started coding for the PIC.

The original thread was here, and contains more info about the original development that I had started:  http://www.midibox.org/forum/index.php?topic=3713.0

@mess:  This will be coded in ASM, since I will have to end up counting cycles to ensure that I get the highest output frequency possible.  Yes, it's going to be that close.  As a quick example, assuming 10% overhead for messaging from the core (and safety), at 10 MIPS and 8 kHz output I only have 1125 cycles per sample.  At 16 kHz that's down to 562 cycles/sample, to handle the oscillators, modulation, mixing, output envelope, etc.

The oscillators are pretty straightforward - there will be a waveform table stored in the program flash that will be read with table lookups.  The sample number in a given waveform will be determined by a 24-bit phase accumulator, which in my simulations gave adequate tuning accuracy.  There will be a loss of waveform resolution at higher frequencies - with an 8 kHz sampling rate, a 2 kHz note will only get four (!) samples per cycle - but this will probably be used for lush pads and maybe basslines, so I don't expect that to be a major shortcoming.

@bill:  right now, there's nothing anyone can really do to help.  Once I have the basic concept working - and can verify that it's working over IIC, if there are some enterprising souls who want to take over the MIOSification, that would be excellent.  That's still a long ways off, so I'm trying to actually *get* to that point before I start worrying about MIOS support.  In the event that I don't manage to complete this, I don't want to waste anyone else's time and effort.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...