Java Synthesizer, Part 23, Full Synth


It’s funny, how, as I try to verify new sections of the app, especially after connecting up the A-300, just how many new bugs I find. In some cases, it’s obviously a copy-paste error and I wasn’t careful enough in making all the changes needed. In others, I have no idea what I was thinking as I wrote something that obviously can’t work as-is. And occasionally, I simply didn’t realize that certain conditions could combine and never added checks for them.

I’m trying to get more interesting sounds out of the program, while also imitating existing old-style hardware synths, like the early Moog boxes. So, I figured that I’d make one big circuit and leave the plug-cable wiring for later when I wanted to experiment with a specific patch. This meant putting 3 oscillators, a gate osc., the ADSR, a VCF and the VCA amp into one file. However, the first circuit, a simple gated ADSR driven by three offset oscillators, didn’t work. In fact, it didn’t work for quite a few reasons.


(Full-blown synth circuit wiring diagram. osc2 and osc3 are driven by the frequency out of osc1 and offset via the benders. The ADSR generates separate gate events for each of the attack, decay, sustain and release modes, so I’m using the A, D and R events to gate the noise1 generator. The splitters just take whatever value is applied to the input and clone it to each of the splitter output pins. This allows a one-to-one pin wiring when making connections between modules. The mixers act in a similar fashion for the one-to-one pin assignments, but can be used for signal averaging or scaling, or as boolean AND and OR gates. While the wiring is user-definable for most of the modules, the keyboard, VCF (voltage-controlled filter) and pan are the exceptions; for these, I pretend to have fixed box inputs and outputs that the other modules can tie to.)

First was that as I increased the number of modules, the workload in the processSound() method started pushing the limits for the 44K sampling rate. I dropped back to 16K, then tried bringing the FFT array size from 1K to 2K, but the sound broke up again. Currently, sampling rate is 16K and the FFT array is at 1K, which still sounds pretty good.

Second, the code for saving and restoring the pin values (i.e., the range settings) behaved randomly, and the amplitude for the pan module kept going to 0. Took a while before I realized that if I programmed a specific slider or dial to a module input (i.e. – the input pin for that module), when I loaded the patch from file that the connector object was defaulting to 0.0 for each connected pin. That is, even though I was preloading the settings into the range objects, the connector object was overriding the settings with 0’s when processSound() started running. Copying the settings into the connector object for each pin connected to a control (dial or slider) fixed that problem.

Third, the drum pads on the A-300 keyboard were producing multiple button press events, and causing havoc with the menus. Before, I’d been tapping the pads fairly quickly, so I could mimic clicking on the Next and Previous buttons pretty easily. Now though, I was pressing the pads longer and skipping 3-4 screens at a time. I needed to modify the updateFromKeyboard() method to only send one .doClick() message per pad press.

Youtube link.

Fourth, the canned module code hadn’t kept up with the changes I was making to the command line parser. So, while I could create a new custom circuit by hand-entering the code from the command line, trying to do the same thing through the menu items was causing parser errors. So I had to double-check each line of the canned code and tweak that to match the parser syntax.

Fifth, the arp module was misbehaving. The patterns weren’t running, the steps between notes weren’t noticeable and the canned code didn’t include an option for wiring the arp module to the keyboard input pin. As a part of the fixes, I added a step option to allow the user to scale a “0 1 2 3” pattern to “0 2 3 6” or “0 3 6 9”. The bigger steps make for more noticeable changes and make it easier to tell if the pattern is running.

There were a number of other minor tweaks, and typos that I noticed in the comments that I also addressed. I started out with just one oscillator, and with each new circuit added one or two more modules, made the wiring connections and verified that those worked before incrementing to the next circuit. The final package has what I’d tried to do when I did the full Moog emulator a week ago.  The difference being that everything runs correctly now. There’s still noise and breakups when Windows does something in the background, so I’m thinking that running this app on a Linux box is the only way to go.

Full Circuit Patch textfile.

Advertisements
Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: