MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

DIY Poly Synth Processor? (analog sound, digital control)
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page 1, 2  Next [all]
Author DIY Poly Synth Processor? (analog sound, digital control)
Tristana
Hi there-

I'm hoping to design a poly synth where all the sound generation is analog (based on the CEM/AS chips) but the voltage control is done by a microcontroller or microprocessor (digitally). My aim is to create voice cards that can be added rather simply to the synth as resources become available.

By using a microcontroller/microprocessor, the circuitry to control the oscillators becomes greatly simplified + there is the potential for things like patch recall, software control, etc.

Initially I've been looking to an Arduino Mega 2560 as an easy to use option- but now I'm worrying I'll run out of I/O.

For inputs there'll be,
Two 2-way switches
Two 3-way switches
19 rotary encoders
MIDI input (1 pin)

Meanwhile, there are 16 global CV outputs(referenced by each voice), 3 of which can be digital, as well as 4 CVs per voice.

If I've mathed right, even making use of the Mega 2560s 16 analog inputs & having a separate DAC (given that there are only 15 PWM outputs), it seems that the synth could then only have up to 7 voices, fully maxing things out.

Preferably I'd like the option to expand to an 8-voice poly at some point, and so I ask you, wonderful wigglers-

What microcontroller or microprocessors should I have a look at? I'm hoping to find something that can be coded in a high-level language as I've never worked in assembly or below.


disclaimer: I'm a programmer/engineer, not a calligraphist
abelovesfun
Take a look at the Ambika. It isn't fully analog, but I absolutely love mine. Really nails the JUNO sound.
djs
You might want to take a look at the midibox architecture. I haven't worked with it, but it looks like it can probably handle more i/o?
Chrutil
I tend to go with a Teensy 3.1 as my go-to microcontroller for most things I do. They are cheap (~$20) and fast. The Mega will work just fine though.
Running out of IO is generally not a problem. Use the MCP23S17 (SPI or mcp23017 for i2c) for 16 digital read/write pins per chip, and you can use as many chips as you need.
For your analog inputs, you can experiment with a 4051 mux, or simply use a couple of 8 channel ADCs (like a few mcp3304)
For your analog outs I would just use a couple of 8 channel DACs like the MAX5725 or similar.
It also depends if you are comfortable with smd as the selection of DAC/ADC is limited in thoughhole.

Sounds like a great project - good luck!

[Edit: misstyped dac name]
JanneI
Is there a reason for CEM envelopes? Wouldn't it save some cv outputs to do it digitally?
guest
i agree with chrutil, dont worry too much about the platforms IO, you will have to mux the IO with almost any micro. youll probably want higher precision ADCs anyways for the pitch CVs, so some SPI ADCs will go a long way. as for which micro, if you dont already have experience with one, then the teensy is probably the way to go. that and the arduino both have a large user base and good online support forums, but the teensy is way more powerful, so you dont have to worry about writing efficient code.
Tristana
JanneI wrote:
Is there a reason for CEM envelopes? Wouldn't it save some cv outputs to do it digitally?


I’ve thought on this, and haven’t been quite certain if the curved/exponential sound of analog envelopes is a result of the ADSR setup or the VCA.
Jaytee
Tristana wrote:
JanneI wrote:
Is there a reason for CEM envelopes? Wouldn't it save some cv outputs to do it digitally?


I’ve thought on this, and haven’t been quite certain if the curved/exponential sound of analog envelopes is a result of the ADSR setup or the VCA.


If you do digital envelopes, you can toggle between linear and curved envelopes.

Wanted to second Teensy. MIDIbox is well-suited to the task, but the programming is IMO not as friendly.
JanneI
For example Deckards Dream uses digital envelopes..

Jaytee wrote:
Tristana wrote:
JanneI wrote:
Is there a reason for CEM envelopes? Wouldn't it save some cv outputs to do it digitally?


I’ve thought on this, and haven’t been quite certain if the curved/exponential sound of analog envelopes is a result of the ADSR setup or the VCA.


If you do digital envelopes, you can toggle between linear and curved envelopes.

Wanted to second Teensy. MIDIbox is well-suited to the task, but the programming is IMO not as friendly.
flts
Agree regarding Teensy (3.x) that people have recommended - primarily because of what guest mentions: you're looking at so much more resources compared to Arduino Mega that it'll be easier to pull off whatever you want without having (yet) much experience with embedded programming. Plus it's nice that the form factor is so small. You'll probably have to learn how to interface with a bunch of peripherals (GPIO expanders / multiplexers, ADCs and DACs etc.) in any case.

People I know who work with modern MCUs say that unlike in the age when 8 or 16 bit microcontrollers were state of the art, Assembly is all but gone from their daily jobs. Bulk of the code is written in C because the modern compilers usually optimize better than a human does, and the rare cases where eg. inline ASM is needed are probably not something you'll stumble upon as a hobbyist right away. So don't worry regarding that.

However, if you're serious about what you're doing and have background in software development so you aren't leaping from zero to embedded C, I'd probably either skip the Arduino/TeensyDuino IDE and language / libraries altogether or start learning from there and move to something else pretty quickly. Don't get me wrong, you can do a boatload in the Arduino environment and it's perfectly OK if you find other options intimidating, but it feels like a bit difficult environment for managing and building larger projects and the included libraries often abstract low level details in a silly, not-so-efficient way.
Tristana
Thank you for all the great advice everyone! SlayerBadger!

@fits I do have plenty of high level coding experience (coded robots since the age of 10 and studied CS & Music Tech!) so mucking around with C is perfectly fine. Will take me back to my vEx days haha!

@Chrutil thanks for that suggestion, the Teensy seems the way to go for price & power.

So with digital envelopes as @JanneI mentioned (does anyone know the function for the analog-envelope curve btw? exp of what factor?) that takes us to:
Global outs (8):
• Osc1 Wave
• Osc2 Wave
• PW1
• PW2
• Sync enable
• Filter resonance
Per voice (5):
• Osc 1 Pitch
• Osc 2 Pitch
• Osc 1 Gain
• Osc 2 Gain
• Filter Frequency
Inputs (25):
• 19 rotary encoders
• MIDI Input
• 5 switches

My understanding then is that an 8-voice poly could be realized with a Teensy 3.x, with 5x MAX5725, yeah?

The 25 digital inputs directly to the teensy, with the MAX5725 DACs handling the output CVs. Could also save on a DAC by using PWM and the 1 analog out but meh!
Tristana
Also, some voltage questions-

Seems the CEM3340 isn't gonna play nice below 10v, so I figure a 12v supply (to parallel my eurorack circuits) would make sense, with it attenuated to line-level at the output jack.

That said, the CVs from the MAX5725s seem to be 5.5v maximum if using the supply as a reference. Fine for, say, the PWM control, but no bueno for the pitch CV.

Would the best way to handle this be to amplify the CV after the DAC? Perhaps using the 4v supply for a simple x3 multiplication? Or should I look for a different DAC?
KSS
Would suggest having a read through the service manuals for the prophet 5
and other old polys. The 8 spoked wheel you're chasing has been made before and their results have clues and details which are still relevent.
Tristana
KSS wrote:
Would suggest having a read through the service manuals for the prophet 5
and other old polys. The 8 spoked wheel you're chasing has been made before and their results have clues and details which are still relevent.

afaik the poly of yore weren't done with microprocessor control razz the old boys are quite a bit more complex!
Jaytee
Tristana wrote:
KSS wrote:
Would suggest having a read through the service manuals for the prophet 5
and other old polys. The 8 spoked wheel you're chasing has been made before and their results have clues and details which are still relevent.

afaik the poly of yore weren't done with microprocessor control razz the old boys are quite a bit more complex!


Pretty much anything with patch memory is controlled with microprocessors.
Graham Hinton
Tristana wrote:
What microcontroller or microprocessors should I have a look at? I'm hoping to find something that can be coded in a high-level language as I've never worked in assembly or below.


Before that can be answered you have to define the system and its architecture and timing. Do you have a keyboard, control panel and a UI to process as well? You may need to use several processors to divide the tasks up or to use dedicated hardware to unburden a processor. Where you decide to draw the dividing lines will make a large difference. Hardware/software tradeoffs are critical.

Then you have to work out how you will debug it and what sort of development system you need. Most software IDEs fall down when it comes to real time problems and this project is all real time problems.

I have always used a disassembling logic analyser for this sort of work. That is a device that shows you the code that was actually executed rather than what you thought you wrote and which can save months of tearing your hair out. Unfortunately they are pretty hard to find now (which explains why so many products are shipped full of bugs).

Writing in high level language and especially using supplied libraries gives you little control of timing. How many libraries have you seen that list execution times or are designed to be used with heavy interrupts?
Synthiq
Tristana wrote:
Inputs (25):
• 19 rotary encoders
• MIDI Input
• 5 switches

Rotary encoders normally have 2 quadrature outputs so plan for 44 inputs.
Tristana
Graham Hinton wrote:
Before that can be answered you have to define the system and its architecture and timing. Do you have a keyboard, control panel and a UI to process as well? You may need to use several processors to divide the tasks up or to use dedicated hardware to unburden a processor. Where you decide to draw the dividing lines will make a large difference. Hardware/software tradeoffs are critical.


The time-critical function of the synth will be sending control voltages to the sound generation circuitry. Processing MIDI data or interface data (knob movements and such) and changing the control voltages accordingly are additional tasks.

I’ve done some plug-in dev so I know a bit ‘bout thread priority and not-locking and such. I (perhaps falsely?) assume it’ll be much simpler to implement than with a computer, given that there’s only CV & interface handling for the processor to take care of.
Graham Hinton
Tristana wrote:

The time-critical function of the synth will be sending control voltages to the sound generation circuitry.


Yes, sure, but what I meant was that you have to define what time resolution you need and then work out if you can implement it. E.g. do you want to update the CVs on a 2ms, 1ms or 0.5ms schedule? Can you execute the necessary code in that time frame? How are you going to prove that?

Quote:
Processing MIDI data or interface data (knob movements and such) and changing the control voltages accordingly are additional tasks.


Both of those are non-trivial and non-forgiving tasks. With MIDI you have to guarantee to be able to process whatever comes in and if you miss one byte all hell breaks loose.

You said encoders rather than pots and quite a lot of them. There is a good reason you don't often see more than four or so on most products. Every edge has to be debounced, are you going to do that in hardware or software? If you miss any edge it will appear to be rotating in the opposite direction.

Quote:

I’ve done some plug-in dev so I know a bit ‘bout thread priority and not-locking and such. I (perhaps falsely?) assume it’ll be much simpler to implement than with a computer, given that there’s only CV & interface handling for the processor to take care of.


Only? Please don't think this is a put down, but you don't realise how difficult this project will be. It isn't really an ideal first project if you have never done any microprocessor development before. You can't just write the code and load it and it will "just" work. What I suggest is you break it down into smaller manageable tasks and make a set of building blocks that you later will put together into this project. It is as important to learn what not to do as what to do. Try something like a MIDI to CV converter first, that should give you a MIDI and an analogue output building block, then try some UI development, then put those together and so on...
You need to try to break them too. If you think you can read MIDI does that mean it won't crash if something sends a 16K SX block at it?

What you are attempting is something on a scale of the Emu Audity (the first one) or the Crumar GDS and you ought to do some research into what happened to them and why.
mutronic
Tristana wrote:
Thank you for all the great advice everyone! SlayerBadger!

@fits I do have plenty of high level coding experience (coded robots since the age of 10 and studied CS & Music Tech!) so mucking around with C is perfectly fine. Will take me back to my vEx days haha!

@Chrutil thanks for that suggestion, the Teensy seems the way to go for price & power.

So with digital envelopes as @JanneI mentioned (does anyone know the function for the analog-envelope curve btw? exp of what factor?) that takes us to:
Global outs (8):
• Osc1 Wave
• Osc2 Wave
• PW1
• PW2
• Sync enable
• Filter resonance
Per voice (4):
• Osc 1 Pitch
• Osc 2 Pitch
• Amplitude
• Filter Frequency
Inputs (25):
• 19 rotary encoders
• MIDI Input
• 5 switches

My understanding then is that an 8-voice poly could be realized with a Teensy 3.x, with 5x MAX5725, yeah?

The 25 digital inputs directly to the teensy, with the MAX5725 DACs handling the output CVs. Could also save on a DAC by using PWM and the 1 analog out but meh!


I highly doubt you would be able to pump out 8 voices with a teensy. I could see each voice housing a teensy, but that's somewhat economically impractical given you could accomplish the same thing with an atmega chip at the fraction of the cost. Also, 19 rotary encoders is a lot...like more than I've ever encountered on a BOM. You would use normally rotary encoder for something corresponding an LCD and microprocessor.
Tristana
Quote:
What I suggest is you break it down into smaller manageable tasks and make a set of building blocks that you later will put together into this project. It is as important to learn what not to do as what to do.


My dude- this is how I get projects done anyways. I have an understanding of design patterns.

Some of my earliest coding experience 13 years and half my life prior was working with a microcontroller to create robots for the Trinity Robot Firefighting Competition, where-in my team won IEEE awards two years in a row while I was the head programmer.

I appreciate the snippets of advice hidden in the big load of condescension though nanners . I’ll look into pot based input circuitry.
Tristana
To state my aims here:

I’m looking to create a software-controllable, analog-sound poly for my personal use. I’m not looking to create a product for the market and thus creating the most financially and resource efficient design isn’t paramount.

Where I lack knowledge is in interfacing circuitry with a microprocessor/controller. On the software end of things, I am more than confident I will come to a design that will accomplish my goals- that is not a concern here. I get things done, and I’m not on any time constraints other than self-imposed ones.
Chrutil
mutronic wrote:

I highly doubt you would be able to pump out 8 voices with a teensy. I could see each voice housing a teensy, but that's somewhat economically impractical given you could accomplish the same thing with an atmega chip at the fraction of the cost. Also, 19 rotary encoders is a lot...like more than I've ever encountered on a BOM. You would use normally rotary encoder for something corresponding an LCD and microprocessor.


I think you are assuming that the Teensy will generate the sound, but in this case it will not.

I don't recall OP's exact specs, but on a normal poly, unique to each voice card is only the CV/Gate and possibly an autotune signal for each oscillator. The rest of the signals are common for all voice cards and only used for patch recall and parameter editing - nothing too sensitive to a little bit of latency.

That many encoders may be an issue, or maybe not. It looks like someone has experimented with encoders and ioexpanders here, so that can be something to check out: https://forum.arduino.cc/index.php?topic=465225.0
Or simply go with potentiometers and ADCs, that's probably what I would do myself.

I think a comprehensive list of microcontroller tasks would be something like:

a) Patch recall
b) Live parameter editing (pot or encoder reading)
c) MIDI to CV/Gate to drive the voice cards
d) Autotune
e) Software Envelopes
f) One or more LFO's
g) Bunch o' LEDs, possibly using a MAX7219
h) Maybe a small display

I have done most of these at one time or another but the two unknowns for me are:
1) Lots of encoders. I have done a few encoders, but never this amount of encoders at the same time.
2) Software envelopes timing requirements.

For the real-time aspects, my main worry would be to drive 16 software envelopes while the microcontroller is dealing with MIDI and Encoder data.
I have seen a Teensy being flooded by MIDI messages from wonky devices causing a sequencer to skip beats (drag a few sliders on a TR-8 during playback, for example). If you were to offload MIDI to a second mcu that'd take care of that, or possible beef up the MIDI library or roll your own to prevent resource grabbing.

I don't know how sensitive the envelopes are to glitches. Perhaps a little, perhaps a lot - but if you are driving a self resonating filter you'll probably hear any hickup clearly. Fast suitable curves could probably be created with a LUT and linear interpolation, or maybe the actual math is fast enough.
Personally I'd go with 3310's, mainly because it all the cool machines way back when did, and I like voice cards to be as independent as possible from the host - but again that's a design preference not a right/wrong thing.

If you get into performance problems, depending on the type of issue, the mitigations could be either to offload something to a second MCU, or just get a faster MCU - The Teensy 3.5 or 3.6 are compatible and super fast and still won't break the bank.

All in all a very cool project. Hope you keep us posted!
flts
Chrutil wrote:
For the real-time aspects, my main worry would be to drive 16 software envelopes while the microcontroller is dealing with MIDI and Encoder data.
I have seen a Teensy being flooded by MIDI messages from wonky devices causing a sequencer to skip beats (drag a few sliders on a TR-8 during playback, for example). If you were to offload MIDI to a second mcu that'd take care of that, or possible beef up the MIDI library or roll your own to prevent resource grabbing.


Yeah, with a lot of encoders, spinning several of them wildly around at once, you are going to have to think interrupt handling carefully, I'd guess. You can't really skip or shuffle even a single edge / transition without getting incorrect direction readings. I don't have an experience of reading ~20 encoders at once - I'm sure that when one is prototyping something for her-/himself, one can try out and iterate, but this is something I think could take some learning to get "right".

Of course, if you have 20 encoders and only ever turn 1 or 2 of them at once, it may not be much more complex than having 4 encoders and turning 1 or 2 of them at once, because you're looking at a comparable amount of interrupt handling.

Potentiometers will be a vastly easier choice technically, but it's probably going to be fun to experiment what's going to be achievable.

With MIDI, you're looking receiving at most 31.25 kbit/s of data (31250 baud), on a Cortex-M4 clocked at 50-100 MHz, with several actual hardware serial ports you can use - some of them with FIFOs that reduce the interrupt overhead even more. If you want to go wild you can even do DMA.

As long as you're filtering and queuing all MIDI data quickly when it comes in, and processing the result (the potentially heavy part) outside the interrupt, I wouldn't think there's a major problem with keeping the actual control voltage / envelope generation glitch-free and at a nice refresh rate with that kind of hardware. Or, rather - receiving and storing MIDI messages, when done properly, will most probably not be the bottleneck in keeping all the control voltages going.

This is assuming one is willing to roll their own handling code for everything that pre-made libraries aren't doing in an adequate manner - which looks like OP is completely prepared to learn / do.

One thing is, of course, that if you aren't going to add another layer of abstraction in form of a RTOS (eg. ChibiOS or FreeRTOS, I'm not sure if they're viable options with something like Teensy 3.1), you're looking at learning more about timing and interrupts rather than threads and their relative priorities. It's not rocket science and the OP may already be very familiar with these, of course. Just a random note, that there's going to be less helpful stuff between the CPU/MCU and the software written, than what one would have with eg. VST/AU development.

Quote:
I don't know how sensitive the envelopes are to glitches. Perhaps a little, perhaps a lot - but if you are driving a self resonating filter you'll probably hear any hickup clearly. Fast suitable curves could probably be created with a LUT and linear interpolation, or maybe the actual math is fast enough.


FWIW if you're using the kind of DACs people usually use for CV (eg. ones that work nicely for precision DC), they don't require a steady stream of data unlike audio codecs. They just update their output value on command - meaning if you miss processing / writing a block for some reason, you won't get a dropout, but a stuck value.

You'll still want to run the output at a steady rate in case of envelope generation, but chances are it'll be much, much lower than what you'd use for audio, which relaxes the resource / timing requirements - what the acceptable sample rate is for a given use, and how much one can get out of particular hardware is what one has to find out.

Plus as you say, if one hits a roadblock with Teensy 3.1/3.2, there's always the Teensy 3.6 and 3.7 as an "easy" upgrade path with same kind of architecture and similar form factor. They don't cost much, so it could be worth specifying a 3.7 for a hobby project in any case - especially if it looks like there'd be a lot of channels of eg. envelopes and LFOs to generate and spit out.
Tristana
Appreciate the input!

Pots & ADCs seems to be the smarter way to go. Will have to work out the knob behavior when loading a preset (what amount of voltage change on a pot = change the parameter from the preset) but that can be done.

I could of course do something as simple as one encoder and an LCD, but I don't like menu-diving and would prefer to make a hands-on instrument a la the Minilogue.

A DAC that latches it's output will be optimal for avoiding glitchiness, certainly.

I may indeed just sport for the beefier teensy's as the price difference isn't significant for a one-off project.
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page 1, 2  Next [all]
Page 1 of 2
Powered by phpBB © phpBB Group