Fun with Midi Pedals

I rediscovered my hobby playing the guitar in the last years. It was interesting to see the big changes that happened in the last 20 years in guitar amplification technology. In the 90ies i used to play my guitar with a couple of stompboxes into a huge 100 watt tube head with a 4×12 cabinet. Very loud and heavy stuff. Today there are many new options, especially when you are into computer stuff. So amp modeling on the computer is a thing. This might not be rock solid setups for on stage performance. And sure i like to play my Marshall DSL straight with a Tubescreamer in front and delay pedal in the FX loop. Great sound. But the stuff you can do with amp modeling on the computer is really fantastic.

Bias FX Bias FX

Bias FX

At some point i settled on Bias FX from Positive Grid, because its just does everything i need. I use it as standalone and in Logic Pro as a plugin and also on my iPad. I use Bias Amp 2 with gives even more option playing with the parameters in in your amp. You can basically change each aspect of your amp, like preamp tubes, power tubess, the transformer, voicing stack and finally your IR for cab simulation.

Bias AMP Preamp Transformer

I sometimes get a bit frustrated with the code quality of Positive Grid products. The frontend parts tends to be a bit buggy, like crashes when you paste a password in Tone Cloud login screen, stupid stuff like this. The UI consistency between their products is not great either. But on the positive side, you can try out so many different tones in Bias FX, using different pedals, setup stereo stacks or play with IRs. So you can basically try out tones that usually not possible to achieve, because it not feasble to aquire so many different pedals and amps, to get that certain tone. You want to sound like Metalica on Ride the Lighting, just login to Tone Cloud where you can download all kinds of community driven tones, there you will find a preset.

What i dislike with, that i often feel interrupted from playing because i have to grab the mouse and tweak some settings or toggle a pedal. Not really a relaxed playing position while cramped in front of a computer. For me that stands a bit in the way of playing. I figured it would be nice to have a foot controller for my amp modeling setup. I knew Bias FX supports Midi, so i got into Midi controllers.

Behringer FCB1010

Behringer FCB1010

After some research i went with the Behringer FCB1010 and the UNO firmware, it seemed so have all the features i needed and looked highly customisable.

Midi Monitor

I tought i will spent just a couple of minutes to connect to my Audio Interface and setup some “midi commands” in Bias FX. Man was i wrong…It was not that easy. I had to get my hands dirty and understand Midi basics. I used the Midi Montor to see whats was going on the wire.

Since my footcontroller came with the UNO firmware, which support the concept of stompbox in patches i was looking into that feature to get it working with Bias FX. So the idea is to have 5 different patches on the lower switch row. Pressing switch 1 will trigger a patch change e.g. “Dist Rythm”. The foot controller sends a Progamm Change(PC) to Bias FX. Once the patch is active, you can control individual stompboxes within the patch, using the top row of switches. Pressing one of the top row switches will trigger a stompbox toggle by sending a Control Change Messages (CC) to Bias FX. Here is a example patch and stompbox config.

Patch Name PC
1 Dist Rythm 1
2 Dist Lead 2
3 Clean Picking 3
4 Clean Chorus 4
5 Clean Lead 5
Stombox Name CC
1 Boost/Dist 51
2 Mod 52
3 Delay 53
4 Reverb 54
5 Misc 55

So my plan was to configure 5-10 patches with 5 stompboxes each. I also wanted to add support for the expression paddles on thefoot controller. That i can map one CC for Wah-Wah and a volume pedal. And another CC for the pedal value. Put the foot controller in programming mode, then you would be doing some crazy “River Dance” style pattern tapping on the switches to get all the patches setup. That was not my cup of tea, too lazy for that. Started to look for a desktops program that would assist me building the config for the foot controller.

UNO Control Center

There is the offical FCB/UNO Control Center that work on OSX, but it was a bit glitchy and unmaintained, there is no 64bit build, which Mojave is starting to complain about. So i was not feeling confident spending 20 Euro on that.

FCB1010 Midi Editor

Spreadsheet View

I ended up using the FCB1010 Midi Editor via Wine.There were some quirks, like that i was not able to persist certain CCs for specific switch, which i could work around. After spending a couple of hours and many config round trips sending SysEx i got the setup working with Bias FX.

But one thing wasn’t working. When selecting a patch, each stompbox would have an inital state. Like patch 1 has the distortion pedal and the delay pedal active, thus the status led of that switched would be on. Which also means that the foot controller send a PC 1 to switch the actual patch in Bias FX and CC 51 and CC 53 to enable the distortion pedal and the delay pedal. But thats not how Bias FX works, if you select that patch in Bias FX the stompboxes are active in the patch. So the footcontroller would actually do the opposite, it would disable the distortion and delay. I tried to mitigate the problem my changing the initial stompbox states in Bias FX, but that was not was i wanted, because i often select the patch via mouse input. It also didn’t work consistently due timing issues. So i needed a feature to enable a new patch that has certain stompboxes active but not triggering the stompboxes CC messages on inital select of that patch. The UNO firmware would not support such.

Time to build my own Midi Controller

I started looking around and found an Midi examples using an Ardunio. I was never a huge fan of Ardunio, didn’t like the IDE and that it tries to hide all technical details from you. But there a lot of easy accessable components and librarys, which will make the project a lot easier for me. I found this Arduino Makefile project, so i could go without the IDE.

Poc

I stared with getting a debug console running and then implemented some midi commands using the midi library. Conntected some the switches and status LEDs to the POC. Added a debounce switch lib to get the switches working properly. Now it was time to write the real program. I came up with a couple of C structs to hold all the patch meta data and states. Finally added a small OLED Display via I2C for status display which patch is active and with stompboxes are selected.

main.ino

Soon i ran into hardware limits. I could only use half of OLED display because if was already out of SRAM on the AVR, and i could already see that i would run out of IO pins, too.

Ardunio Mega

So i switched to Ardunio Mega and 2,2″ QVGA TFT LCD Display. After refactoring the hardware part of the software , i got the the new display working. Time to cleanup the code and throw most of the stuff into a C++ class. I was trying to convert all the config stucts to C++ classes, but then the dynamic character of C++ got into the way and was eating to much memory, so i stayed with the static c structs for the config.

Poc

Downside was the TFT SPI display was a lot slower, too slow infact. Sure it has a lot more pixels to push, but still it was slow as a dog. Initial display code was a bit too simple.

  • Clear the screen
  • Render patch name and state
  • Render all the stompbox names and states

Patch 1

Patch 2

First i tried a different display lib which seems to be faster than the Adafruit_ILI9341 lib. But even with the faster lib, my approach to rendering was not fast enough. So i moved away from full blanking and switched the display code to partials updates.

What now…

The POC phase of the project is done and now its time to build the complete pedal. I need to put everything in a nice case, add all the 10 Momentary Switches and 10 status LEDs. I don’t really need to make PCB, everything can be wired directly to the Ardunio board, there are just a couple of pull ups, that can directly go on the switches. I need to decided how i want to do external power, probably the easiest way to do it, it to give access to the USB port of the Ardunio thru the case and use external a USB power brick. The hardest part right now is to find a nice case for it.

To be continued…

Building a Company

Its been some time since I blogged about the development of my company Userlike that I co-founded in 2011. It has been 5 busy years since I last blogged about Userlike.

Since then I haven’t had a lot of time to work on gaming console related hobby projects. (Despite some work on the AspectQt port and a Amiga Intro I made). I hope to find more time to work on new projects. I already have planned to update the quickdev16 software a bit.

It has been an awesome time developing the company. Our headcount grew from 3 people working at Userlike to 20 people today. The customer base grew from a couple of hundreds signups to 30k customer accounts that we are handling right now. 4 Years ago we were more or less working from home office all the time. Then we moved into our first office space in the center of Cologne like 2.5 years ago. This was a huge step for us and moved the company forward. As of today we have already outgrown the office space and started looking for a new and bigger place to call our new home.

Wasn’t slow on the technical side either. I guess its fair to say that we replaced each of our software components at least once by a either re-write or different approach. And still we are refactoring and getting rid of technical debt all the time. On of our most visible components is the chat messenger widget itself, where we are on the 3rd major iteration. Each major version introduction involves a migration phase for our customers. This is always a huge task for the development team, to make the migration smooth as possible while maintaining multiple software versions of the messenger.

Developing a SaaS can be tricky. You always have to balance between customers requests, not falling behind competition and don’t overloading your product with options that hardly anyone is using. The challenge is to find the right compromise, being pragmatic sometimes helps.

Devops side of the project wasn’t less interesting. Last year we switched our datacenter, since we had outgrown our old setup and approach of scaling we went for something new. Now we rely on automatic deployment of our system which we solved with Ansible and are very happy with it. Another big change for our infrastructure was to switch from MySQL to Postgres. The reason for this was quite pragmatic. We used to store all business data in MySQL and stored all bulk data in a mongoDB. Over time and a growing dataset it became clear mongoDB is a hard to handle memory wasting database. So we decided to move to Postgres and merged the mongoDB bulk data using the Postgres JSON type feature. It was quite a task to do the data migration, but since then we never looked back.

We kind of matured the feature set for Userlike over the last 4 years and already branched out into new fields. We started integrating different messenger channels like Telegram and Facebook. Another new development will be to break up the online / offline communication paradigm to a more async and sync communication which will yield to higher usability for professional support teams using Userlike.

Btw, we are hiring and extending our developer team. If you are a python and javascript person, or like building infrastructure, we might have the right job for you.

Bake that Book

Last Summer i gave my old Macbook Pro 15″, Late 2011 with 8GB and 160GB SSD to one of my team members at Userlike, since i got a Retina upgrade. I think the old one was still decent, since the SSD gave it that boost to make it usable, even if the laptop was 2 years old at that time. Unluckily the old Macbook Pro didn’t last long, it just died after 3 month. Wouldn’t turn on anymore. As i predicted, after bringing it to the Apple Store, they said the logic board was fried, which always means its totaled. We bought a new Macbook and moved on.

Now i got the broken Macbook back to my place and i thought i would at least sell the display, case and reuse the SSD. But i remembered reading all the Macbook baking blog articles. I already disassembled a few Macbooks down to the logic board and also did some reflow stuff for side projects. Also knowing that a friend of mine has good experience with baking old Nokia phones, i though i give it a try.

  • Go to ifixt.com and look up the tutorial to change the logic board
  • Disassemble the laptop, collect screws and parts in separate containers
  • Be becareful with all the ribbon cable connectors, there are a lot and some are tricky
  • Get the logic board out, remove heat pipes, ram and speakers
  • Preheat oven to 180c
  • I cleaned the board with isopropyl alcohol
  • Set board on tin foil legs on a baking tray
  • Put in the oven for 7 minutes
  • Let it cool fast at a open window
  • Clean fans and case from the inside
  • Assemble, make sure to get all cables connected
  • Boot that Book

I hoped that i had a 50/50 chance that it will work. I was confident, that i don’t mess the laptop during disassemble and assemble phase, i wasn’t sure what the result was after baking. I remembered that the laptop got quite hot while working, so there were some odds that this permanent heat would have altered the setup of the parts of the pcb. And it turned out to be worth the work, the Macbook booted up nicely.

Get your tools

IMG_2536

IMG_2534

IMG_2537

IMG_2538

IMG_2540

IMG_2543

AspeQt for OSX

2 years ago i started to transfer my old Atari 800 XL software from the 28 years old “5,25 disk to ATR images on my laptop. But i was never happy with the setup using a windows program in a vm to do the transfer. I found AspeQt which is opensource, but it did not support OSX. So i started to add an serial driver with OSX support to it. And then forget about it. Till recently when i got an email from the AspeQt maintainer Ray who asked about the state of my github repo. Since i want OSX support in the mainline, i picked the lastest version of AspeQt to update my repo, which already got a little stale. Then i found out that is a pain in the ass to run QT4.8 on Maverick, there is no offical package and building from source you end up in patch hell.

So i decided to move my branch of AspeQt to QT5.2, which was pretty straight forward.

QtCreator is not a great editor but does the job

QtCreator
QtCreator

AspeQt on OSX

AspeQt on OSX
AspeQt on OSX

Found some cool stuff on my disks

Software from the 80ies
Software from the 80ies

Meet my new project Userlike

Its not that i have been kind of lazy about blogging the last year, its just i didn’t to anything on my side projects like SNES hacking or the like. I quit my day job last year and started founding my own Company Devcores. Last Summer i began coding our first SAAS wich entered the beta phase last december. Lets meet Userlike. It’s a webbased live chat system targeted for online shops. It SAAS and can be added with one line of javascript to your website. We are in private beta right now and plan to release the first public version with the next 2 month. If you want to test it, drop me a line and i will get you an account.

Userlike

Quickdev2 Progress

After building the quickdev16 in the summer of 2010 we decided to work on a 2nd version off the quickdev16, which we called quickdev2. All this work was done in the summer of 2010 but i never got around to finish the project nor to blog about it. So here is a little overview:

The next quickdev should be a little bit faster and should have more features. So we selected a new CPU, the Atmel at90usb1287 that can handle USB via hardware and has more SRAM. To simplify the logic part we opted for a XILINX CPLD xc95144xl. We used a bigger Cypress 16-Mbit SRAM CY62167E. The AVR would expose the USB interface to the PC side, as a masstorage device using the LUFA library. The AVR has a data bus to the CPLD. The CPLD is also connected to the external SRAM. In the CPLD we implemented a SREG, counter, commandmuxer and memory interface in Verilog.

The system top looks like this:

module system (

    inout [7:0] sram_data,
    output [20:0] sram_addr,
    output sram_oe_n,
    output sram_we_n,
    output sram_ce_n,


    output [7:0] snes_data,
    input [20:0] snes_addr,

    inout [7:0] avr_data,
    input [7:0] avr_ctrl,
    input avr_clk,
    output [7:0] debug
);

We have a 8 bit data bus and 21 bit address bus to the SRAM. 3 extra lines for OE,WE and CE. Then there is the same setup for the SNES side. 8 Data and 21 address line. No more control lines to the SNES are currently implemented. There is a 8 bit data and 8 bit control bus to the AVR. Finally we have a CLK line from the AVR to the CPLD and a 8bit debug bus. The AVR clocks its own clock into the CPLD, which is feed into a DCM and is divided by 2. This clock signal is feed into the FSM and SREG internally. The avr_ctrl bus is feed into a commandmuxer which drives the other components on the CPLD. Foremost it drives a FSM which manages the data routing between AVR <-> SRAM and SRAM <-> SNES.

module bus_fsm #(
    parameter DWIDTH = 8
)(
    input                   clk,
    input                   reset,
    input                   we_n,
    input                   oe_n,
    inout   [DWIDTH-1:0]    avr,
    inout   [DWIDTH-1:0]    sram,
    inout   [7:0]           debug
);

parameter SIZE   =  3;
parameter IDLE    = 3'b000;
parameter WE      = 3'b001;
parameter BUFAVR  = 3'b010;
parameter BUFSRAM = 3'b011;
parameter OE      = 3'b100;


reg   [SIZE-1:0]          state;
reg   [SIZE-1:0]          next_state;
reg   [DWIDTH-1:0]        buffer_avr;
reg   [DWIDTH-1:0]        buffer_sram;
reg   [DWIDTH-1:0]        buffer;

assign avr = buffer_avr;
assign sram = buffer_sram;

always @ (state or we_n or oe_n)
begin : FSM_COMBO
    next_state = 3'b000;
    case(state)
    IDLE : if (we_n == 1'b0) begin
            next_state = BUFAVR;
        end else if (oe_n == 1'b0) begin
            next_state= BUFSRAM;
        end else begin
            next_state = IDLE;
        end
    BUFAVR: if (we_n == 1'b0) begin
            next_state = WE;
        end else begin
            next_state = IDLE;
        end
    BUFSRAM: if (oe_n == 1'b0) begin
            next_state = OE;
        end else begin
            next_state = IDLE;
        end
    OE : if (oe_n == 1'b0) begin
            next_state = BUFSRAM;
        end else begin
            next_state = IDLE;
        end
    WE : if (we_n == 1'b0) begin
            next_state = BUFAVR;
        end else begin
            next_state = IDLE;
        end
  endcase
end

//----------Seq Logic-----------------------------
always @ (posedge clk)
begin : FSM_SEQ
    if (reset == 1'b1) begin
        state < = #1 IDLE;
    end else begin
        state <= #1 next_state;
  end
end

//----------Output Logic-----------------------------
always @ (state)
begin : OUTPUT_LOGIC
  case(state)
    IDLE: begin
        buffer_avr <= 8'bz;
        buffer_sram <= 8'bz;
        buffer <= 8'bz;
    end
    WE: begin
        buffer_sram <= buffer;
    end
    OE: begin
        buffer_avr <= buffer;
    end
    BUFSRAM : begin
        buffer <= sram;
    end
    BUFAVR : begin
        buffer <= avr;
    end
    default : begin
        buffer_avr <= 8'bz;
        buffer_sram <= 8'bz;
    end
  endcase
end

assign debug = { clk,we_n,oe_n,state,2'bz};
endmodule

From the AVR software side a SRAM write looks like this.


void sreg_set(uint32_t addr)
{


    uint8_t i = 21;
    #if SREG_DEBUG 
    uart_putstring("sreg_set\n\r");
    #endif
    SET_AVR_SREG_EN_HI();
    while(i--) {
        if ((addr & ( 1L < < i))){
            SET_AVR_SI_HI();
    #if SREG_DEBUG 
            uart_putchar('1');
    #endif
        } else {
            SET_AVR_SI_LO();
    #if SREG_DEBUG 
            uart_putchar('0');
    #endif
        }
        SET_AVR_SREG_EN_LO();
        SET_AVR_SREG_EN_HI();
    }
    #if SREG_DEBUG 
    uart_putstring("\n\r");
    #endif
}

void SRAM_write(uint32_t addr, uint8_t data)
{

    // set direction of data port
    AVR_DATA_DIR = 0xff;
    // load address
    sreg_set(addr);
    // disable OE and WE
    SET_AVR_OE_HI();
    SET_AVR_WE_HI();
    // wait for FSM to go into IDLE state
    nop();
    nop();
    // write data
    AVR_DATA = data;
    // enable WE
    SET_AVR_WE_LO();
    // wait for FSM to go into WE state
    nop();
    nop();
    nop();
    nop();
    // disable WE
    SET_AVR_WE_HI();
}

The development was done on our new prototype board, which Max layouted for us. I used an AVR Dragon for the AVR programming part and debugging via JTAG. For the CPLD side i used a homebrew Xilinx Platform cable alongside with ISE. I quickly stopped using the IDE and just cooked my own Makefile using the Xilinx commandline tools.

Most of the logic was developed using a testbench and running through iverilog. But having a module working in a testbench doesn't mean that it works on real hardware. We had todo a lot of debugging on the real hardware. This involved a lot of test probe soldering. Luckily we had my 8bit Saleae LA which helped a lot to track done some Problems. But the biggest issue was to get the timing right with the FSM for the memory bus.

We hacked this in a 3 day weekend sprint and implemented the SRAM read and write from the AVR side. But then we hit a wall and didn't implement the SNES side. The project lost some traction. Max had moved to Berlin we couldn't work together on the project anymore. We lost a little interest because the sd2snes project achieved what we we intended to do and Ikari_01 did far better job then we did. I recently got word the sd2snes is considered stable and a first batch is sold.

We plan to start working on this again. To implement the SNES side of the memory we would need to increase the speed of the FSM to get it into IDLE state and then in SNES state within 120ns or 200ns after the SNES does a CS on the cartridge. Since the AVR drives the CPLD clock with 20MHz, we would need some kind of PPL to run the FSM with like 60MHz, which should be plenty to run the FSM for the SNES SRAM read.

We appreciate any comment or suggestion for the hardware design of this project.

Super Nintendo Talk

A while ago i held a talk at the ccc in cologne about my favorite game console the Super Nintendo. This talk covers the Super Nintendo technology in detail. Starting with the CPU and PPU, covering the cartridge memory maps and showing most of the custom chips which where used on cartridges. I also show development hardware, copier stations and the current available flashcarts. The topic emulation is also covered . The second part of the talk is about the quickdev16 project, which i did with my friend max in 2009. We built a flashcart for the SNES which is useful for developing homebrew software. The talk sums up all the details i learned during the research i made to built this kind of cartridge. I uploaded the slides, maybe someone find this useful to dive into the SNES world.