- Caught up with all pending accounting/payments issues.
- Re-opened the online shop and handled the tsunami of orders.
- Ordered packagings for new module 2 (they won’t come in white boxes).
- Started the hunt for new packaging suppliers, and for new toys!
- Went hunting for new papers/printers – as the “Laguna” paper used for all the module manuals so far is no longer available.
- Implemented new module 1′s soundhack-ish easter egg.
- Improved the quality of some DSP algorithms used in new module 1, benchmarked code speed.
- Implemented a signal analysis tool (based on ESPRIT) to get some insight from audio samples and tune some parameters of new module 2.
- Solved a bug in Ambika’s handling of the sustain pedal when cyclic voice allocation is used.
- Received the last 30 Peaks and 10 Frames. QA’ed & shipped.
- Ordered panels for new module 1 and 2 (250 each).
- Implemented the routines for saving/restoring new module 1′s state and programmable data (fun fact: module 2 is modeless).
- Received 100x CVpal alu panels. Bagged them all, available on the shop!
- Rewrote some horrid boundary checking/buffer arithmetic code in new module 1 into something I (hopefully) will still be able to understand in a few months.
- Rewrote new module 4′s factory testing tool to give more usable visual feedback of measurements (switched from pyGTK + matplotlib to SDL, FPS went from 4 to 60). Configured testing machines.
- While reviewing the factory testing procedure, found a hardware bug in new module 4, occurring when high CVs are applied to a pair of inputs.
- Solved the bug in new module 4. Butchered one of the prototypes to validate the circuit – which unfortunately will require PCB and stencil retooling. Did LTSpice simulation to confirm the bug and fix. I’ll have 24 boards assembled with the fix in less than 3-4 weeks, validate them, and then continue with the 200 remaining ones end of the year.
- Prepared a new set of production documents for new module 4 – with the fix.
- After a rather frustrating patching session, reimplemented the last of the 4 main modes/functions of new module 3. I’m now quite happy with it, and we have a golden firmware file for the testing of the pre-production run (available next week).
- Got my hands on new module 2, back from a tester. Tested and optimised the DSP code of the Autechre-inspired easter egg mode.
- Combed through Peaks’ source code looking for possible embarrassing bits. Found nothing scary. So published it!
- Received 24 “stillborn” new module 4 PCBs (1 panel of 6 fully populated, 3 panels of 6 with SMT). Verified that at the exception of the bug, everything else is OK.
Reminder: I’ll close the online shop on sunday (7th) and will reopen 2 weeks later (21st).
- Resumed work on new module 1’s firmware. Currently the plan is to restart everything related to DSP from scratch since I’m still not happy with it (UI and all is fine, though…).
- Demo’ed new modules to the Modular Square guy. Everybody agrees new module 2 is going to be awesome.
- Put out fires on the module testing front: first the display of a module testing unit requiring replacement (1 day of testing lost), then a damage PSU (1 more day), and finally a dead JTAG box (2 days of testing lost before the replacement was shipped).
- Received shipments of Peaks, Edges, Ripples, Frames. Slowly working through backorders. 125 Peaks shipped to dealers, 50 or 60 more dispatched on monday.
- Worked on a custom MIDIpal app for a demanding customer. This is probably the last time I’ll do this as it was ridiculously time consuming…
- Implemented new module 1′s state saving and V/Oct calibration procedure.
- Developed the software tool used for the factory calibration/testing of new module 1.
- Implemented half of new module 2’s easter egg (which probably deserves to be a module on its own).
- To counteract the imminence of the Blanchotian disaster, went shopping for PET COOLS.
- Wrote the factory testing procedure for new module 4 (script, software tool, and a short code update for the module tester).
- Finalized BOM and production documents for new modules 1 & 2.
- Finally ordered the production of new modules 1 & 2 ; 25+225 each. New module 1′s firmware is still far from being done, but I want to make sure everything will be ready to roll production-wise once the firmware is finished.
- Prepared a big shipment of jacks and pots for new modules 1 & 2′s production.
- Fixed some minor annoyances in new module 3′s firmware.
- Fixed some minor bugs / did some minor UI tweaks in the Shruthi firmware.
- Had a couple of good ideas/breakthroughs about a complex oscillator algorithm that is very likely to become new module 5. I’m going to try avoiding getting too excited about it before I finish new module 1′s code first!
- Set up a new (laptop) workstation for when I’m on the go… I’ll travel and close the online shop between september 8th and 24th.
- Received 150 Ripples, verified a random sample of them. Rest of the stuff (Peaks, Yarns, Frames, Edges) will slowly arrive throughout next week.
- Implemented many incremental improvements to all the synthesis blocks involved in new module 2.
- Did yet another pass of code timing/optimizations for new module 2. Found a missing “f” somewhere that had the nasty effect of doubling the runtime of a very important chunk of code.
- Wrote for new module 2 the “signature” code which adds a handful of random modulations and parameter shifts from the MCU serial number.
- Built two new prototypes of new module 2 to send to testers.
- Implemented new module 2′s factory testing backdoor.
- Developed the software tool used for the factory calibration/testing of new module 2.
- Implemented the easter egg for new module 3. Not revolutionary but it’s an idea I had around for quite some time and that certainly did not deserve a module on its own (at least from Mutable Instruments).
- Implemented the factory testing backdoor and wrote the factory testing procedure for new module 3.
- Did the Mouser/Digikey/Farnell shopping for a small batch of complete Ambika kits (probably released around december).
- Worked on small touches for new module 3: smoothing knob moves, better response to very fast inputs.
- Wrote a Scala to SysEx conversion tool – allowing Scala files to be converted into custom tunings for Yarns.
- Proof-read and ordered quick start guides for new modules 3 and 4.
- Filled all the gaps to run new module 2′s code on the actual hardware.
- Benchmarked and optimized sections of new module 2′s code.
- Tracked a nasty SysEx dump bug in the Shruthi codebase.
- Prepared a new batch of CVpal kits – but the lead time for the aluminium faceplates is going to be longer than expected.
- Finished the performance tuning of new module 2. I had originally planned a few secret/fancy features, but I ultimately had to remove them to get the best performances.
- Wrote user manual and quick start guide for new module 2.
- Wrote V/Oct calibration procedure code for new module 2, and routines for persistent storage of settings in flash.
- Got trapped for 3 hours a day in the pink-turquoise world of new module 2.
- Did a lot of tuning/balancing/listening tests on new module 2′s synthesis algorithms.
My week-end project was an application allowing the creation of Scala scale files (or the definition of new scales using this syntax) into MIDI tuning messages recognized by Yarns.
The application is web-based, and online at this address: http://scale-editor.appspot.com
To use a custom tuning table for Yarns:
1. Select a .scl file or type in the text area the definition of your scale. Here is a sample .scl file for you to try!
2. Click Convert.
3. The .scl file has been analyzed, no error is reported! The interval (in cents) between each note and the root note is shown. The application tries its best to map each note in place of its nearest neighbor on the equal temperament scale – this is shown in the fuschia block.
4. Click Download .syx file to grab a SysEx file with the scale description.
5. Send the SysEx file to Yarns, using, for example, a program like SysEx Librarian or MidiOX.
6. Set Yarns’ TS (TUNING SYSTEM) setting to CU(STOM).
7. If you want to change the root note, modify the TR (TUNING ROOT) setting. By default, the scale will start with a root of C (261.625Hz).
Yarns uses the Scale/Octave tuning 2-byte form MIDI standard. As such, the following limitations apply:
- The same scale is repeated for all octaves – only transposed up/down by +/- 1200 cents.
- The scale must not contain more than 12 tones.
- The difference between a note and its equal temperament equivalent must not exceed 100 cents.
- Received, tested (and sometimes reprogrammed with last minute firmware fixes) 125 Frames, 100 Yarns, 55 Peaks, 25 Edges, 55 Ripples. All dispatched to dealers, more to come at the end of the month.
- Implemented new features in module tester for new module 4 test procedure.
- Analyzed a bunch of samples for extracting interesting model parameters for new module 2.
- Wrote bootloader/firmware updater for new module 2.
- Wrote ADC multiplexing and other I/O routines for new module 2.
- Continued development of new module 1′s firmware. 3 out of the 4 DSP algorithms available on the module are finally giving results I’m satisfied with; I’ll tweak the last one or replace it with something else.
- Wrote a DSP algorithm which will be used to extract from samples an interesting bit of data available in new module 2.
- Built a new module tester to speed up the testing of the big batch of modules that has recently been produced.
- Continued development work on new module 1′s firmware. Over the past 10 days the process has been the same: identify the weakest feature/parameter/sonic zone, kill it, and find something interesting to put in place of it. There has been quite a shift in scope, but everything is still happening under a coherent theme. Lots of code refactoring too – with C++ templates used to generate various flavors of the code handling different audio quality constraints.
- Received, inspected, shipped 23x Branches.
- Received a new batch of 250x Volts power adapter. Tested and packed them.
- Built 35x MIDIpals.