Gakken Animaris Imperio Review


(Images from the Gakken site used for review purposes only.)

(I don’t have any photos of my own to include here this time, because my camera got dropped and it hasn’t been repaired yet.)

Gakken’s latest kit, number 37, (2950 yen) is the Animaris Imperio, AKA -The Bipedal Robot. This is the third in the series of machines based on Theo Jansen’s linkage design. (According to an earlier Gakken newsletter, “Imperio” was chosen by Jansen for the beest’s name because it refers to the Emperor Penguin in Latin, and was influenced by the beest’s “waddle walk”). The idea here is to use a pair of control rod assemblies (one pair per leg) that causes the leg to pivot at the ankle to maintain the beest’s center of balance throughout the walk cycle. The exact details of this process are described in one of the articles in the mook. The beest’s primary motive power, as with the previous 2 kits, is a wind-driven fan. (Note that the cover image on the mook is inaccurate; the pivot action at the ankle causes the beest to tilt significantly towards the side of the planted foot. The picture has it more vertical in midstep.)

There’s no new theory to talk about this time. The crankshaft has 4 crankpins, two for each leg (the 2 crankpins work together to push or pull the left and right sides of the foot to create the pivot motion at the ankle). The fan attaches to a preassembled driveshaft built into one of the frame pieces, which in turn spins the gears on the left side of the beest to rotate the crankshaft. One interesting thing is that the design includes a long plastic tube within the frame, containing 4 steel balls that roll over the supporting foot for balance (called the “balance bar”). Mods suggested in the mook are to add a marble machine to the top of the frame, to turn the beest into a baseball field mascot pulling a roller drum, to place an LED with a small battery inside the balance bar, and to add a micro-motor and lithium battery.

(Gakken’s official youtube video.)

Suggested assembly time is 60 minutes, and it took me 90, mainly because I had lots of problems understanding the pictures and I had to take the legs apart several times to fix my mistakes. In essence, though, the idea is simple. You start out with the A-frame for the left leg, and start attaching the triangle pieces to each side of the A-frame, while putting a long or short control rod on the pins in the middle of the leg. A pair of straight pieces are used to form a box with the second set of triangles. When you’re done, you’ll have something that looks like a crane arm, with one end of the “crane” connected to one pin of the A-frame. Most of the connections are just slotted pin-and-holes, but you’ll need to use the small metal screws to fasten the pieces together securely (being careful to not strip the threads). One tricky part is when you have to pull the left and right halves of the leg apart to get one of the longer pins to fit in the hole. The plastic is flexible, but you want to avoid pulling so hard as to snap something. Repeat with the right leg.

When both legs are completed, you assemble them along with 3 more A-frame pieces (middle with the drive shaft, plus left and right ends (the gear shaft is on the left when the kit is facing you)). Together, the 5 A-frames make up the “body frame” of the beest. Put the small hex nuts into the plastic end knobs, run the stiffener rods through the holes at the three corners of the A-frames, and tighten. For the “central” rod (the one not at the top or bottom of the legs), you’ll need to also put on the balancer holders – two short arms that will hold the plastic tube with the steel balls inside. The key things to be aware of here are that the A-frame pieces need to be aligned so that they all have the crankshaft holder arms lined up in the same direction. And second, that the balancer holders point towards the back of the machine within the gap in the legs.  Attach the long and short control rods as shown in the diagram. Hand turn the crankshaft to make sure it rotates easily. If not, at least one of the control rods is probably in wrong and will need to be fixed.

If the legs move freely, then add the balancer (put the balls into the tube, put the threaded endcaps on the tube, and put the assembly into the holders). Stick the two little squares of sponge into the bottoms of the feet so they’re at the inside back corners where the unattached parts of the leg will press down on them. Attach the feet to the legs as shown in the diagrams. Finally, put on the gears, assemble the fan using the double-sided tape, and put the fan on the fan shaft.

Regarding tools, you’ll need a small Phillips head screwdriver, and you may want a sharp pocket knife. The leg pieces need to be removed from the “tree”, and you might want to shave the flash from the parts afterward.

The mook isn’t particularly remarkable this time, unless you like Gundam. The first article is an interview with Kunio Okawara, mecha designer for the Gundam robots. This is followed by another piece on Theo Jansen, plus explanations of the Imperio’s linkage system and comparisons with the structure of the human leg. There’s an overview of other bipedal robots (including the Asimo of course), and then the suggested mods for the kit. Hobbyist articles include one on a group of people making a 2-wheeled rocket-launched robot, and 2 guys making their own scaled-version of a giant mecha. For the first article, the idea is to launch a rocket containing the robot and eject it near the goal site. Then, the robot rolls over to reach the goal on its own. A third hobby article describes a guy that makes small walking robots out of foamcore.

There’s a long section on the theory of how animals and people walk, additionally contrasting humans with penguins.The mook ends with another of Yoshitoo Asari’s Science Manga, this one entitled “What Shape is a Robot?” This time, our heroes are approached by a stranger wearing a hood, with just its glowing eyes visible. It’s a robot and has no body, so it asks them what the ideal shape should be for it. The kids take turns trying to argue for humanoid, cart-shaped, or factory-specialized arms. Examples of different applications are the Mars rovers and the Hayabusa explorer. Finally, they realize that there is no one good shape, that everything is determined by need, application and environment, and the stranger leaves, happily.

As with most Otona no Kagaku kits, the main point to buying it is to make the thing. There is limited replay value unless you modify it significantly. The mook is less visually interesting this time, and it really helps if you can read Japanese for the articles, or if you really like Gundam. Fortunately, it is somewhat cheaper than the other beests (2950 yen is roughly $36 USD without the import markup), but it is a smaller kit, measuring about 4″ x 4″ x 6″. Recommended if you are a fan of Jansen’s beests, or if you teach mechanical design.

Next up – Kit #38, the Radio Wave Flap Clock. No price given, tentatively scheduled for a Spring, 2013 release.

Updates for Gakken Kit #37


The Gakken Otona no Kagaku site has updated with the newest Theo Jansen mini-Beest kit – the Animaris Imperio. The main page has links to the official promo video, and the info page has the link to the assembly instructions (60 minute suggested assembly time).

One thing that surprises me is that the Otona no Kagaku site doesn’t yet have a link to volume 2 of the Science Live series. It’s been out for close to a week now, so there’s no reason not to have a dedicated page for it. But, whatever. I’ve seen the mook in the bookstore here in Kagoshima. It looks nice, but there’s more text than photos, so it’s not quite as visually impressive as vol. 1 is. It’s harder to find, though. Vol. 1 is in the science magazines section of the Junkudo shop, but vol. 2 is in with the physics textbooks. I might pick it up just to see if I can read the section on the Higgs Boson.

One nice thing as that the “Next Up” page has updated to show kit #38. It’s the radio wave flap clock. This one looks like it may be a challenge – it’s the old-style flip-card type of clock that has the time printed on little sheets of plastic that are advanced one sheet at a time. Apparently, it’ll be powered by radio transmissions. Tentatively scheduled for a Spring release. 84 page mook. No suggested retail price.

 

JASS Wiring Patch Example


Time to wrap things up for a while. This will be the last entry for the JASS synth, until I come up with an excuse to write about it again. I’m hoping that someone else will look at the code and decide to make it more “Java compliant”, and maybe point out ways of making improvements to the FFT section, or overall playback.  Enjoy. In the meantime, here’s the “patch” for my equivalent of an old Moog synth.

// This is a wiring patch for the JASS (Java ADSR Software Synth) app.
// It contains:
//     3 VCOs (voltage controlled oscillators)
//     2 Benders, for shifting frequencies of VCO 2 and 3, based on the VCO 1 frequency
//     1 Gate oscillator, for driving the circuit if the A-300 keyboard isn’t connected
//     2 Noise generator (configured to run during the ADSR attack, decay and release phases)
//     1 ADRS
//     3 mixers for allowing multiple connections to 1 input pin
//     2 Splitters, for allowing multiple connections from one output pin
//     1 VCF (voltage controlled filter)
//     1 Pan module
//     1 echo module for reverb
//     1 VCA (voltage controlled amplifier) as the main sound amp
//     1 arp (arperggiator) module for running note patterns
//
// https://threestepsoverjapan.wordpress.com/
//
///////////////////////////////////////////////////////////////////////////////////

// Create the new modules.

new osc osc1 (100, 0, 0.5, true, 0)
pin (50, 1000, 512, 256, Freq.,    freq)
pin (0,     4,   4,   0, Waveform, waveform)
pin (0.0, 1.0, 100,  49, Ratio,    ratio)
pin (0,    50,  50,   0, Glide Smoothness, smooth)
pin (0,    50,  50,   0, Glide Width,      width)
pin (0,     1,   1,   1, Enable Glide,     enableGlide)
pin (0,     1,   1,   1, Gate,             gate)

new osc osc2 (100, 0, 0.5, true, 0)
pin (50, 1000, 512, 256, Freq.,    freq)
pin (0,     4,   4,   0, Waveform, waveform)
pin (0.0, 1.0, 100,  49, Ratio,    ratio)
pin (0,    50,  50,   0, Glide Smoothness, smooth)
pin (0,    50,  50,   0, Glide Width,      width)
pin (0,     1,   1,   1, Enable Glide,     enableGlide)
pin (0,     1,   1,   1, Gate,             gate)

new Bender bender1 (1.0)
pin (-2.0,  2.0, 400, 199, Offset, offset)

new osc osc3 (100, 0, 0.5, true, 0)
pin (50, 1000, 512, 256, Freq.,    freq)
pin (0,     4,   4,   0, Waveform, waveform)
pin (0.0, 1.0, 100,  49, Ratio,    ratio)
pin (0,    50,  50,   0, Glide Smoothness, smooth)
pin (0,    50,  50,   0, Glide Width,      width)
pin (0,     1,   1,   1, Enable Glide,     enableGlide)
pin (0,     1,   1,   1, Gate,             gate)
new Bender bender2 (1.0)
pin (-2.0,  2.0, 400, 199, Offset, offset)

new osc gate1 (20, 1, 0.5, true, 2)
pin (0.1,  20, 100,   3, Freq.,    freq)
pin (0,     4,   4,   1, Waveform, waveform)
pin (0.0, 1.0, 100,  49, Ratio,    ratio)
pin (0,    50,  50,   0, Glide Smoothness, smooth)
pin (0,    50,  50,   0, Glide Width,      width)
pin (0,     1,   1,   0, Enable Glide,     enableGlide)
pin (0,     1,   1,   1, Gate,             gate)

new Splitter freqSplitter (2, 0)

new mixer adsrMixer (4, 1.0, 0)
pin (0.0,   3, 100,  60, Avg. Comp., comp)

new vca mainAmp (16000, 0.0)
pin (0, 16000, 512, 256, Amp., amp)
pin (-2.0, 2.0, 100, 49, Offset, offset)

new ADSR adsr1 (4000, 4000, 0.4, 4000)
pin (0, 8000, 512, 255, Attack,   attack)
pin (0,  600, 100,  10, Punch,    punch)
pin (0, 8000, 512, 255, Decay,    decay)
pin (0,  1.0, 400, 200, Sustain,  sustain)
pin (0, 8000, 512, 255, Attack2,  attack2)
pin (0,  1.0, 400, 200, Sustain2, sustain2)
pin (0, 8000, 512, 255, Release,  release)
pin (0,    1,   1,   0, Invert,   invert)
pin (0,    1,   1,   1, Gate,     gate)

new mixer gateMixer (2, 1.0, 2)

new VCF vcf1 (512, 0, 500, 0.5)
pin (0,   512, 512, 512, Cutoff,   filterLevel)
pin (0,    2,   2,   0, Mode,      mode)
pin (0,    7, 512, 256, Threshold, threshold)
pin (0,  1.0, 100,  50, Mult.,     mult)
pin (0,    1,   1,   1, Filter On, filterOn)

new Splitter echoSplitter (2, 0)

new mixer echoMixer (2, 1.0, 0)
pin (0.0,   3, 100,  60, Avg. Comp., comp)

new Echo echo1 (32000, 0.5, 0.75, 0, 1)
pin (100, 32000, 512, 255, Loop Length, loop)
pin (0.0,   1.0, 100,  49, Delay Max.,  delay)
pin (0.0,   1.0, 100,  49, Decay,       decay)
pin (0,       1,   1,   0, Mode,        mode)
pin (0,       1,   1,   1, echoOn,      echoOn)

new mixer noiseMixer (3, 0.0, 3)

new noise noise1 (0, 10, 0.4)
pin (0,   3,   3,  0, Mode,          mode)
pin (0, 100, 100, 10, Density,       density)
pin (1, 100,  99, 49, Brownian Max., brownian)
pin (0, 1.0, 100, 20, Volume,        amp)
pin (0,   1,   1,  1, Gate,          gate)

new Pan pan1 (true, 0.5, 1.0, 0.5)
pin (0.1, 10, 100, 10, Pan Rate,     rate)
pin (0,    4,   4,  0, Pan Waveform, waveform)
pin (0,  1.0, 100,  49, Magnitude,   mag)
pin (0,  1.0, 100,  49, Offset,      offset)
pin (0,    1,   1,   1, panOn,       panOn)

new Arp arp1 (1, 2.0, 0.5, true)
pin (0.1,   10, 100,  10, Arp Rate,     rate)
pin (0.01, 1.0, 100, 100, Arp Ratio,    ratio)
pin (   1,   5,   4,   0, Note Steps,    step)
pin (   0,   1,   1,   0, Note Gate,    noteGate)
pin (   0,   1,   1,   0, Master Gate,  masterGate)
pin (0,    4,   4 ,  0, Pattern,      pattern)
pin (0,    1,   1,   1, Enable,      gate)

// The next section sets up the patch.
// Specify wiring to the fixed pins.

connect kbd.note osc1.freq
connect kbd.gate gateMixer.1
connect kbd.pitch osc1.pitchBend
connect kbd.touch osc1.touchIn
connect arp1.out kbd.arp

// Specify wiring between modules.

connect gate1.gateOut gateMixer.2
connect gateMixer.out adsr1.gate
connect osc1.out adsrMixer.1
connect osc1.getFreq freqSplitter.in
connect freqSplitter.1 bender1.freqIn
connect bender1.out osc2.freq
connect osc2.out adsrMixer.2
connect freqSplitter.2 bender2.freqIn
connect bender2.out osc3.freq
connect osc3.out adsrMixer.3
connect adsrMixer.out adsr1.in
connect adsr1.attackE noiseMixer.1
connect adsr1.decayE noiseMixer.2
connect adsr1.releaseE noiseMixer.3
connect noiseMixer.out noise1.gate
connect noise1.out adsrMixer.4
connect adsr1.out echoSplitter.in
connect echoSplitter.1 echoMixer.1
connect echoSplitter.2 echo1.in
connect echo1.out echoMixer.2
connect echoMixer.out mainAmp.in
connect mainAmp.out box.fixed

// Specify wiring from the sliders and dials to the module input pins.

connect Control.0 mainAmp.amp
connect Control.1 osc1.waveform
connect Control.2 bender1.offset
connect Control.3 bender2.offset
connect Control.4 adsr1.attack
connect Control.5 adsr1.decay
connect Control.6 adsr1.sustain
connect Control.7 adsr1.release
connect Control.8 echo1.loop
connect Control.9 echo1.delay
connect Control.10 echo1.decay
connect Control.11 osc1.smooth
connect Control.12 osc1.width
connect Control.13 osc2.waveform
connect Control.14 osc3.waveform
connect Control.15 noise1.density
connect Control.16 noise1.amp
connect Control.17 pan1.rate
connect Control.18 pan1.mag
connect Control.26 echo1.toggle
connect Control.27 vcf1.toggle
connect Control.28 noise1.toggle
connect Control.29 pan1.toggle

// Specify the module “pin” settings. This is part of the actual patch.
// Format: setting moduleName pinName sliderValue rawData

setting osc1 freq 51 144.63
setting osc1 waveform 0 0
setting osc1 ratio 54 0.54
setting osc1 smooth 10 10
setting osc1 width 10 10
setting osc1 enableGlide 1 1
setting osc1 gate 1 1
setting osc2 freq 198 417.38
setting osc2 waveform 0 0
setting osc2 ratio 49 0.49
setting osc2 smooth 10 10
setting osc2 width 10 10
setting osc2 enableGlide 1 1
setting osc2 gate 1 1
setting bender1 offset 141 -0.59
setting osc3 freq 256 525
setting osc3 waveform 0 0
setting osc3 ratio 9 0.09
setting osc3 smooth 10 10
setting osc3 width 10 10
setting osc3 enableGlide 1 1
setting osc3 gate 1 1
setting bender2 offset 170 -0.3
setting gate1 freq 0 0.1
setting gate1 waveform 1 1
setting gate1 ratio 95 0.95
setting gate1 smooth 0 0
setting gate1 width 0 0
setting gate1 enableGlide 0 0
setting gate1 gate 1 1
setting adsrMixer comp 60 1.8
setting mainAmp amp 419 13093.75
setting mainAmp offset 49 -0.04
setting adsr1 attack 113 1765.62
setting adsr1 punch 10 60
setting adsr1 decay 124 1937.5
setting adsr1 sustain 309 0.77
setting adsr1 attack2 0 0
setting adsr1 sustain2 0 0
setting adsr1 release 323 5046.88
setting adsr1 invert 0 0
setting adsr1 gate 1 1
setting vcf1 filterLevel 512 512
setting vcf1 mode 0 0
setting vcf1 threshold 287 3.92
setting vcf1 mult 39 0.39
setting vcf1 filterOn 1 1
setting echoMixer comp 54 1.62
setting echo1 loop 92 5832.03
setting echo1 delay 30 0.3
setting echo1 decay 11 0.11
setting echo1 mode 0 0
setting echo1 echoOn 0 0
setting noise1 mode 0 0
setting noise1 density 19 19
setting noise1 brownian 65 66
setting noise1 amp 4 0.04
setting noise1 gate 1 1
setting pan1 rate 12 1.29
setting pan1 waveform 0 0
setting pan1 mag 86 0.86
setting pan1 offset 7 0.07
setting pan1 panOn 0 0
setting arp1 rate 20 2.08
setting arp1 ratio 49 0.5
setting arp1 step 1 2
setting arp1 noteGate 0 0
setting arp1 masterGate 1 1
setting arp1 pattern 1 1
setting arp1 gate 1 1

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.

Java Synthesizer, Part 22, Arping


Just some observations regarding arpeggiating. On its surface, the idea of arpeggiating a note, or series of notes, is very straightforward. Essentially, it’s like automating someone standing at a keyboard and pressing keys (i.e. – like a sequencer). But, as I dig deeper through it, and spend more time implementing the ideas arising from the arp module, the more complex things become.

The simplest form is just one key turning on and off. Stand in front of the keyboard. Press one key. Let go. Press it again for the same amount of time. Let go for the same amount of time. Repeat. This is a gate arpeggiator. One approach is to take an LFO (low frequency oscillator) running a squarewave and connect it to the gate-in pin of the envelope generator (ADSR) or gate-in for an audio oscillator. The note out will depend on which key you press, and the rate and duty cycle (ratio of time on to total cycle time) will be based on the LFO rate and ratio settings.

(Imagine there’s a VCA between osc2 and osc1.)

The next type of arpeggiator switches between two notes to create a trill effect (usually two notes close together and switching between 10 to 50 times a second). An approach for this circuit is to connect the LFO outputting a squarewave to the input of a VCA (voltage-controlled amplifier). Because the LFO output only goes between -1.0 and +1.0, we need the VCA to create a signal that oscillates between our two desired frequency numbers. Set the VCA offset to 2.0, and amplitude to 100, to get a value of 100 ((-1.0 + 2.0) * 100) and 300 ((+1.0 + 2.0) * 100). Connect the output of the VCA to the setFreq pin of an audio oscillator and you get your trill between 100hz and 300hz. Rate and duty cycle still depend on the LFO frequency and ratio, while the upper and lower notes are a function of the VCA amplitude and offset settings.

Things get a little more tricky when dealing with patterns. Stand at the keyboard and press four adjacent keys in a rising sequence, and then loop them. This would be a “0 1 2 3” pattern. Start with a different key and do the same loop and it’s still “0 1 2 3”. Play the adjacent keys in a falling sequence for a “0 -1 -2 -3” pattern, etc. The easiest approach is to take a dedicated arp module and connect it to the keyboard hardware, adding the arp pattern value to the keyboard NoteOn number. So, if you press MIDI note number 50, the rising pattern would give you “50 51 52 53” in a loop, while the actual frequencies played by the audio oscillator would come from an array of piano frequencies (for example). However, there are now at least three more operating modes available from an arp module.

Mode 1: Switch between notes with no break between them. This would be like pressing one key of a monophonic (one note at a time) keyboard, then pressing the next without letting go of the first. Press the third without releasing the second, etc. As far as the envelope generator (ADSR) is concerned there was only one keypress, which started the attack phase, and no unpress, so no start of the ADSR release phase, until you actually let go of the last key.

Mode 2: Switch between notes with breaks. Press one key, let go. Press the next key in the pattern and let go. Etc. The envelope generator would trigger with each key, applying the attack, decay, sustain and release phases to each note. This is probably what most people think of when talking about arpeggiating. You press the key once, and as you hold it, the arpeggiator walks through the pattern, applying the envelope to each new note out.

Mode 3: Kind of like a cross between 1 and 2. There’s a break between notes, but the ADSR isn’t triggered each time. That is, the envelope starts when you press the key, and ends only when you let go. The notes sequence through the pattern as raw oscillator output as long as you hold the key down, with the dead space between notes based on the arp on/off ratio setting.

The rates of modes 1-3, and duty cycles of modes 2 and 3, are determined by an internal LFO within the arp module. Selection of the pattern to play is done through the arp module itself. The frequencies out are a combination of the keyboard key being pressed, and the step values specified in the pattern (i.e. – 0, 1, 2, 3 or 0, -4, 2, 6).

Why go into all this detail?

Each synth circuit provides slightly different audio experiences, and can be used in combination with the others.

A gate oscillator driving the ADSR provides a solid, stable pulse regardless of the waveforms being applied to the ADSR input.

An LFO driving another oscillator lets you select any two frequencies that you want. Contrast this with the arp module in mode 1 running a “0 1” pattern, which only lets you pick the fixed frequencies used by a piano keyboard.

Youtube Video

Arp module mode 1 makes for a nice, smooth trill, while mode 3 is very harsh and abrupt. Mode 2 is unlike any of the other setups because it treats each note in the pattern as a separate keypress for gating the ADSR (but similar to the gate oscillator if you’re just running a “0 0” pattern).

Combining circuits would let you have a trill effect and a “0 2 4 -6” pattern running to the input of the ADSR, which is being gated by a completely separate LFO.  Mind you, all this arpeggiation  is possible with just some oscillators, the VCA, the arp module and the ADSR. Throw in everything else, including the bender, the oneShot, filtering, pan, echo, mixers and splitters in any combination you like, and you can really start having fun.

Maker Faire in Japan Times


As mentioned in my translation of the Gakken Otona no Kagaku e-mail newsletter, #153, Make magazine Japan held its Maker Faire on the weekend of Dec. 2nd in Odaiba. The Japan Times newspaper ran a review of the event.

 

Java Synthesizer, Part 21, Tidbits


Ok, now I’m just in final clean-up and last tweaks.

VCF – I wanted to see how far I could take the FFT filter before encountering performance issues. I’d started out with a 1K FFT array, and had hardcoded some of the buffer sizes in the vcf method, so the first step was to clean up the code and use variables everywhere. When that was done, it was a just matter of changing one constant (array size) and running a simple synth circuit (an oscillator with gated ADSR and vcf) to test it. Going to 4K immediately resulted in break up of the sound. Dropping down to 2K allowed for a clean sound, but there’s little real difference in the filtering effects between 1K and 2K.

At the end, I wanted to see what happens when I increase sampling rate from 16,000. I’d already softcoded the methods tied to sampling rate, so all I had to do was change the rate to 44,200 in one location. However, the impact on the simple oscillator circuit was really severe, with breakups in the sound playback. The code looked fine (meaning I hadn’t introduced a bug somewhere) and on a hunch I turned off the VCF module. The playback returned to normal, so I dropped the VCF array size back to 1K and the dropouts disappeared. Turns out that changing sampling rate makes a much bigger difference to the quality of FFT filtering than changing the FFT array size does. A lot of the hiss caused by rapid changes in volume and frequency has also disappeared with the higher sampling rate. I’ve decided to keep sampling rate at 44,200 and the FFT array size at 1K.

The next step was to try adding base boost. Normally, it’s a simple case of writing a value to a desired frequency bin and then running the inverse FFT on the frequency data. However, because of the minimal number of frequency bins and the fact that a lot of energy is spread out over several bins with the circuit I was using, the output sound was noisy and the base note got lost easily. So, I decided to instead just use a separate oscillator running at 50 hz, and that sounded pretty good. So, if I want more base along with the regular waveform, I’ll start with a second osc module first.

Which brings me back to the bender module. I started thinking about how to have two notes, where the second was a fixed fraction of the first. That is, if I played a 200 hz note, I’d also get something at 100 hz or 50 hz (anything less than 50 hz would either be inaudible or produce clicking from my laptop speakers). I could try making a new module that acts as a pure multiplier or divider, or I could just use a bender and hand-type 0.5, 0.25 or 0.125 into the offset text field. Or, I could set the bender offset range to go from 0.1 to 1.0 in 9 steps and set the osc2 frequency that way. The more I think about it, the harder it is to make a decision. I’d say that it really depends on the final sound I’m trying to create, but the base note probably won’t be user adjustable during play time, so a bender with a fixed offset feeding into osc2.setFreq() will be good enough right now.

pitchwheel: The code was already mostly in place for implementing the pitch wheel with the new circuit design. I just needed to add the “pitch” keyword to the command parser and the menuing system. However, I’d initially just adjusted pitch as part of the sine waveform generator, meaning that as the pitchwheel was moved I was getting loud clicking, and it didn’t work with the other waveforms, like the square and triangle waves. So I modified the oscillator setFreq() method to include pitch and channel pressure as part of the check for a change in incoming frequency. The advantages of this change are that both the pitch wheel and channel pressure (or aftertouch) work with all of the available waveforms, there’s very little clicking, and I can smooth the transitioning sound even further by tweaking the glide settings.

As a reminder, channel pressure is a MIDI option that allows the user to vary the current note out by pushing harder or softer on the key without releasing it. Channel pressure is an average of all keys pressed at one time, while after touch is per-key. It’s a question of what the manufacturer of your model of keyboard decided to implement. I’m using the Roland A-300 Pro, which has channel pressure. I hadn’t included it in the code of the A-300 class, so I had to go back and copy-paste the required lines from my K-Gater app, then track down the bugs I inadvertently added at the same time. Then, I more-or-less duplicated the existing code for the pitchwheel, and just changed the names for the new channel pressure function. I also aded a “touch multiplier” to mirror the pitch multiplier, to allow for varying the sensitivity of the keyboard key. However, even a multiplier of x1 produces a big frequency shift in the waveform output, so dropping down to x0.5 might be desireable in some cases.  On the other hand, both pitch mult and touch mult are hardcoded values, and are not user-changable right now. I’m going to leave them this way until it becomes more obvious that they should be user-accessable (would only take a few minutes to implement).

I am getting to the end of my “wish list” for new modules. Given that I put so much effort into K-Gater for user-selectable arpeggiator patterns, it seemed only reasonable to at least have some sort of similar functionality here. Back in the blog entry on oscillators, I gave several examples of how to use one oscillator to drive a second to get a trill effect, or to gate the first one on and off. Those were simple cases of arpeggiating. But, if you want more control over several sets of notes, especially if you’re ‘pegging the keyboard, then there has to be something more powerful to work with. That’s why I created the arp module. I could load the arp patterns from a file, but at the moment that’s overkill, and I can easily add more patterns to the ArrayList within Java whenever I run this app through Netbeans. Alternatively, I could add an “arp” command, and load the patterns dynamically via the command parser (which I may do, making the arp patterns part of the overall patch). In any case, the arp module allows the user to select one of the pre-coded patterns, set the play rate, and toggle the enable state. Output from the module is then an integer taken from the pattern based on rate, that is applied to a new “kbd.arp” input pin that I also created specifically for this case. The arp pattern value offsets the keyboard key currently being pressed, resulting in a different value being selected from the piano key frequencies array.

The last major, and definitely the most satisfying tweak, is note tracking. For simplicity’s sake, I’d written the keyboard noteOn() and noteOff() methods to only treat the most recent keypress as the master key. That is, if the user pressed note 1, the synth would set keyboard.gate to true and the on note as whatever key had been selected. Then, if the user pressed a second key, gate would be set to true again and noteOn would go to the new note number. When the user released either of the two keys, gate would get set to false and the sound would stop playing. Not ideal, but good enough during the testing phase. But, now that I want to play with glide, I really needed to go back and rewrite note handling to be smarter. To do this, I just made a keysList Array List for the keyboard class, and add each new note to keysList when noteOn() is called. When a key is released, noteOff() is called and I go through the array list to remove the specified entry. If the specified note is the last one pressed, I change the note played to the last item in the existing list. If the only remaining key is released, I set keysList to new ArrayList to avoid Java’s stupid null reference exception, and set gate to false. Now, I can easily play with glide between several notes at a time and the resulting effect is pretty cool.

One of the complications of going from hardcoding the synth circuit to making it user-definable, that I hadn’t discussed before, was that echo didn’t work right anymore. The original approach was to feed the input of the echo module with the output of the ADSR, and then loop the echo output to the input of the ADSR, which resulted in a desireable feedback loop and the echo output being reshaped by the envelope generator each time.

But, in the user-definable system, the echo died the second the user let go of the key and the ADSR release phase completed. That is, regardless of how long the echo decay was set for (2 seconds or more), if release ended (assume a quarter-second release setting for the ADSR) then the echo got cut short, too. While this is the correct behavior for a gated ADSR, it kind of defeats the point of having reverb in the circuit. Instead, my user-definable synth circuits now treat echo as a delay buffer between the ADSR output and the VCA amplifier input.

I lose the feedback loop into the ADSR, and the accompanying envelope shaping, but I gain extended reverb.  But, this is a trivial case, it’s just a question of how you want to wire the echo module into the circuit when using the connect commands.
I’m now at the point where I’m thinking more of circuit wiring than I am of new Java code. I’m kind of torn between making a set of pre-wired synths and loading them one at a time based on the sounds I want, or making one big master circuit with preset ranges and then specifying the inter-module wiring as if I had an actual hardware box. On the one hand, having specialized circuits would decrease patch load times. On the other, I have to consider my per-pin, per-module ranges code for each new circuit. With one big master circuit, the ranges would be coded once and I could focus more on which pins I want wired together.

Java Synthesizer, Part 20 – File Handling


Finally, I can save and load patch settings.

Actually, it took a bit of code to get to this point, too. Things really were speeded up with the introduction of the command line parser, since all I really needed to do was add code to call the parser from the top menu bar. And that’s where things got more messy (and/or fun, depending on your definition of “fun”).

I started out by simply adding a new menu item for listing command line instructions, modules, pin wiring, etc. – all the “list” commands already in the parser.

From here, it was a relatively simple step to add a second new menu item for creating new modules. I decided that it’d be easier all around to just hard code the constructor and range settings, then let the user tweak everything using the sliders within the GUI.

The third new menu item was “connections”, which allows for making and breaking the wiring between modules. So, in fact, the menu bar now has the same functionality for creating new synth circuits as the command line does, the only difference being that the menus use pre-coded range values, and the command line allows the user to specify everything themselves.

One bug that I ran into, that I’m not going to try to fix, is that the “pin” command needs to specify the pin ranges in the same order, and for each and every pin, as given in the inpins[] arrays for each module. It’s not really a *bug* per se, but more of my being lazy. Plus, you need to specify the range for each of the pins you want to vary from the GUI screens. I did put in a check for whether a control that you’re trying to wire has been specified with the “pin” command, but it’s easy to overlook if you’re hand entering commands through the command line.

Loading a circuit from an existing file is trivial. I just read the file one text line at a time and send it to the command line parser. This does create a long pause from when I click “ok” to when Java starts printing out parsing results in the jTextArea1 window, especially if it’s a big circuit. I think this is a limitation in Java itself, wanting to finish printing everything to the text area before displaying it to the user.  (Copying the patch from a textfile into jTextArea1 and using the grab command is several times faster than loading the same patch directly from a file.)

Saving the patch file is equally simple. First, I just write the contents of the instructions[] array, which contains the wiring commands entered by the user. Then I go through the ranges ArrayLists for each module and write a new “setting” line. I added “setting” to the command parser at the last minute. This takes the slider settings, and text field values for each module and pin, as previously changed by the user, and puts them in the ranges ArrayLists for each module. When the user saves the patch to file, the save method appends the “settings” statements to the end of the wiring commands. Then, when the file is loaded again later, the parser sees the “settings” statements and restores the user’s last synth patch settings.  This is really the key to making my program usable, because now I not only have user-configurable circuit wiring, but I can save and load the last slider settings (i.e. – what everyone calls the actual “patch”) as well. To avoid having multiple copies of the settings commands show up in the patch file with each “file save”, I strip them out of the instructions ArrayList during file save, and then save only the current range values each time.

While creating and saving various simple circuits for testing the command line parser, I made one that I called “simple osc and gated ADSR with echo and noise”. I decided to use it at random for testing the file load and save function, and suddenly the playback sound seemed strange to me. It was very hissy and had a bell-like component in the echo loop. Thinking that I’d screwed up the echo class when I tweaked it to make it compatible with the range setting function, I started digging into the in() and out() methods, then realized that I had indeed written the echo loop portion wrong. I was varying the loop buffer length, but not the time between the bufferReadPtr and bufferWritePtr for allowing the time from write to read to change.  So I ripped out the old code and put in what I’d originally planned for that class (varying loopLength, then having a variable going from 0.0 to 1.0 to set bufferReadPtr as a ratio of loopLength, lagging behind bufferWritePtr). Unfortunately, this didn’t fix the noise-bell issue, and I lost several hours until realizing that it was a natural side-effect of that particular circuit. Switching to “simple osc. with gated ADSR and echo” (and no noise) produced the kind of echo I wanted. But, the new echo loop code produces hiss when I change settings with the sliders. So, I figured “what the heck” and added a mode setting for selecting between the old version of the echo loop and the new one.

Not too much more to say about the synth from the Java side.  I still need to re-implement the pitch wheel, and I’m getting occasional “timer concurrent operations” errors when I load the patch via the parser (seems to be something with the timer class, but it doesn’t hurt anything so I’ll live with it until I figure out what the cause is). I also need to do more testing to verify that everything else works right. Plus, there is one extra feature I need to add at some point – allowing two or more keys to be pressed at the same time (I’ll retain the monophony restriction, I just don’t like having the keyboard turn off when the first key is released and the second is still pressed).  After that, I’ll make a youtube video for a quick demonstration of the app. It is still hissy, which bugs me, but that may be caused by either Java itself, the sound card hardware or the card drivers. At the moment, I have no idea how to remove the last of the hiss when changing slider settings, but at least the clicking isn’t as bad as when I first started out a month ago.

Raw formatted script file here (same as last blog entry).

 

50 Famous People – Jean-Henri Fabre


(All rights belong to their owners. Images used here for review purposes only.)

Growing up in Minnesota, I wasn’t exposed to a wide variety of insects. We had a couple kinds of butterflies, some grasshoppers and dragonflies, and that was about it. (We didn’t have much in the way of birds, either.) Since I lived in the city, I didn’t have many opportunities for bird watching or insect collecting. The local library had a few books on North American birds, but I don’t remember seeing anything on insects. So, I had no idea who the subject of this mook was.

Jean-Henri Fabre was a primarily-self-taught French entomologist, living from 1823 to 1915. His father attempted to run restaurants in several cities in France, and failed with all of them. Fabre grew up with relatives in the countryside, where he developed an interest in plants and animals from an early age. He attended school for a while but started working from around age 14 to help raise money for the family, selling lemons or working construction sites. He attended school in order to gain a teaching certificate, and then taught physics and chemistry at several schools while attempting to conduct his own studies on the side. He discovered the works of Leon Dufour and decided to focus on insect studies. Eventually, he quit teaching to concentrate on work in his own lab, and wrote 10 volumes based on his observations. He’s very well-known in Japan, in part because of his humorous writing style (which was unlike the tedious pedantry common at the time).

The intro manga has Merrino trying to come up with a new insect-based machine to play with, and Daichi pulls out a stack of books from under his shirt. He gets into a dispute with Utako, who thinks insects are creepy, while Daichi himself feels that bug collecting is a “real man’s game”. Studybell appears in an attempt to cure Utako of her phobia. At the end of the lesson, she still dislikes bugs, but not quite as much as before. Merrino announces that he’s found a bug not detailed in Daichi’s books, so he’s chosen it for the basis of his new machine – a giant cockroach.

The artist for the main manga this time is Yayoi Furudori, creator of Fuku Fuku and Library Wars – Spitfire. There’s a decided shojo feel for the character designs, but the backgrounds and detail work on the insects are very good. Overall, the “westernization”  of the characters isn’t as distracting as normal. The story picks up with Fabre, age 32, bringing home a beetle that was just stung by a wasp. He shows it to his wife and demonstrates that it’s not actually dead, just paralyzed. The insects are similar to the ones Dufour wrote about in his research papers, but there’s a puzzle that hasn’t been answered yet. Mainly, how did the wasp deliver the venom to the beetle through its hard upper shell? There’s no puncture wound. After long study, Fabre tried stealing a beetle from one of the wasps, substituting it for one that he’d brought with him. Thinking that it had failed to subdue the beetle the first time, the wasp struck again, and Fabre could see that the stinger was curled under the beetle where it could reach the more vulnerable abdomen area. Fabre writes up his findings, which eventually make their way to Dufour. He writes a letter to Fabre, but rather than being angry at having been proven wrong, he commends the younger man for his work and encourages him to keep doing insect research.

Time passes, and Fabre is still poor. Teaching doesn’t pay well and he doesn’t like the work. He and his family move to different schools in different cities, but his heart’s not in it. One day, as he’s trying to write the first volume of his collection, he decides to ask his second oldest son, Jules, to help him with his research. Of all the children he’s had, only Jules and one of his daughters shares his interest in insects. One of the other daughters has finished making dinner and she calls to Jules and her father to come eat, but they’re engrossed in looking at a caterpillar and ignore her. But, before volume 1 can be finished, Jules falls ill and dies at age 16. Fabre himself collapses from grief and sees a vision of the boy eagerly waiting to read his father’s books. When he recovers, Fabre completes book 1, then tries to get a publisher for it. (A sidebar mentions that Fabre discovered a new insect while researching the first volume, and named it after Jules.) He moves the family to a new home a few miles away, in a section of undeveloped land that his christens “Arumus” (Japanese spelling, means “wilderness”). He then welcomes the insects there into his household. He stays there until his death at age 91, completing all 10 volumes on insects, as well as observations on other plants and animals. (Note that I can’t find information on Fabre’s children, such as names and how many he had. The Japanese pronunciation of Jules is “Jule”, so I’m guessing at how it’s spelled.)

The textbook section describes pretty much the same information given above, but with more detail on his father’s financial failings, and listings of the schools he taught at. Pictures include shots of Fabre, his wife and older son (Paul, who became an insect photographer), pictures of his insect collections and his lab. There’s also some excerpts of his observations (the Aesop story of the ant and grasshopper got it wrong. Outside of the original story being about an ant and cicada, the cicada is the one that does all the work in pulling sap from trees, and the ants steal it away. So, the cicada is the forthright worker, and the ants are just lazy thieves.) The last two pages have illustrations by Chikaba Kumada (1911-2009), an illustrator known as “the petit Fabre”, due to the detailed work he did on insects and plants for textbooks.

The TCG cards are for Ernest Seton, Yuan Shikai, Arthur Conan Doyle, Sven Hedin, Henry Ford, Pierre de Coubertin, Sun Yat-sen, Ramsay MacDonald and Anne Sullivan.

If you want to know what western textbooks don’t teach you about insect history, this mook is for you. (Side note: Asahi Shimbun has included an ad on the back page of this mook announcing that the second series of illustrated famous people will start up at the end of January, 2013. It will feature 30 more names, such as Hans Andersen, Caesar, Newton and Tolstoy.)