MemeCode - Blog

Blog

Page: 0 1 2 3 4 5 6 7 8 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85 ... 90 ... 95 ... 100

Logic Pro X bounce time
Date: 27/4/2016 Tags: logic audio	I was doing some mixing today and the bounce time in Logic Pro X seemed very long. Much slower than I was expecting. (Bouncing is basically "rendering" all the audio down to a stereo track for those wondering). I opened up the Activity Monitor and Logic was reading 10mb/s off a disk capable of 100mb/s. CPU was about 30%, i.e. it's using one core (of my 4 core i5 machine). In true programmer fashion I started to google the problem and it appears that people are having trouble with various plugins being slow. I didn't have anything much loaded, just lots of audio tracks. But I tried disabling the reverb to see if it made any difference. None whatsoever. I began wondering about the disk speed. Maybe it's causing problems? So I copied the project (all 50GiB) onto a fast USB3 flash drive and run my test again. The export of 2 songs went from 2 minutes to 20 seconds. Uh, ok, wow that's pretty different. Then I started to wonder about why that is so. The USB3 flash drive is capable of 190MiB / second, and the original hard drive can do 110MiB / second. It's in the same ball park really... so why the order of magnitude performance difference? I think it comes down to the read strategy of Logic. Now I'm just guessing here, but I think it reads small blocks (KiB) of audio from the files to keep the in memory buffer of audio small. This means in large projects with many audio tracks seeking from one file to the next constantly trying to get the next little bit of the audio. This is kinda worst case for a mechanical drive that has to move the head to a new location between each file. Seeking is expensive. On the USB key, seeking is almost free... so it runs fast. Now the authors of Logic could have bumped the buffer size up considerably so that when trying to access lots of audio tracks there would be more reading and less seeking between files. In my case with 16GiB of RAM to burn that would be fine, but might be an issue with smaller RAM sizes. You certainly can't afford any paging during audio work. Still Logic should be able to see how much RAM is available and size it's internal buffers accordingly. Obviously for anything to do with "live" audio the buffer size has to be tiny, so that the latency is short. But for pre-recorded material buffering up a few MiB's of audio shouldn't be an issue.
(0) Comments \| Add Comment

MC2 April Progress
Date: 3/4/2016 Tags: mc2	So here is a scary idea... I'm playing next weekend in my live band. Should I use the MC2 for the first time? If I get a bunch of stuff finished I don't see why not, although I'll definitely have the MC1 packed in case it doesn't go smoothly. The main hurdle will be the expression pedal ports which I haven't really done any work towards other than getting the ADS1115 chip to show up on the I2C bus. Nothing like a dead line to get you moving. Running progress: 1/4 Wired up the rest of the encoders, and their buttons. Implemented the software side to read all their state changes. I now have 6 encoders fully working. 2/4 Fixed the button handling to only do something of the "down" event. Lowered the maximum brightness of the Neopixels a lot... otherwise they are almost white instead of the selected colour. This also uses less power, which is nice. 3/4 Implemented software button debouncing to remove duplicate up/down events. Also added "held" buttons events that fire if I button is held down for more than 1200ms. This is useful for hiding advanced features. I might use it to access the Y settings of Axefx2 blocks connected to Instant Access buttons for instance. 4/4 Implemented tuner support on the higher resolution screen of the MC2. Yay for not having to make custom text characters to display a line. Hooked up the encoder output to the Axefx2's EXTERN 1-8 CC messages. Limiting the range to 0 - 127 and adding a little acceleration if the user is turn the dial a lot. I've managed to get one twist of the dial to go from 0 to 127 and yet retain some fine control when moving slowly. It seems to be reasonably good transitioning from non-accelerated to accelerated. Bought some stereo switched insulated jacks for implementing 2 expression pedal ports. The system supports 4 but I only need one at the moment. Also bought some plastic knobs for the encoders, just till I work out what ones I really want. Ideally I'd get something that is suitable for recessed shafts. Most knobs cater to raised shafts, where the nut is above the panel surface. 5/4 Drilled and deburred holes to mount the MIDI and expression pedal jacks on the case. Soldered together the expression port jack and hooked it up to the ADS1115 chip. The stereo socket is a DPDT switch as well which allows me to detect when there is no expression pedal plugged in. Basically I set +3.3V for that condition, and start about +3V for maximum expression. Wrote the corresponding code to read the value from the ADS1115 chip over the I2C bus. This was pretty straight forward. I keep a min and max value to auto-calibrate to the pedal. And that technically means the MC2 is out of Alpha into Beta! All the basic functionality works. However there is a lot of road testing to go :D 6/4 Added a row of labels under the IA config buttons to say what the buttons are currently configured as. Added an continuous parameter mimic control to display graphically the position of things like encoders/expression pedals. This looks like a circle, with a line showing the "amount" radially, just like the Axefx2 parameter display: Fixed some display bugs when switching presets. Added a script to start the MC2 application on startup. Obviously I want the program to start automatically when I'm using the system live. Added a button on the setup page to shutdown Linux. There is a confirmation dialog before that happens. Now I can start and shutdown the whole thing without a keyboard attached. Excellent! Took the plastic off the touchscreen... oooooooooooh! ;) 7/4 Added a MIDI disconnect event to the Raspberry Pi hardware layer. Basically if it doesn't see any MIDI for 3 seconds it flicks over to "disconnected" mode. Normally the tempo messages keep this from happening. There is no easy way at a hardware level to see if MIDI cable has been unplugged. Going to start "testing" things by doing my personal rehearsal during the day. Then tonight I have the full band rehearsal. Fixed the select scene 'n' IA button selecting scene 'n+1'. Removed the nice highlights on the buttons to improve rendering speed. Currently the GUI thread is running the controller code, and message passing is limited by the redrawing of the screen. This is not ideal and I will fix it at some point but I just want it to work ok for the weekend. So things like the expression pedal send a message from the hardware IO thread. And it's laggy because of the screen updates. At some point I'll need to break out the profiler and find out where the time is going. Most likely there are a number of CPU bottlenecks in the graphics and text handling code. Changed the expression pedal reads to happen every 8ms instead of 16. Again in an attempt to improve latency. I can probably improve that again by reading up on all the ADS1115 modes. I think it can do like 800 samples a second but I'm getting a lot less than that ATM. Band Rehearsal There were no major issues at the rehearsal. It all worked pretty much as I wanted it to. The only minor issue is that if I configure a bunch of IA buttons the text on the labels is pushing the layout off the right edge of the screen: So I'll have to fix that in the layout code. One problem is that the edge of the touch screen doesn't really work, so if things are too near the edge you can't activate them. The second issue is that is just looks bad. Hahah. I'm really liking the layout of the hardware buttons. Having the IA buttons along the near edge is much better for triggering things during the song. And the tap tempo on the corner is also better than the location on the MC1. Being able to dive in and setup a new IA button quickly was also really useful (I decided I needed some Phase90 in my life last night). I also noticed a text clipping bug when text is off the right edge of the screen it wraps around to the left edge. Hmmm should fix that sometime. 8/4 Fixed the layout bug by adding some CSS to the text label cells: max-width: 59px; The text overflows a bit for larger labels, but at least the position of the buttons doesn't move. 10/4 Live play testing! Yes I took it out to play live this weekend. It went pretty well overall. For the most part everything worked as well as I had hoped. The main glitch was at the very end of the first set the buttons stopped responding for a little while. Touch screen was still good so I just shut it down and restarted for the next set. It didn't affect my performance though. After rebooted it seemed to settle in ok and the 2nd set went without any problems. The expression pedal lag was still there obviously but I worked around that. There may be some display issues with the IA LEDs. I thought I noticed some block IAs in the wrong state after scene changes. But I was pretty busy just getting on with playing rather than analyzing the IA states. Something to follow up later.
(0) Comments \| Add Comment

MC2 March Progress
Date: 1/4/2016 Tags: mc2	After when seems like forever I bring you an update on the MC2 project. The good news is that most of the hardware is now working, including MIDI Input/Output, the Neopixel chain, the I2C bus to the GPIO expander chips, which in turn connects to the buttons and encoders. In short I can now use it to change presets on the Axefx which is like the bare minimum functionality. Some of the issues I've had to sort out: Very slow compile times on the Raspberry Pi I'm only using a Pi B (version 1, rev 2) so it's got a single core running at 700MHz which frankly is molasses slow. So I decided that it was worth getting a cross compiler working on something with more grunt. It took days of mucking around, and 3 different builds, copying off almost the entire Pi's worth of headers and libraries, but it now works. More importantly it's fast. My main dev box (3.8ghz i5 /w 16GiB of ram) chews through the code very quickly, and then copies the binaries down to the Pi over the network. PiTFT touch screen not working correctly The behaviour I was seeing was the cursor stuck in the top left, and the x & y axis' were swapped. I ended up building SDL from source and then inserting a pile of logging during the mouse driver setup only to discover that it was using the default mouse driver instead of the touch screen driver that I had configured in the environment. It turns out that as I'm running the code as root (sudo) the environment is different than my normal user account. Ok, so now I just set the right env vars in my C code before initializing SDL. Which forces it to do the right thing on any account. I2C bus not working / unreliable This came down to adding 1000uF electrolytic over the 3.3v supply line, and also adding 0.15uF decoupling caps over the +V/GND pins of the GPIO expander chips. Also I had to change the pull up resistors connected to the SDA+SCL data lines from 4.7k to 10k. Neopixel chain stopped working Eventually I found a cold solder joint on the ground pin output. Only after disassembling it completely, including the button harness and taking the plastic backing plane out. MIDI input not working / garbled This has actually taken most of the week to sort out. The hardware for the input side seemed ok, and I even did see some incoming MIDI at one point. Initially it was garbled and I tweaked the baud rate with system settings. It seemed to work for a while then stopped again. I got very frustrated with not being able to see the logic signals in the circuit so I went and bought a Bus Pirate which can read both the UART and do logic analysis. I tested all the hardware I could in isolation. I went over the traces like 6 times. I tried the optical isolater chip in my MC1 and everything appeared to be good. I even pulled the diode out and tested it in isolation. I tested the Rx+Tx pins of the Pi by hooking it up to the Bus Pirate and had the Pi talking to the PC. Then I tried minicom and saw the incoming Tempo messages from the Axefx! Ah, so the hardware IS good, and thus I started looking at the software side again. It turns out that in more recently Linux kernels you can see custom baud rates in code. Most of the people getting MIDI working on the Pi are doing system config settings. But it's a hack. Using an API to set the speed to the exact right value is way better. Now the existing code snippets kinda get you there, but for me I had to merge the old code and new code to get something that works for me. This is the final result: int MidiHnd = open("/dev/ttyAMA0", O_RDWR \| O_NOCTTY \| O_NDELAY); if (MidiHnd > 0) { struct termios2 tio; ioctl(MidiHnd, TCGETS2, &tio); tio.c_cflag = BOTHER \| CS8 \| CLOCAL \| CREAD; tio.c_iflag = IGNPAR; tio.c_oflag = 0; tio.c_lflag = 0; tio.c_ispeed = 31250; tio.c_ospeed = 31250; ioctl(MidiHnd, TCSETS2, &tio); } The MIDI output was an easy fix: just turn the 4011 logic chip the right way around. And boom: working! Hahaha... in my defense it has a little stamped circle at the other end of the chip. Which is sometimes used to mark the "1" pin. Grrrr. Oh and here is some video showing it working:
(0) Comments \| Add Comment

Got the NeoPixels working
Date: 3/3/2016 Tags: mc2	I've got around to working on the MC2 again. Last I got up to was getting the NeoPixels working and for some reason none of them would light up. To isolate the issue I used the bread board to step the data signal from 3.3v up to 5v. As you can see it works great. Now I know the NeoPixels themselves, and their connections are good I can get to work finding the issue on the peripheral board.
(0) Comments \| Add Comment

Core Text LOL
Date: 3/2/2016 Tags: scribe mac	Sometimes you just have to laugh. I let XCode 7 install. And now I get the choice of the 10.11 SDK or the 10.11 SDK. Apple have finally removed the ATSUI API I was using to draw text in my Mac ports, causing compilation errors. So time to pull out the partially complete CoreText implementation and get that working. Not quite there yet ;)
(1) Comment \| Add Comment

Merry Christmas
Date: 24/12/2015 Tags: scribe linux	I think for the first time ever? There is a simultaneous release of Scribe on 3 different platforms: Windows, Mac AND Linux. The new v2.1.3 build is tri-platform. The Linux (x64) build is a GTK2 app and runs ok on Ubuntu and Arch. Well that's all I've tested at this point. It also runs on a Raspberry Pi 2 although it's a little slow. I know because I got bored and tried building it while working on some MC2 stuff. Links to the i.Scribe builds: Win32 Mac32 Linux64
(0) Comments \| Add Comment