<< >>
justin = { main feed , music , code , askjf , pubkey };recent comments
[ present ... 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 ... past ]
July 28, 2010
freeform jam with brennewtjoshnoj

July 25, 2010
freeform jam with chr

July 23, 2010
freeform jam with chrwiener

July 21, 2010
newtbrenjosh - 1 -- [82:17]
newtbrenjosh - 2 -- [51:16]

July 19, 2010
freeform jam with newt

July 13, 2010
Buggy fmod() with Visual C++ 2005/2008 targeting x64

I am posting this in case anybody debugging something needs to find it -- I did find mention of it on some Java related site, but nothing conclusive. This may affect VC2010, too, but I haven't tested it.

While VC 2005/2008 targeting x64 generates SSE code for floating point code, fmod() still uses the x87 FPU, and more importantly it assumes that the divide by 0 exception flag is clear going in (meaning if it is set prior to the call, the call will throw an exception or return #.IND regardless of the input). Apparently they assume that since the compiler won't possibly generate code that would cause the divide by 0 floating point exception flag to be set, then it would safe to assume that flag will always be clear. Or it could be a typo. If you use assembly code, or load a module compiled with another compiler that generates x87 code, this can be a huge problem.

Take this example (hi.cpp):

#include <stdio.h>
#include <math.h>

extern "C" void asmfunc();

int main() {
  return 0;

and hihi.asm (compile with nasm -f win64):


global asmfunc
  fstp st0

Compiling this (cl.exe hi.cpp hihi.obj) and running it does not print 1.0, as it should.

The solution we use is to call 'fclex' after any code that might use the FPU. Or not use fmod(). Or call fclex before fmod() every time. I should note that if you use ICC with VC200x, it doesn't have this problem (it presumably has a faster, correct fmod() implementation).


July 12, 2010
brennewtjoshnoj - 1 -- [20:50]
brennewtjoshnoj - 2 -- [38:08]

July 6, 2010
balls at 102

July 2, 2010
chrwienerschwa - 1 -- [4:40]
chrwienerschwa - 2 -- [4:30]
chrwienerschwa - 3 -- [4:12]
chrwienerschwa - 4 -- [4:45]
chrwienerschwa - 5 -- [5:12]
chrwienerschwa - 6 -- [5:34]
chrwienerschwa - 7 -- [5:47]
chrwienerschwa - 8 -- [3:56]
chrwienerschwa - 9 -- [2:48]
chrwienerschwa - 10 -- [7:08]
chrwienerschwa - 11 -- [5:06]
chrwienerschwa - 12 -- [6:51]
chrwienerschwa - 13 -- [6:10]
chrwienerschwa - 14 -- [3:06]

June 30, 2010
freeform jam with brennewtfritznoj

June 19, 2010
freeform jam with 100623-newtbrennoj

June 14, 2010
brennewt - 1 -- [79:16]
brennewt - 2 -- [23:24]

June 8, 2010
freeform jam with newt

June 7, 2010

We've just released a new piece of open source software for Windows, called LICEcap! It allows one to create animated screen captures. I know, there's a lot of software out there that does this already, but none of them are both free and meet my needs, so we made LICEcap.

LICEcap has a nice UI (in that you position/size the window where you want to capture, and can move it around while recording). We support writing to .GIF directly (big thanks/credit/blame to Schwa for getting the palette generation working as well as it does), as well as to a new format called .LCF.

LCF compresses by taking a series of frames, say, 20 frames, and then dividing each frame into slices, approx 128x16px each. Each slice is then compared to the same slice on the previous frame, and (if different) encoded directly after the previous frame. zlib is used to remove redundancy (often slices don't completely change from frame to frame, i.e. scrolls or small updates will compress very well). This is all done in 16bpp, and the end result is quite good compression, and lossless (well, 16bpp lossless) quality. REAPER supports playing back the .LCF files, too. The biggest down side is high memory use during compression/decompression (20 frames of 640x480x16bpp is about 12MB, and for smooth CPU distribution you end up using twice that).

I should mention that the primary reason for us making this tool was the desire to post animated gifs of new features in REAPER with the changelog. Hopefully we'll follow through on that.

On a related note, tomorrow (or soonish), I plan to post my latest additions on how to make OS X applications not perform terribly (new one: avoid avoid AVOID CGBitmapContextCreateImage() like the plague. HOLY CRAP it is bad to use). Apple: please, for the love of God, either make your documentation a Wiki, or hire someone who actually writes (multi-platform) applications with your APIs to write documentation.


June 4, 2010
newtbrenbiderman - 1 -- [49:31]
newtbrenbiderman - 2 -- [33:59]

May 26, 2010
freeform jam with brennewt

May 25, 2010
freeform jam with chr

May 24, 2010
freeform jam with chr

May 22, 2010
freeform jam with chrtodd

May 19, 2010
this is the best movie i've ever seen


May 19, 2010
freeform jam with brennewt

May 15, 2010
brenchrnewtbiderman - 1 -- [87:25]
brenchrnewtbiderman - 2 -- [13:54]

May 12, 2010
Perhaps I am influenced by the design of rocket engine nozzles?

1 Comment

May 7, 2010
One pitch to go


May 5, 2010
The memory of Winter.


May 5, 2010
The rain is coming

1 Comment

May 5, 2010
freeform jam with brennewtnoj

May 1, 2010
wiener - 1 -- [5:52]
wiener - 2 -- [6:32]
wiener - 3 -- [8:42]
wiener - 4 -- [7:11]
wiener - 5 -- [10:03]

April 30, 2010
random iPhone notes fingerings from a plane

ca 1995, near Prescott: idle, on a rock, among the pines, at the foot of granite. the smell of trees and sap and pine needles, the warm sunshine and cool shade all comfort. having forgettable conversations with companions, names forgotten or not important, whose paths will diverge as inexplicably as they crossed. only good feelings remain.


April 25, 2010
The funny/sad thing about releasing software is...

...if your test/beta/etc period is more than a few days, it doesn't matter how long it is, within 24 hours of releasing you'll almost always have brought to your attention a few very ugly bugs that need to be fixed. Sigh...

It makes me want to release things even more often.


April 14, 2010
freeform jam with newtchrtodd

April 12, 2010
freeform jam with chr

April 11, 2010
Dear Intel,

I've just read this article about your experimental 48-core CPU. Can I mention that our software, REAPER is highly multi-core optimized, and we'd love to see how it runs on / can be improved for 48 cores?


Justin Frankel
Cockos Incorporated

P.S. We have REAPER running on Linux, too. Don't tell our users though, or they'll start whining (you know how Linux users can be).


April 10, 2010
freeform jam with newttombren

March 31, 2010
freeform jam with brennewtnoj

March 24, 2010

The best quote I've heard in a long time* (from a NYMag article):

    "Stumptown offers the best of the best. I'm not saying it to be arrogant, I'm saying it because it's a true fucking story."
I've found that agree with him.
* Allison actually read it to me many months ago, and it has stuck with us both ever since


March 20, 2010
wiener - 1 -- [3:31]
wiener - 2 -- [3:32]
wiener - 3 -- [5:39]
wiener - 4 -- [4:01]
wiener - 5 -- [5:42]

March 12, 2010
software patent news


Here's hoping the supreme court does something good. Fingers are crossed.

1 Comment

March 9, 2010
newt - 1 -- [13:04]
newt - 2 -- [13:26]
newt - 3 -- [4:54]

March 4, 2010
eeePC 901

I got a while back this ASUS eeePC 901, with a 1.6ghz Atom and 20GB of SSD. When I first got it I upgraded the RAM to 2GB, and installed Windows XP. It wasn't that great, so then I tried Win7 pro on it, which almost worked, but would just freeze for lengths of time for no apparent reason. The keyboard is tiny and has a very different arrangement from what I'm used to. It sat idle for a while, and since I have been developing on Linux (hello, SWELL/generic), I decided to install Ubuntu on it. The new verdict:

I love it. It's reasonably fast for compiling, installing new stuff is easy (apt-get ftw), Firefox w/ flash is fine, Xchat is decent enough, the stock mail client is very usable. The best part is that the battery life is fantastic, the screen is bright, there are very little moving parts, and it feels really solid. Yes, a bit like a toy, but I'm not worried about breaking it. Anyway, I'm fully on board with the netbook thing. Maybe next time I'd get one with a slightly larger keyboard, though...

Oh yeah and the other part of what I'm saying is: I'm definitely appreciating where Linux distributions for the desktop have gotten. Almost there... ;)

March 4, 2010
which reminds me: strict aliasing

I get that the "strict aliasing" optimization of recent C/C++ standards allow for great optimization. And I get that gcc has some anciently-designed optimizing, but at any rate, it annoys me that gcc will detect strict-aliasing violating code, and still go ahead and generate code that is obviously wrong -- i.e. when it knows that two pointers ARE in fact pointing to the same memory, it assumes that they can't possibly, and optimizes as if they don't. LLVM probably doesn't have the same problem, heh. Oh well I'll use -fno-strict-aliasing and meanwhile go through and use unions (and occasionally C++ templates) to make our stuff compatible with strict aliasing optimizations.

Of course, on performance sensitive code this is a huge time sink -- I ended up (on our anti-denormal code) looking at the output of many iterations of the same code on gcc i686, x86_64, vc6+icc10, vc2005+icc10, icc11 on osx, gcc ppc, etc, to try to find source code that worked properly and produced decent assembly code. The variety of code produced by each combination is staggering. Also, I found that often the code I thought would be fastest was not, when benchmarked. Oh well.


February 22, 2010
Ideas vs Execution

A better delivered post of something I've been telling people for years -- that execution is way, WAY more important than ideas. Yes, the ideas still need to be reasonable, but beyond that, it's how you do what you do that counts.


February 18, 2010

February 17, 2010
freeform jam with brennewtnoj

February 7, 2010
freeform jam with chr

February 4, 2010
The mighty iPhone vs the Nokia n900

After seeing a slashdot post about people running OS X on the Nokia n900, I read some more info about the n900. It seemed like great hardware, and was debian-linux based, so it seemed like a good platform to play with. Enticed, I found it on Nokia's site, complete with a 14 day return policy.

I should mention, I have/use an iPhone 3GS. Apple ends up pissing me off to no end, but I really end up liking the 3GS. It's a great phone/browser/apprunner/notetaker/calendar/ipod/etc. If it wasn't locked down so tight, I would like it even more. So really I end up disliking the idea of the iPhone, but liking it in reality.

The n900 is pretty much the opposite -- the idea is great. Having a phone I can ssh into and install g++ and make on and build stuff and run on, is great. On paper, everything's there. This is what I found:

  • Screen: the screen looks good. It's high resolution, but the touch sensitivity of it isn't great, it ends up feeling clunky.
  • Storage: on paper it has 32GB of flash. This is great. What's stupid is that the root fs is only 256mb of NAND memory, and while you can install extra packages via apt-get etc, if those packages aren't carefully designed, it ends up filling your root filesystem. Even the obvious things like making /var/cache/apt point to the big disk, they could do, but haven't. So basically you have to do one of many hacks if you wish to install much. The biggest thing I found was moving various /usr/[share|lib|bin]/xxx directories -- all stuff nonessential to booting -- to the bigger disk and symlinking them. Anyway, it's dumb that you should have to do this. Complete pain in the ass. I eventually got everything I wanted installed, but if the point is to have an open extensible phone, you gotta make it do that out of the box.
  • WiFi: support seems solid. When the phone is sleeping, you can still ssh to the phone (if you installed OpenSSH, which is easy). RAD.
  • SSH: awesome. Fast, the thing really feels quick. It is 600mhz, and for command line linux that is super fast. I remember my P133 being quick, too.
  • Web: the browser is pretty solid, and flash support kinda works (wasn't really fast enough for YouTube, but there seems to be an app for this).
  • Keyboard is usable. Better than the iphone's, for me, but not fantastic either.
  • No AT&T 3G support. I don't care whose fault it is, but come on?!.
  • Camera: quality was decent. The video recording was pretty good, sound seemed better than the iPhone 3GS's. Here's a youtube video we did as a test (apologies for the content).
  • General UI: Some things are super fancy (nice blurs, transitions), but other things are not even half baked. There's a nice standard for "close window" or "go back" button locations, but 90% of the time the buttons for those are not visible, yet if you click them they are there. Silly stuff.
  • Multitasking. Mmmm. so good. I like. Hear that, Apple? It's not even a pad...
So I sent the thing back. It didn't last 24 hours. The dealing with root fs, I could get past that. The lack of AT&T 3G support, that made the decision easier. I really tried. I wanted to like it.


[ present ... 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 ... past ]
search : rss : recent comments : Copyright © 2020 Justin Frankel