Category: Code

ST4 September update, DIY kits

Just to keep you informed, another ST4 progress update. In the last weeks we’ve tested the sample casing and we’ve requested another one. Two PCB’s didn’t fit correctly, the other 7 did just fine. This will take until early October.

In the meantime all the presets have been added, the DIY manual has been updated with better tables, and we’re ironing out all the firmware bugs. ..And.. we’re finally compiling all the DIY kits. Still, that’s not too much work. The casing is the only real work that’s left. We strive for November, but the planning is now in the hands of the casing factory.. At least you’ll be getting your gear when you spend most of your time indoors. It makes sense ūüėČ

The current collection of kit bags (half of it, actually).

The current collection of kit bags (half of it, actually).

In the meantime we did a minor Sawbench hardware revision (to protect against wrong AC/DC converters) and we’re looking forward to test the 1.2 firmware with its improved VCA/VCF envelopes and improved MIDI support.

Kit bag, with spiffy new label. ;)

Kit bag, with spiffy new label. ūüėČ

When the final casings arrive we’ll start shipping out the kits ASAP! This is done in first-come-first-served order:

1. Kickstarter DIY backers first to last
2. Kickstarter assembled version backers first to last
3. Pre-order list DIY first to last
4. Pre-order list assembled version backers first to last

Today we’ll send out a questionnaire to ask you guys which version you want: rackmount or desktop.. and to ask you for your postal address.

ST4 – Electronics production done

All electronics for the ST4 kickstarter have been completed!

All electronics for the ST4 Kickstarter have been completed!

Take a good look. Yes, all those PCB’s have been assembled. And over half of them in-house. That means we just have to hook it all up and test it.

On other fronts: the firmware¬†has progressed nicely. Apple USB keyboards are now supported, German keyboard layout is supported, and it looks like UK is up next. If you have a kayboard layout¬†you want to see supported, you can send it to us and we’ll code it!

USB hubs are (somewhat) supported, which opens doors to new¬†avenues like USB MIDI controllers. The tracker now features half and double speed options. The display has the feature to show multiple controls (up to 4) at the same time, and controls have set points. Huge amounts of features to control the¬†signal path¬†have been added: LFO sync, LFO cross modulation, frequency controllable LFO random noise, channels may be bundled¬†in one big group (for instance, set cutoff for all channels with a single pot). Poly and mono (non-)legato modes are available. There’s now a PWM mode and LFO¬†modulation can control¬†it. That’s not all, LFO can also control¬†bit crusher parameters!

We’re currently negotiating the casing with a number of factories. This is a lot time consuming as previously thought. The ST4 casing is multi-functional (desktop and 19″ rackmount), has a display and this involves a lot of details and choices to be made. When we’ve invested months and months in electronics and software, we’d like to do the same for the casing.¬†We’ll see which ones comes out best. The cardboard box design now also has been done. The DIY manual is 95% finished and the user’s manual is about 70% complete.

In the meantime we’ll continue making the firmware better and better. Most features will be¬†made available through the two onboard rotary encoders, not only through the USB keyboard. The goal is to have everything except sequencing and typing in names possible with on-board controls.

In short, it’s primarily casing stuff and firmware polishing from here on. Late august does seem somewhat feasible.

ST4 Production

In recent weeks the ST4 electronics production has kicked off. Many of the simpler boards have now been produced and are ready to be built into the ST4 units. These were handmade right here at Tasty Chips labs in The Netherlands, just like the Sawbench synth was.

A stash of assembled ST4 VV boards.

A stash of assembled ST4 VV boards.

The more complex boards (exp, vcf, vca) are being assembled by machine in a fab nearby and should be done by the end of the month. Concerning the manual labor, we still have to do the voice and the mod boards. The DIY manual has also seen some major progress and many of the board pages are supplied with photos of all the soldering steps: ST4 DIY resource. More and more detailed information will appear on this DIY resource in the coming weeks.

In parallel, the firmware is still being worked on. Some news:
– Poly mode now works fine and is intelligent enough to allow 3 finger chords + solo.
– The ST4 tracker can now send MIDI out clock signals.
– The ST4 tracker accepts MIDI clock input (preliminary).
– Samples can now be tuned.
– Sample looping can be turned on or off individually per instrument.

The casing (graphic) design is ongoing. We’ve got an excellent graphics artist on board to help us with the silkscreens. The details of the fabrication are being negotiated at the moment.

Last but not least. We’ve had multiple requests whether the ST4 will become available to the public after Kickstarter. The answer is YES! Also, we are taking pre-orders. These are completely free of charge and the interested party is not obliged to buy in any way. Just send your name, postal address, and the version you want (kit, or built unit) to Price for built unit will be 850 eur, 550 for the kit. Units are shipped out on a first-come-first-served basis.

Arduino DUE Makefiles

The Arduino IDE is good for starters as it hides some of the complexity of C++ development: notably the linker and project management. It is intended for beginners so they can have a LED blinking in 2 seconds. And you can extend it using libraries based on C++ classes, which is great.

Correction, this SEEMS great and it would be if it were implemented right. Of course, the editor is somewhat limited compared to matured platforms such as Sublime text, or the typical IDE editor.. However, that’s not the real problem here. It’s good that it’s simpler than those powerhouses, otherwise beginners would run away. The real problem lies with the project management.

Normally, you’d have a project setup which defines dependencies between classes. Mostly, the user sets this up manually or semi-automatically (for instance using CMake or GNU Autotools). The major advantage of this is that no unnecessary code is ever compiled or
linked.. and when changing only 1 file, only that file is recompiled and linked.

What Arduino IDE does wrong for the DUE (and I’m talking about the recent version 1.5.6):

  • It recompiles everything. Even the core libraries.
  • It cannot reliably tell which libraries to include or not.
  • Verification of upload is always done, even when you explicitly set a flag not to. This takes ages.

Especially the second point is deadly. It causes error messages about missing #include statements, while these shouldn’t have to be there at all. Not only this but an unnecessary library can be linked, causing the maximum code size to be exceeded!

The other points are primarily annoyances of ours. But compilation and upload speed IS important. Uploading big programs to the due can take 30 seconds or so. And verification doubles that. But verification is only required when you’re performing diagnostics. Forced recompilation of core libraries adds another 10 seconds. Better make some tea.

But back to the deadly second point. Assume we have the following piece of sketch code:

#if 0
#include "Foo.h"
#include "Bar.h"

void setup()

Foo and Bar are our libraries and we disabled their inclusion by using preprocessor directive #if 0. Much to our bemusement, this didn’t do anything. The libraries were still linked and the upload was still as big as before. The first thing to do in Twilight Zone episodes like this is to wipe your glasses. Correct your monitor angle and try again.. But no.. Nothing was wrong with our code.

What then, was the problem? What happened under water in the depths of the IDE was that our sketch got scanned for library includes. But the scanning was implemented in such an improper way you’d actually be surprised that it works at all. It’s just a “grep”.. A line by line search for the #include directive. It doesn’t take into account the context at all. Instead it should do parse the C++ code, but it doesn’t. We don’t know why. But we also shouldn’t care. After witnessing this it was clear that the IDE just wasn’t designed with bigger programs in mind.

Finding a bug in a big program can be a very time consuming task, and this could make things a lot worse, especially when maximum program size is exceeded for no reason. Added to this is that fact that the IDE also seems to think #include’s are missing, like mentioned before, was really the limit. Let’s just do it properly, shall we?

Our solution is just a typical makefile. Makefiles are ancient, their syntax a bit cryptic, but they always get the job done and they never change. Learn once, and use the rest of your life.

The start was to check the IDE’s compiler output:
Arduino -> Preferences -> Show verbose output during compilation

This produces a huge mountain of GCC and GPP command lines. We’ll spare you the actual raw text here and analyze it for you. What is there to do when building a DUE sketch:

  • Build the Arduino core library. This features implementations of the well known digitalWrite(), analogWrite(), and everything else an Arduino sketch uses. Eventually we intend to completely replace this with our own code (as it’s a million times more efficient). But for now it has to stay. The process is hard to generalize. Every piece of source can be in a different subdirectory so we ended up with 100 lines of Makefile code.
    Sources get compiled to object files (.o) and these get archives into core.a.
  • Then there’s the non-core libraries. For instance, SPI.cpp. Compilation proceeds similar to parts of the core.a lib but are not archived. Your own libs should be compiled in a similar fashion. Note: For some reason syscalls_sam3.c should also be present as a separate object and not (only) be present in the core.a.
  • The ELF should now be built from the sketch source and all the objects and the core.a should be linked.
  • The ELF should be dumped to a .bin using objcopy. This is used with “-O binary” mode, meaning it strips all symbols and relocation info.
  • Finally the .bin should be uploaded using bossac. This is what we came up with:

    # erase the DUE!.. done by opening comms @ 1200 bps
    stty -f /dev/cu.usbmodemfd121 raw speed 1200
    # actually upload the binary
    bossac -p cu.usbmodemfd121 -e -w -b test_ili9340.bin
  • Serial output can be monitored with a combination of screen and cu:

    sudo cu -l /dev/cu.usbmodemfd121 -s 115200

    ..And just kill the screen Using ctrl-a k when we’re done.

As you can see it’s not that crazy. Of course, loads of definitions of include paths, GNU tool locations and compiler and linker flags are necessary. For your convenience I’ve put them in a ready-to-go Makefile attached to this post (it’s a display driver test):



Scroll to top