- 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.
- Continued writing and experimenting with new module 1 DSP code.
- Worked with Hannes on panel revisions for new module 1 and new module 2.
- Planned & ordered parts for a new run of Anushri kits + end of the year Ambika kits.
- Identified and salvaged the good bits from new module 1’s DSP code.
- Found a coherent theme/UI under which the good bits from new module 1 could be combined with other stuff some of you will love playing with.
- Wrote a lot of code, almost done on the new firmware for new module 1. That was an intense coding marathon, and I’m continuing over the week-end.
- Built my RYO optodist.
- “This is April to… boobelyboo. This is err, misc… And this is… other.” Gathered and sorted all Q2 documents for the accountant.
- Validated production docs for new module 3 and 4.
- Prepared a last list of quality checks for the production batch of Peaks – SMT assembly launched!
- Wrote user manual for new module 4.
- Built a couple of module 3 & module 4 protos for early testers.
- Found that one of the module 3 I’ve built behaved a bit differently from its siblings. Added a software calibration routine so that the odd ducks can be identified and fixed during factory testing.
- Cleared on the breadboard some last doubts about new module 3′s analog circuitry.
- Tweaked levels/response curves/parameter ranges in new module 3′s code.
- Did a bunch of last sanity checks on new modules 3 and 4 (output and power supply protection, noise and bleed measurements, current consumption check).
- Received a batch of 25 Peaks. Tested tested tested, packed packed packed, shipped shipped shipped.
- Received the hardware and knobs for the Anushri rack-mounting kits. Back on the shop, more shipping!
- Refactored most of new module 1′s code to make room for new parameters and treatments, and added plenty of optimizations.
- Sent production order for new modules 3 and 4 (25+225 each). Prepared production documents.
- Wrote new module 3′s quick start guide.
- Got slowed down by a few repairs.
- Finished all optimisations in new module 1, everything I wanted in there now runs in realtime, on the real hardware. Put it in the case for hours of fun and… I am not happy – some things are great, some others don’t feel right. And the things that are great could fit in a less expensive 10-HP module… I will try to see if the same feature space can be achieved using other DSP techniques over the week-end. If so, it’ll become a different beast running on the same hardware. If not, I’ll move on and keep the good bits for a simpler module.
- Finished the DSP code for the second half of new module 2, including obsessive fine-tuning of all parameters ranges and control curves.
- Wrote all the glue / meta-parameters code that wraps together the two halves of new module 2 in an interface ready to be grafted onto the hardware – the main class that needs to be fed a stream of trigger input, codec and ADC values!
- Did most of the overall tuning/sound balancing of new module 2. Very happy with the results, but I want it badly to work with at least 2-3 voices of polyphony so optimizations will be necessary.
- Built and tested latest iteration of new module 3. Circuit performs well. There are a few 3D glitches that needs to be solved (parts very close to each other with risks of assembly problems), but I am not reordering a PCB for this – so this one finally goes into production!
- Implemented a “snap” feature for locking the potentiometers when Peaks is used in Expert mode. Added state saving code so that the state of the 4 “hidden” potentiometers in Expert mode are saved when the module is powered off.
- Received a batch of pre-production Branches. Gross assembly mistake, sent back to the assembly house for repair :-/
- Experimented with a nice stereo/spatial/verb output mode for new module 2.
- Experimented with approximations in various areas of new module 2′s code. They are actually not a bad thing at all and add a little flavor of analog detuning/instrument stretch-tuning.
- Fixed a last set of minor annoyances in new module 3′s firmware.