Rhythm Wolf - Individual Drums Outs

I got asked by a friend if I could help him modifying his Akai Rhythm Wolf for individual outputs. After opening the little box, it became quickly clear that Akai was nice enough to label five resistors with "Individual Outputs Available Here". Not knowing about the signal levels, etc, it seemed worth to just give it a try and to simply wire them to mini jacks.

For this, I solderd five (red) cables to the upper part of the resistors.

The respective resistors are located left of the TSR jacks, suggesting that the levels get mixed here afterwards.

Quickly measuring the voltages passing through those connections, it became clear that none of them is ground. However, ground can be picked up almost everywhere on the board, and I soldered it to the sleeves of a all (mono) mini jacks. Similarly, the red wires got soldered to the tips.
Initial trials indicated that the signal level was very much sufficient for my friends amplifier/mixer, and also that the corresponding sounds did not get ablated in the main mix. So after drilling small holes into the backside of the case and attaching the jacks there the mod was done :)

Home Automation - Farewell Old Friend

Everything has to end at some point. Here and now, my very first project ends.
The one that made me familiar with µcontrollers.
The one that brought me to electronics.
The one that initiated me as a tinkerer.

HardWareHub

Actually, that is not true - it is the other way around. I started the project because I wanted to do something with µcontrollers and wanted to dive into the world of electronics. What I was missing at that point was a project; a purpose for my tries. That was HardWareHub.

While it is not strictly about sound creation, it is connected with the purpose of this blog in the wider sense and deserves a comment here: HardWareHub was a home automation system. When I started playing music in iTunes, I wanted my amplifier to automatically turn on, switch to the correct input source and to turn the bass down if it is late at night. Similarly, if I received a phone call, the volume faded out and iTunes went on pause. If the TV got turned on, the same actions happened, in case music was playing, but the amplifier switched to the TV source.

It worked quite well for a couple of years, but like many projects without a defined goal, it happened to be in a constant state of changes. At one point I got distracted by other projects and it happened to be left with some functionality temporarily turned off. Consequently, I happened to use it less and less lately and I want to officially focus on more current projects now. When I decluttered some cables in my living room yesterday, I removed the Arduino, the heart of HardWareHub, to give it a new purpose.



Some details for those of you interested in similar projects. HardWareHub consisted of three parts:

• an Arduino managing the hardware side and communicating with my living rooms appliances by mimicking the IR commands of their remotes
• an applescript continuously running as a demon on my computer (which never gets turned off anyway) communicating with the Arduino and assessing states of iTunes, Plex, router (Fritzbox), browser (yes, it also worked with youtube), brightness of my computer screen, etc.
• two javascript widgets to serve as GUIs

last but not least, however I would not consider this a real "part", there was a USB controlled power outlet (Gembird SIS-PM) to switch lights and some devices on/off.

Implemented features included:

• full control over a stereo amplifier through IR commands
• full control over a projected using similar commands
• responsive to their native remotes
• responsive to my own IR commands
• control over room lights through USB controllable outlets
• auto mount of my NAS on startup
• iTunes control through applescript
• PLEX control through HTML commands
• "knowing" if youtube is playing by measuring the performance burden of the web browser
• responding to phone calls (ingoing and outgoing) though an api of the router (Fritzbox)
• evaluating the time of the day and adjusting volume and bass/treble settings
• action based GUI (e.g.. Movie mode turns on the stereo and the projector, switches to the correct input sources, starts PLEX, turns off iTunes, turns the lights off, ...
• device based GUI for individual access to all features

Widget to control the individual devices

Good bye, it was fun and I have learned a lot thanks to you - now it is time to move on...

Celebration

I am very happy to announce that my code to receive and send MIDI Time Code messages and a yet unpublished function to send Real Time messages was just added to the official Teensy core libraries.


Celebrating:

Receiving MIDI Time Codes over USB with the Teensy

Due to a request of a reader of my blog, I elaborated on my extensions for the Teensy 3.x usb_midi library by adding support for callback functions to receive MIDI Time Code (MTC) messages. To fully understand the code, I recommend also reading my post for generating the MTC.

Briefly, the library files where we need to add the missing functions are located (on Mac OS X) in Contents/Java/hardware/teensy/avr/cores/teensy3/. This folder can be found by right-clicking on your Arduino application and then selecting Show Package Contents from the drop down menu.

You can either download the modified files from my GitHub repository and copy them to above folder, or you can modify the files yourself by following the following simple instructions:

Open usb_midi.h and search for "#ifdef __cplusplus". Add the following code one line above that:

Now search for "private:" and add this code right before it:

You are almost done. Save and close the file, and open usb_midi.c instead. Search for "// Maximum number of transmit packets to ..." and add this line above:

As a last step, search for "return 0; } #endif // F_CPU" (they might be distributed over multiple lines) and add these lines of code before the "return 0;"

And voilá, you can now receive MTC messages over USB and evaluate them with callback functions.
Your callback function will receive the MTC as a word parameter. An example sketch showing how to do the decoding is included in the repository...

Monotribe fun

Opinions about the Monotribe are quite controversial. While many like the sound this little device can produce, its lack of midi, 2nd oscillator, etc, are considered a huge draw back by others. Flanked by the Monotron series on the low budget end and with the Volca series having more functionality, the Monotribe appears obsolete and can be tough to integrate into your workflow. However, I got an offer for one that I could not decline - and I love the little thing. Its sound is (except being prone for clicks on note on and off events) raw analog and rich, while not missing a certain level of aggressiveness either.

Further, many of the points of criticism can be readily addressed by slight hardware modifications. These are largely facilitated by labelled soldering pads that Korg graciously put on the pcb. In addition, Midi functionality can be added without the necessity of physically changing the Monotribe, by using a serial connector present in the device and by using Midi commands and messages that are already integrated in all the official firmware releases. Consequently, several commercially available Midi kits from third-parties are at hand, however, these are often overpriced, considering only costs for materials, and many modifications can be implemented with only few and simple steps for a fraction of the price of a kit.

In this context, a modification scene has formed around the Monotribe with a plethora of mods being well described and published online. This information is often dispersed among several sources and I will summarise some of them here while implementing them in my own Monotribe,

Since I would like to have both, Midi DIN connections as well as over USB, I decided to use the Teensy microprocessor again to manage all communication and serve as a bridge between Monotribe, DIN and USB. This approach has also the advantage that there will be quite some processing power available for additional modifications of the synthesizer...

My first implementation is quite crude and demonstrates only basic capabilities: while the Teensy already takes care of the USB Midi communication I further added a small OLED display and a joystick. The display, so far, shows which note is currently played, either through Midi or on the Monotribe's ribbon keyboard, indicates the active drum sounds with icons (not shown in the picture), and visualises the position of the joystick - which in turn controlles LFO frequency and range.

Control Playback/Recording in Avid Pro Tools with an Arduino or Teensy

I would like my Ghz Warrior to be able to sync with Pro Tools. The way I envision this feature, is to be as little as possible in touch with the computer. So instead of using Pro Tools as a Master, and slave the sequencer to it, I would like the Ghz Warrior to be the Master clock and the computer coordinates with that. Since USB hubs are cheap while MIDI DIN hubs are expensive, this should be accomplished through MIDI over USB.

While Pro Tools can send MIDI Real Time Messages (MIDI Clock) and MIDI Time Code (MTC) messages, it can only receive the latter. A quick look at the MIDI reference sheets, and the wikipedia page for better readability, reveals that a full MTC consists of two so-called frames. The combination of both frames encodes the actual second, minute and hour of the song/video/you-name-it that is playing, as well as 2 bits to communicate how many frames will actually be sent per second (FPS). This information is split into eight quarter frames (how was ONE frame defined in the first place?), each consisting of the status byte 0xF1, a zero bit, and then 7 bits encoding the described information in the following way:

  #    Data Byte    Description

  0    0000 ffff    Frame number lsbits

  1    0001 000f    Frame number msbit

  2    0010 ssss    Second lsbits

  3    0011 00ss    Second msbits

  4    0100 mmmm    Minute lsbits

  5    0101 00mm    Minute msbits

  6    0110 hhhh    Hour lsbits

  7    0111 0rrh    Rate and hour msbit

The Digital Warrior, and therefore my Ghz Warrior, is built on the Teensy platform, and I am actually truly grateful to Paul Stofregen and Robin Coon for this great system. In particular MIDI functionalities are extremely easy to implement, and a library for MIDI over USB comes with the installer that well integrates the system into the Arduino IDE. Unfortunately, what is missing in that library are routines to send MTC messages (and Real Time Messages, but more about that in another post).

I quickly wrote two routines to implement sending MTC with the library. To use that functionality on your Teensy board, copy paste the following lines to the usb_midi.h file of the midi_usb library:

On Mac OSX and for the Teensy 3.x boards, you will find the usb_midi.h file by right-clicking on your Arduino application and then selecting Show Package Contents from the drop down menu. In the now opening folder structure, usb_midi.h is located in Contents/Java/hardware/teensy/avr/cores/teensy3/

For the Teensy 2.x platforms, the file is in Contents/Java/hardware/teensy/avr/cores/usb:midi/
Make sure to select the right folder according to the hardware you have (selected in the Arduino IDE).

A fully modified version of the file for the Teensy 3.x is also available on my GitHub page. Further, I have put there an example sketch that synchronises your board with Pro Tools (Arduino/Teensy = Master, Pro Tools = Slave) and have the play/record status of Pro Tools respond to button presses. As a bonus, the option to use a standard serial connection without the need to use above library tweaks are included. By that you can also sync out-of-the-box Arduinos with Pro Tools.

Presets in the examples are a button connected to pin 4, and MTCs with 25 FPS.
For this, in Pro Tools, go to Setup/Peripherals... and set the MTC Reader Port under Synchronization to any:

Then, open Setup/Session and select 25 as the Timecode Rate:

Finally, put Pro Tools online by activating the corresponding button in the Transport window:

When you compile the sketch for the Teensy, make sure to select USB Type: "MIDI" in the Tools menu of the IDE, and everything should work out of the box.



Note:

If you use an Arduino, or compile the Teensy with the USB Type: "Serial" option, you will need to use a serial to midi bridge. This converts the incoming serial commands to actual MIDI messages in your computer. I found the free Hairless quite useful for this.

In Hairless, select your Arduino/Teensy in the Serial Port section, and the IAC Driver as a MIDI Out. Activate the Bridge and you are also done on this route :)

Digital Warrior - SD Card Mod

The parts for my very own Digital Warriors have arrived - and they really look good.

However, as pointed out in my last post, there were a few things I was missing among the functionality:

The Digital Warriors are based on the Teensy microcontroller development system, and consequently, the original design makes use of the Teensy's internal 2kb EEPROM to store its data. Naturally this tremendously limits the amount of data that can be saved.

To be able to use the Digital Warrior most flexibly and efficiently as a stand-alone sequencer, I wanted to use an SD card instead of the EEPROM. This would allow me to implement longer

Unfortunately all through-hole pins on the Teensy are already used by the Digital Warrior's standard functions. To make things worse, we can not freely choose any pins for the SD card access. SD cards are typically connected through the SPI ports and these are on: pin 13 - SCK, pin 11 - MOSI, pin 12 - MISO. Alternatively also pins 14, 7 and 8 can be used respectively, but these are also occupied. The fourth SPI pin, SS, is less of a problem as it is freely assignable.

Looking at the Digital Warrior firmware, it it quickly became clear that the necessary pins are easily re-routable. Pin 11 is used by one of the encoder push buttons, pin 12 the sequencer button, and pin 13 the track button. Changing the pin assignments in the software is pretty easy, rerouting them in hardware is also not really a problem. I decided to use the pads, on the bottom of the Teensy, 31, 32 and 33 for the button pin reroutings and soldered small cables on them before attaching the Teensy to the PCB:

Then I removed the corresponding pins from the headers which I used to solder the Teensy to the pcb. And finally connected the cables to the corresponding spots on the board:

A quick test with my updated firmware confirmed that everything was working well.


Similarly, for the SD card, I decided to use pad 29 for the SS pin, and added a small cable here as well:

Afterwards I soldered the Teensy to the PCB and connect the remaining cables (the purple one was too much) to pins 11 (brown), 12 (red), 13 (grey) as well as GND (black) and 3.3V (white). The other side got soldered to the corresponding points on the micro SD adapter  as described here, and voilà - done:

The first version of the Ghz Warrior firmware to start using the SD card instead of the EEPROM can be found on my GitHub page.