| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 12 13 14 15 16 17 18 19 20 ... 25 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85 ... 90 ... 95
| Waiting is fun | |
|---|---|
|
Date: 23/5/2011 Tags: axefx | So all 3 packages for the Axefx controllers have "shipped"
but not arrived. Awesome. The last of the packages to ship
was the PCB's which apparently shipped today, although the
tracking number hasn't shown up on the postal system yet.
And I don't know what the shipping transit windows are
either. The 3 boxes, are the footswitches, all the electronic components (inc the AVR stamps) and finally the custom PCB's. I think at one point last week I had 8 outstanding orders, including unrelated stuff from ebay. Things have slipped partly because I took a while to verify the drill lists and images of the tracks, and made some minor changes before the PCB's got made. And partly because the vendor making them took a week longer than they said it would take from when they accepted payment and the final design to when they shipped the boards. While I've been waiting I've started working on a new revision of the PCB that supports a 40 pin IDC connection between the main PCB and the switches / LEDs / expression pots. This is very similar to the setup I used in the prototype but I think I'll end up using it primarily to test complete boards. I'm going to make a test harness that just plugs into the board and lets me test all the functions without having to solder in all the parts directly. Depending on the layout of the final enclosure it might be useful for others as well. |
| (1) Comment | Add Comment | |
| Mac Mini RAM Upgrade | |
|---|---|
|
Date: 19/5/2011 Tags: mac upgrade | I found this guide nailed upgrading the RAM in a Mac mini. Tonight I took out the paltry 1GB and replaced it with 4GB for about $33 AUD. Not bad... not bad ;) The mini runs all the servers (imap, svn, http) in the house, because at 14w it's the cheapest computer to run 24/7. The iMac is 70w at idle, and the PC up around 110w. Yay for minis! |
| (0) Comments | Add Comment | |
| Axefx Foot Controller | |
|---|---|
|
Date: 10/5/2011 Tags: axefx guitar | For the last six months or so I've been building a MIDI foot controller for the Fractal Audio System's Axefx guitar processor. The Axefx digitally models the effects and amps that guitarists use, but on a scale
that hasn't been seen before. For me the main draw cards were great audio quality, the ability to practice and record quietly (I
have kids and neighbors), and very consistent sound quality in a live setting. Something that I couldn't do with my old tube
amps.
The design of my controller is based around an AVR microprocessor built into a stamp that I bought many moons ago for an economy gauge that I never got around to building. I did however build something useful and fun with that stamp. There is a long thread about the various stages in the build process. Which resulted in a plywood prototype that I now use when I play guitar in a live situation every week or two. It allows me access to the important parameters of the Axefx via knobs and switches and displays the current state of the settings and parameters on the LCD. All the software running on the microprocessor is written by me and I developed the support circuit from various information available on the 'net. About a month ago I switched from building this just for my own use to exploring the possibility of building these controllers for others as well. In kit form, or fully assembled. A few people expressed interest on the Axefx forums, so I created a PCB layout and am currently having those printed up (design acceptance and payment happened last friday), I've also ordered enough parts to build 2 controllers up front. The design can be executed in 2 main ways, as a full foot controller, or as an amp controller, with reduced functionality. When I get the boards back from manufacturing next week I'll build at least one for testing the PCB kit out and then I'll be putting the kits and PCB's up for sale on the site. A new hardware section will be created with PayPal links. The software that runs on the AVR chip is written in C and has a high level foot controller portion, and a low level hardware specific layer/API. The foot controller part controls all the functions specific to the axefx, the setup menu and the display of information on the LCD. The device specific layer is responsible for talking to the hardware, and running the main event loop. The design is deliberately separated like this so that you can also run the foot controller software on the PC and Mac, mainly for testing things out before committing it to hardware. It far easier debugging on a desktop computer that way. Surprisingly this works really well. There are no #ifdef's in the high level code needed to make the 2 systems run, and they behave exactly the same. |
| (0) Comments | Add Comment | |
| Const Armageddon | |
|---|---|
|
Date: 7/4/2011 Tags: code | So after getting about 9000 warnings building Lgi with the latest XCode 3.x I
decided that I would do something about it. A lot of the warnings consisted of
"casting from const char* to char* is deprecated" because I was passing a
string constant into a char* arg. So I fix one of those. Which causes 4 more.
And so I fix some more of those, and it snowballs... and snowballs... and then
there is an avalanche of API's getting 'const' all through them. Many days
latter I'm now back on top of the warnings. However now I've modified a
number of base classes with virtual functions that had char* arguments. Of
course the compiler doesn't warn you when your child class stops overriding
the parent function does it! So the big hunt for mis-matched function
definitions begins. No doubt I'll miss some and random stuff will just stop
working, because the base class got the call, not the child class. *sigh*
Update: So after finding most of the problems by bumping into them accidentally I realized that I was going to missing something important anyway. So I wrote a python script that calls ctags to extract a bunch of symbol definitions, then it parses through all those and finds all the class methods, and compares their arguments and return type with the parent classes virtual function, and spits out an error if they differ. This was great, it picked up a few methods I'd missed, and gave me confidence that I could release the next build of Scribe without having broken functionality. |
| (0) Comments | Add Comment | |
| Python Is Awesome | |
|---|---|
|
Date: 7/4/2011 Tags: code python | That is all. |
| (0) Comments | Add Comment | |
| Outlook and that stupid "J" | |
|---|---|
|
Date: 1/3/2011 Tags: email outlook | It seems to be common knowledge that people receiving email from Outlook
users see a capital J instead of a smiley face if they are not using Outlook
themselves. As I've been testing the IMAP behavior of Scribe and Thunderbird
lately I noticed that both clients display Outlook's smiley face as a "J" and
thought to myself, if I have spent so much effort making Apple's Emoji work
that it's only fair that I at least have a look into why Outlook's smileys don't
work. There are a lot of "fixes" out there for the "problem", but I wanted to know the REAL reason why it happens. So here it is; Outlook wraps the smiley in the following HTML: <span style='font-face:wingdings'> J</span>There is the famous J character, but technically that markup is correct, if you open up Word, set the font to Wingdings and type 'J' you get a smiley. So what the hell? Initially I thought maybe my glyph substitution code was getting in the way, but after turning that off for wingdings it didn't help. So I looked at the font creation code and remembering something about ANSI vs SYMBOL charsets I hard coded anything with "wingdings" in the face name to use SYMBOL_CHARSET instead of ANSI_CHARSET when calling CreateFont. Which fixes the problem, Scribe now renders the smiley characters correctly. There you go, now you know. Now I can snicker quietly when Thunderbird renders them as 'J's ;) |
| (2) Comments | Add Comment | |