AndrewMartens

Looks great! Once I started getting back into my projects this last week, I realized that I had almost finished assembling the PCBs for my MIDIbox SID when I shelved it almost two years ago (!!). Then came the matter of needing a case, of course! Are you using the Hammond 1455-series extruded aluminum cases? Could I possibly get the part number from you - they seem to just be purpose-built for the MIDIbox SID! Whoops, just reading your SID-NUXX Wiki, I realized that you made your own board for this one. Still, I'm pretty sure that one could fit both CORE and SID boards into such a case... [EDIT]: Further reading of your wiki reveals the Hammond 1455T1601 as the model. Duh, I'm a moron ::)

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.

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...

Hey stryd_one! Yeah, it's been a while since I last stopped by. In the past year my mother-in-law died, my wife and I bought a house, moved, renovated, and then my brother-in-law died. Really crappy :'( Anyways, I've started to get off my butt and realized that if I never work on any of my projects, then they'll never get done! I managed to track down my Labview code for the DPS audiotest prototype, and made sure it still worked. The oscillators sound great, but the filter was still buggy. For now I think I'll just work on the "VCA", envelopes, and LFOs. Then I'll get all the modulation algorithms, etc. working before I worry too much about the filter. Worst case scenario, I'll just leave out the lousy digital filter, and people can use a nice fat analog filter of their choice. I'm thinking something like: 1 core, 8 DPS modules, AOUT_LC, analog filter. That said, I haven't determined just how many oscillators to stuff into each DPS module - it may even be possible to do them with a lower-cost PIC (eg 18F25J10, which is only $4.57 CAD @ Digikey, or $2.60 CAD in qty 25). Regardless there should be at least two wave oscillators (with anywhere from 64 to 256 waveforms available), each with a suboscillator (square or saw waveform). Or maybe four oscillators, I'm not really sure yet! I also may end up going with IIC instead of SPI, since it appears that there is some decent support in MIOS for IIC-connected modules. Don't want to rock the boat, or create extra work for myself ;) Whoops, didn't mean to thread-hijack. I'll have to update my original thread once I've gotten an ENV / gate / VCA working...

I started working on such a beast a while back, actually. It wouldn't be a clone of the AVRsynth, but some of the concepts are similar. Due to the complexity, I've been scaling back the design - it should end up as a simple module controlled via SPI: a PIC, resistor ladder output (woo, cheap!), and an opamp. That's about it. Two wavetable oscillators, a "filter", an envelope and/or LFO or three, and a few other features. Lo-fi gritty goodness. I had already prototyped the wavetable oscillators in Labview, so I have an idea of what they should sound like. For whatever weird reason, I just became interested in my defunct project and came to check the forums here... There were a couple of samples down near the bottom 1/4 of this page: http://www.midibox.org/forum/index.php?topic=3713.15

I had originally put the POKEY chip on my "Project List" a few years ago. Unfortunately, since then it's been demoted by several other projects. Even more unfortunately, this past year has been incredibly hectic and has included: - change of job - death in the family - bought a house - moved into the house - renovated the house - another death in the family It's incredibly unlikely that I will get to this within the next few years. Someone else with more free time on their hands may be able to work on the POKEY, however.

I was going to do a POKEY synth app for MIOS (and a prototype board), but I got distracted sometime after acquiring a few chips. It would be fun, but unfortunately I just don't have the time for it anymore.

Well, I've been busy this past while: switched jobs to something better (hooray!), still contracting with my old company (=$ to buy test equipment, but then I have no life), and other unhappy things. There's a bright side, though! In my spare time I've been thinking about some of the algorithm problems I was having with the design of the DPS, and I believe most of them are sorted out: envelopes, mixing, interrupts, communication stream, etc.. I'm quite confident that I can get an SPI-controlled quad-oscillator multi-waveform synth working. With luck I'll be able to do one volume envelope per oscillator (=4), two LFOs, and a final DCA with its own envelope. Assuming I can get all *that* working, then I'm going to go back and look at doing some kind of digital filter. Oh, and I'm probably going to just go with an 8-12 bit resistor ladder (R2R) output - if I'm doing an internal DCA then there isn't much point of wasting board space and money with an external DAC. I've also been toying around with the idea of being able to slave up to 16 units off the same SPI bus and being able to either uniquely address each one, or broadcast the same settings to all of them (ie, to load up the same patch for all 16 units). Not sure why anyone would want to do it, but it should be possible. I'm getting to the point when it's time to start consolidating the bits of code and run some simulations in MPLAB. Then it will be "build a prototype" time, and then I should be able to make some noise with this thing.

Cool, this project is somewhat similar to my digital PIC synth project that I'm working on. Though right now I'm hoping to do 4 wavetable oscillators using software-based 24-bit phase accumulators on a single 18F-series PIC.

Wow, I'm surprised about Maddox releasing all that for free... kudos to him! Anyways, looks like this should solve the problem of a free-for-hobbyist-use waveform ROM to use in my digital PIC synth project...

Wow, that looks FANTASTIC! Well done!

Update! Here are two small .WAV files (8-bit mono at 8 kHz, since that's what is generated by the oscillators) with all oscillators mixed equally. This is generated by my Labview testbench application, but should be fairly close to what would be produced by the PIC. The files are hosted on my personal website, so try not to hammer it too hard. http://www.andrewmartens.com/music/dps-test2.wav - four DCOs with different waveforms playing a chord, pitchbent to a different chord and then back. http://www.andrewmartens.com/music/dps-test4.wav - four DCOs playing the same chord, DCO1 is swept through about 120 different waveforms. Next step is to get this transferred over to a PIC!

I'm still working on this. Hopefully next week sometime (?) I'll have an opportunity to post some sounds from the test application that I developed. I temporarily removed the envelopes and filter stuff that I was working on, but instead I got pitchbend to work reasonably well. Right now I need a less computationally-intensive method of doing it (right now it has a 16-bit signed divide, ugh), but it's still making some progress. There's a few personal issues causing trouble right now: my mother-in-law's cancer returned and is probably inoperable this time, and I'm also very close to having a different job that won't drive me crazy every day. So that's a bit of turmoil that's keeping me from doing as much development as I would like...

My initial plan (reading back) was to use a multi-channel DAC to output the waveforms separately, and then do some CV mixing / filtering / envelope / etc. The downside was that I wanted to make a fairly simple low-chip-count module (similar to the SID), which got me thinking about the software filters of the Droid-3, Jarek's AVR Synth, etc. That's why I decided to try and take those features out of hardware and move them into software - then I could even just get away with an R-2R resistor ladder output instead of bothering with a DAC. That said, perhaps I should just shelve the mixing / filter / envelope development for now, and just get the oscillators working in a PIC. I'm sure that there are a lot of people out there who would be perfectly happy with a two-chip module (PIC + quad DAC) that could take a parallel or SPI input and just generate sound. Perfect for the modular analog enthusiast, and so on. Heck, with a multiplying DAC, you could easily have external CV control of each DCO's output volume! For now this might be the best way to go... I think I'll use the parallel slave port interface on a 40-pin 18F4620, which gives 64kB flash for program and wavetables. Anyone who wants to start fiddling with a MIOS application should be able to do so with a pair of shift registers, like the MBHP_SID module. Alternately I could use a 28-pin 18F2620 and go with SPI, but I'll have to delve into the MIOS code a bit more to see what changes would need to be made. Current task list: - set aside mixing / filter code - work on oscillator detuning - order PIC & DAC (probably 18F4620 and TLC7226) - code up PIC oscillator using PSP interface, test & debug (tuning and frequency analysis) - test maximum audio output rate - post a copy of the firmware, basic test schematic and register mapping interface On a side note, one could probably use an 18F452 (since we're using them anyways for the CORE modules) and just use a subset of the wavetable. Likewise, the microprocessor interface is going to be the same for most parallel DACs, so one could substitute in an AD7226, AD7225, MAX506, or MAX505 depending on the features you want and the price you are willing to pay. I'm hoping the TLC7226 sounds "good enough", since it's less than 1/4 the price of those other DACs.

Ahhh, the PT2399. I hate to admit it, but I think those are still available for purchase at Small Bear Electronics. I really need to get some of those chips sometime...

Thanks! I'll probably post some sounds once I have the Labview proof-of-concept finished (two weeks? three weeks?) Then I'll start working on getting everything going in the PIC - I'm doing a bit of that in parallel, just to make sure that I'm not doing anything that requires too many processor cycles, but the full transition will still be a challenge. I remember seeing that in the VCDO schematic... "use a 741 to smooth out the noise!". I'm a bit tempted to actually use a 741 on the output, though I'm sure a TL074 might sound fine. I suppose the actual hardware shakedown will be the true test :-) The design I'm using will probably have a different character than the Digisound. A proper ROM-based wavetable oscillator just cycles the address at (frequency * samples_per_waveform) and writes it to the DAC. What I'm doing is just outputting audio at a fixed frequency (8 kHz is my current target, though I may be able to push that higher) and using the top 8 bits of the accumulator to determine the sample number (or 6 bits in the case of a 64-sample waveform, like the Digisound). Initially I was going to interpolate between samples using the middle 8 bits of the accumulator, but then I realized that (a) it would require a few multiplies, and (b) the impact on the sound wasn't that dramatic - but we'll see, by the time I'm done the basic featureset there might be enough cycles remaining to do it, and it might clear up some of the aliasing. And heck, if a bit of a gritty digital sound isn't bad, I might just decimate the "new.256" table down to 64 samples per waveform as well. That way I could potentially have a number of waveform tables available in the DPS: the "new.256" 256x64 table (16kB), the Digisound VCDO 32x64 table (2kB), something else (there should be another 4 or 8kB free), and possibly a software-loadable wavetable in the onboard EEPROM (the 18F2525 has 1024 bytes of EEPROM, which would allow for a 16 waveform user table).

The beauty of using a wavetable is that I have a 64 (or 256) sample sinewave in there (and a lot of other waveforms, with and without harmonics, etc.). The trick is to keep an accurate accumulator so that you know which index to output to the DAC. That way, there's no trig calculations whatsoever. The most computationally-intensive part of the whole thing is mixing the waveforms and running them through the filter.

The idea has been tossed around here before (just do a search for POKEY), and some of us have acquired POKEY chips already. It's just a matter of someone having the time and desire to build a MBHP_POKEY board and the more difficult challenge of developing a MIOS application to make good use of it.

Thanks! I'm hoping that someone will want to build a MIDIBox DPS (Digital PIC Synth, what I've currently dubbed this project) once I'm done. I was never very good at my signal-processing courses at university, so I haven't been able to come up with anything very clever. However, from Jarek's AVR Synth code at http://www.jarek.synth.net/AVRSYN.asm he had some code for his Simplest Low Pass Filter Ever, which wasn't fancy but it worked and definitely filtered the sound. Then "Krue" tidied up the code a bit and also was working on implementing a HPF, and his code is at http://krue.net/avrsyn/avrsyn.asm . The equation in question is just: y[n] = y[n-1] + m * (x[n] - y[n-1]). In english, that's: OutputValue = PreviousOutputValue + CutoffCoeficcient * ( WaveValue - PreviousOutputValue). My existing Labview implementation of the filter looks like this: http://www.andrewmartens.com/images/DPS-filter01.jpg There's some clipping issues with the output waveform, but that's because I still have some U8->I16->U8 issues that I haven't bothered to fix yet. On a different note, I'd like to point out the "De-Rez" feature that I added. It was initially intended to reduce the bit depth of a given waveform, ie from 8-bit to 4-bit resolution, or whatever. I decided to just take the 8-bit De-Rez value and AND it with the waveform sample. Someone might be able to do something clever by modulating this value. Those are some intriguing ideas that you have. Right now I'm concentrating mostly on getting the sound mixing happily and tweaking the filter a little bit, including the distortion modes. After that I'm going to look at doing the envelopes and making those work. Once I have that making noise on a PIC, I'll probably release a 0.5 version to everyone so that people can start fiddling around with MIOS or whatever. But still, here's my comments on them... 1. Sample length feature: this would be difficult to handle in the DPS itself, as it would require recalculating of the 24-bit phase accumulator delta on the fly - and I'm currently doing a table lookup to correlate MIDI note number & pitchbend to the delta value. I suppose that could be offloaded to the MIOS application, but then it would require calculating a 24-bit number whenever the wavelength value is modified. 2. Waveform number (for each oscillator) is just an 8-bit parameter passed to the DPS. This could be modulated by the MIOS app in however many dimensions you wanted, it would just depend on the wavetable layout. 3. Is this like sequencing a wavetable? Again, this could be done in MIOS. 4. This sounds like a digital version of a slew-rate limiter. It could be calculated on the fly in the DPS, but it might require more processing power than I will have remaining - I think it'll already be a bit tight getting the envelopes in there. Labview isn't too difficult to get the hang of, it just takes a bit of time. I haven't really had any formal training with it, but I can get by. The only real limiting factor to using it for hobbyist purposes is the very-steep price tag (a single seat of the Full license that we have at work costs $2395 USD)!!! My current diagram is here: http://www.andrewmartens.com/images/DPS-main-diagram.jpg

I successfully ran a small pattern sequencer called "TTRK" (tektracker) on a P120/32 laptop with a 2.2 Debian install. It's made by a guy named Billy Biggs - http://vektor.ca/audio/ttrk/ At the time I made a few modifications to it, mostly because I didn't like how the scrolling setup worked. I may have backed up that code somewhere, I'm not sure. I got the thing working, but I only had a serial output on the laptop, and when I ran it into a Windows 98 desktop I experienced some jitter when passing the data through to hardware MIDI gear (probably Windows-related, but I'm not sure). If you've got linux-supported MIDI on your laptop, it would be a good program to use - it runs very nicely in the console, so you don't need to worry about X hogging any CPU time. I think I ended up running as root in singleuser mode, but it worked well.

I'm working on a PIC-as-synth-chip design that basically uses a second PIC (connected to a MBHP_CORE module via SPI) as a synth chip. I'm taking inspiration from wavetable synthesis (Digisound, Wiard), the SID, Jarek's AVR Synth, and the Droid-3. Info in this thread: http://69.56.171.55/~midibox/forum/index.php?topic=3713.0 The advantage (assuming I get it working happily) is that one could use a readily-available 28-pin SDIP PIC18F252 (or similar) as a synth - no needing to source SIDs or FM chips or anything. If this works I'm going to have the source and binaries for download so that someone can make a MBHP_ module out of it, so it won't cost hundreds of dollars.

Since I'm having fun with this project (for a change), I'm going to post updates here. Most of you probably don't really care, but someone might be curious, or might be able to make useful suggestions, so this is what I'm going to do. Yesterday I analyzed "Jarek's AVR Synth" and got a few ideas from it. Well, three main ideas. The first: since I'm probably going to have MIOS core unit updating all of the envelopes (still pending, since I still might be able to cram those into the PIC), I may as well do all of the mixing in the PIC as well, and just output an audio stream (no CV). The second: since I'm just outputting audio and no CV - and doing all of the mixing in the PIC - why not just use a resistor ladder output? It's a lot cheaper than a DAC! The third: ooh, a simple filter! Neat-o! The filter sound is pretty basic, but it's much better than no filter. I'm going to do some more experimenting with the filter sound and see if I can improve it a bit. Also, I was looking at the Droid-3 synth and hopefully I can implement something similar to their boost and distortion modes. The tuning issue I mentioned yesterday was a result of just using a 16-bit phase accumulator, so I increased that to 24 bits. It only takes a handful more cycles, and it improves tuning from about +/- 0.5 cents (according to the frequency analysis) to about +/- 0.01 cents, and possibly better. I wasn't running the analysis on really long samples, so the short sampling time probably resulted for a bit of that error. While I'm not happy with the sound yet, I did post a screenshot of the testing interface I threw together. This is all still software running in Labview at the moment, but it really works well for determining what sounds good and what doesn't - without having to mess with the code / burn / test cycle in hardware. Screenshot is here: http://www.andrewmartens.com/images/DPS-dev01.jpg (1280x994, 224 kB, JPEG 80% quality).

Well, it's been a long time since I posted anything about my development projects. Luckily, I actually had time the other day to fiddle around with the PIC-as-wavetable-oscillator concept. I tried two sets of wavetables: the first was the 2kB (32 waveforms at 64 samples each) ROM from the Digisound VCDO, and the second was the 64kB (256 waveforms at 256 samples each) "new.256" ROM from Wiard that I found on the net somewhere. I decided on 8 kHz as the sample output rate, because I'm not going for super high fidelity here - otherwise I would go out and buy a commercial synth and be done with it. Each oscillator has a 16-bit phase accumulator, of which the upper 8 bits determine the current sample to play. Rather than actually going and spending tons of time writing code for the PIC to handle this, I just threw together some Labview code. It reads in the wavetables, lets me select the note frequency and waveform, and then does table lookups with a 16-bit accumulator and outputs audio at 8 kHz, 8-bit mono to the soundcard. I found that the 256-byte waveforms sounded great and appeared to stay in tune throughout the musical scale. However, there was some noticable aliasing present in the 64-byte waveforms (and a bit present when I downgraded the 256-byte waves to 128 bytes). There appeared to be some tuning issues with the 64-byte waveforms, but now that I think about it, I think I made a slight coding error that reduced the accumulator to 14 bits - I wrapped the accumulator high byte at >= 64, instead of shifting it right by two bits to select the appropriate waveform. Okay, well, that should fix the tuning issue. Once I had the successful proof-of-concept that I was happy to listen to, I've started writing up some code for the PIC. The planned target is the 18F252 (or newer 28-pin), but I will probably do my prototyping on the 18F452. The plan is to control the prototype through the parallel slave port (PSP) to load values into synth registers. I can use a simple USB multifunction DAQ to do that with Labview, and then read the waveform back into the computer. That will allow me to run a frequency analysis and check that the tuning of the hardware device is behaving as expected. I still haven't decided exactly what extra features should go on the board, or whether I should just develop this as a two-chip (PIC+DAC) wavetable oscillator solution and let others add filters / envelopes / etc. to it. The current plan is to use an inexpensive TLC7226 quad 8-bit DAC - two channels for audio (OSC1+sub, OSC2+sub), and two control voltages (filter cutoff, filter resonance) - and then a 4-bit resistor ladder output to control the post-filter volume (like the SID does). However, some people might prefer to use the AOUT board to get more flexibility with MIOS (more envelopes, LFOs, etc.) and build their own filter + VCA board. That's still a ways down the road, so I'm not that concerned yet. I'll probably post some Labview-generated audio samples of the concept in the next few days. More will be forthcoming once I have some hardware that works.

I think that the trick is you would need to write a custom program that runs on the SPC700 and contains a bunch of basic (or not-so-basic) waveforms, which would then accept input from the MBHP interface and load it into the DSP. http://emureview.ztnet.com/developerscorner/SoundCPU/spc.htm Then you'd still need to make your MIOS code to load code into and communicate with the SPC700. It'd be very difficult to do all of this, but it's possible...

It's definitely possible to do a MIDIBOX-SNES... I had no idea that Nintendo put the APU in a neat little module like that! Hardware-wise, the control signals for the APU system seem to be very similar to those of the SID. Most of the hardware design can be cannibalized from the MBHP_SID board, at which point it just becomes a matter of writing a custom MIOS application to take control and do cool things of the SNES-APU. If you've got the time and motivation to do it, it would definitely be a very cool project! I have a few old-sound-chip projects in the pipeline, but since I don't have any time to even finish my MIDIBOX SID, they're not getting done anytime soon. I'd be impressed to see a MIDIBOX-SNES, though - I'm sure someone here could easily do it!