Logic Pro X bounce time
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.

Tags: logic audio
MC2 April Progress
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:

Tags: mc2
MC2 March Progress
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: Oh and here is some video showing it working:

Tags: mc2
Got the NeoPixels working

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.

Tags: mc2
Core Text LOL

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 ;)

Tags: scribe mac


05/02/2016 1:13pm

Merry Christmas
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:

Tags: scribe linux
Portable OpenSSL for Linux
A year ago I worked out how to make a portable build of OpenSSL for Mac. And now with the imminent release of the Linux build of Scribe I need to do the same with the Linux build of OpenSSL.

After downloading and unpacking OpenSSL I configured it with:
./config shared -DPURIFY
The reason for adding the -DPURIFY #define is to suppress valgrind errors related to uninitialized memory usage.

Once that is built I had a look at the shared object paths with ldd:
matthew@ubuntu:~/Downloads/openssl$ ldd ./ =>  (0x00007ffc0e197000) => /lib/x86_64-linux-gnu/ (0x00007f5c5ab6c000) => /lib/x86_64-linux-gnu/ (0x00007f5c5a7a7000) => /lib/x86_64-linux-gnu/ (0x00007f5c5a5a3000)
	/lib64/ (0x00007f5c5b1c1000)
So it's not portable yet. I initially tried using the chrpath command but it can only modify existing RPATH records. My binary doesn't have any RPATH yet. So that didn't work. The next thing I tried was the patchelf command from here:
After building and installing I issued this command in the OpenSSL folder:
patchelf --set-rpath '$ORIGIN' ./
Now to check if libssl pulls in the local libcrypto:
matthew@ubuntu:~/Downloads/openssl$ ldd ./ =>  (0x00007ffcdce86000) => /home/matthew/Code/Scribe/trunk/./ (0x00007f39b99d8000) => /lib/x86_64-linux-gnu/ (0x00007f39b9613000) => /lib/x86_64-linux-gnu/ (0x00007f39b940f000)
	/lib64/ (0x00007f39ba0a5000)
Yes! Now this build can be installed in the same folder as the Scribe binary and Scribe will use it without interfering with the system OpenSSL which is often out of date, or not built with -DPURIFY or missing.

Tags: shared-object linux openssl scribe
Scribe 2.1
Well it's been most of a year since I said anything about Scribe v2.1, and the list of changes hasn't moved forward much in that time. There are a few reasons for the slow progress, but it mostly boils down to:
Anyway there is some good news. The integration of Aspell is complete. Scribe v2.1 will come pre-loaded with a spell check and it will download and install dictionaries on the fly with no user intervention. Well you'll need an internet connection for that part, but once installed it'll work offline.

Secondly I'm in the middle of doing a fairly thorough rewrite of the Help files. Which includes fixing some things in the HTML rendering. Reviewing all the parts of the application that have "Help" buttons (or should have "Help" buttons) and making sure they work correctly. Updating all the pages with current information. It's actually a big slab of work. Lots of cross referencing things and checking the UI and source code so I accurately describe the functionality. I'm not much of a tech writer so it's tedious for me.

Anyway there is now a beta release online for v2.1. I look forward to getting feedback on what works and what doesn't.

Tags: scribe


03/12/2015 2:37pm
03/12/2015 2:49pm
05/12/2015 3:23am
06/12/2015 4:58pm
08/12/2015 4:28am
08/12/2015 6:54am
08/12/2015 6:19pm
23/12/2015 2:14pm
23/12/2015 8:07pm

MC1 flash procedure update
The original MC1 flash procedure involved having to use an actual parallel port. For this reason I have kept an old PC running XP around. Just to flash the firmware from time to time. As it didn't work so good on Windows 7 or pretty much any Mac. Then a few months ago someone was asking about the possibility of using a USB in circuit programmer like this. So seeing as they are dirt cheap on ebay, I bought one to try out.

Compiling the code into AVR instructions is accomplished with the WinAVR tool chain. I'm using the latest release. However there is one gotcha when installing. Do NOT install it into a folder with brackets in the name, like say:
C:\Program Files (x86)\WinAVR
This causes make.exe to crash. No I'm not kidding.

The next issue is the Avrdude binary that comes with the WinAVR compile is just a little too old to know about the usbasp programmer. So that needs to be updated to something recent. Just unpack that file into the bin folder of the WinAVR install, overwriting the existing avrdude files. Check that the version available on the command line is correct by running it without any arguments.

Next the usbasp needs a driver to work in Windows (7 in my case). You can get that here. I didn't have much luck with the installer, but if you go into the Device Manager, right click on the usbasp device and install drivers from that menu. Then select the folder where you unpacked the drivers. On my machine the device driver takes 10 seconds to connect so give it time before trying to flash the firmware.

Finally the actual command you use to flash the firmware is:
avrdude -c usbasp -p m128 -U flash:w:main.hex
Where 'main.hex' is the compiled binary. It's faster and easier than the old PonyProg2000 method, and scriptable. Just put it in the makefile. Less mucking around.

Now I'll have to find another excuse to have an old PC lying around. Maybe LAN games with the lad? :D

Tags: mc1
Mc2 Progress #4
The time comes to stop mucking around with software and start building the hardware. I'm no where near as good with the hardware things. Software is easy and fine... so how much did I break it? Turns out a fair bit. Lets take a look.

First I started with an Inkscape file that described all the positions of the components and specifically the places where I have to drill or cut. I printed it out in A3 and glued it down to the top surface of the chassis.

I started drilling out the holes and all the switch / neopixel holes went fine. Then came the LED rings and the paper started tearing everywhere.

So I left the LED ring holes for a while and worked on the screen rectangle. I bought this tool called a "nibbler" to cut the hole. You drill a hole in the area to be removed, and insert the nibbler into the hole and start cutting. It can cut in a curve so I used that to align to the border.

Then I came back and finished all the LED ring holes. However my accuracy was terrible and I don't feel all those holes are good enough.

I've decided that this chassis is a bit of a write off. I have since gone and bought a new chassis (they are about $60 AUD inc shipping so not too bad). And now I'm looking for someone that can do CNC drilling.

Moving on I tried test mounting some of the components, starting with the screen and Pi.

Seems to fit quite nicely. So I tried to bend the holes in to accommodate the countersunk machine screws that I had bought. That bent the metal around the hole too much and deformed the chassis around the screen area. In hind sight I should've used a large drill bit instead of mechanical force. So because of the deformations in the metal when I tightened up the screws around the screen I heard a faint cracking sound. Yup I broke the screen just a little.

That's just fantastic! :( Another thing I have to re-order. Similar price too... bah. There is some good news thought... the screen still works:

Although I haven't had a chance to test the touch screen part.

The PCBs and Neopixels need to be mounted behind the front of the chassis, so I went and bought some rectangles of 3mm perspex:

The switches go through the perspex and keep it in place. I've started soldering some 3 wire ribbon cable between the Neopixels, not shown in this photo. It's slow and tedious work :( And the various glue electronics to interface the Pi with the buttons, encoders, expression pedal ports and neopixels is all mounted to that as well.

Tags: mc2
Why are my videos encoding at a snails pace?
I'm currently rendering out composites for a music video and it's crawling along. Vegas is taking 40+ minutes for a 8 minute 1080p video? That doesn't sound right. My CPU is a i5-3570K and the machine has 16GiB of RAM (5 in use right now). So I started looking at the CPU to see if it's running OK. First stop CPU-Z:

2ghz? What? Where is my 3.8ghz the CPU is capable of? Hmpf. Well better check the temps then.

Oh... oh dear. Well... I er... guess I need to replace that stock cooler then huh. Off the shops, will update with results.

Edit: So I cleaned out the fan, it was clogged with dust. Reapplied thermal grease and reinstalled the heatsink/fan. I think it might've come loose and not have been making proper contact with the CPU?

In any case:

At least now I'm getting decent speed. The render time is down to 21 minutes or so. I wonder if I can overclock with a decent cooler?

Tags: hardware
MC2 Progress #3
The last week or so has been spent a twisty maze of fonts, colour spaces, CPU endianess and cross platform C++. Anyway I won't regail you with all the fun I've had but I will show you some screenshots.

Firstly because I have RGB LEDs for each Instant Access switch, I need a way for the user to select a colour:

It remains to be seen how easy it is to use on the real hardware. But colour selection works either by hitting one of the palette entries or pushing the Red, Green and Blue sliders around.

Also for entering details like the CC number and other textual information I probably need a touch screen keyboard:

This is roughly copied off my Android phone's touch keyboard. Without Swype unfortunately ;)

The screen to select a scene change for an IA button:

And the page where the user picks an Axefx block:

Tags: mc2