picture home | pixelblog | qt_tools

omino code blog

We need code. Lots of code.
entries for category "mac os x"
David Van Brink // Tue 2009.01.6 08:55 // {levity mac os x}

This, just in


tuck into cheek, do not swallow

oh, i dont know. what do you think?


David Van Brink // Sat 2008.07.26 23:41 // {mac os x}

qt_tools 2.7 works on Leopard

Executive summary

qt_tools 2.7 corrects some incompatibilities with Mac OS X 10.5, “Leopard”.

Quick recap

qt_tools is my set of free command line tools for recompressing and examining QuickTime movies. And it got broke by Mac OS X 10.5.

Pointless details

So, somewhere along the way, Apple made a strange and subtle change to their process launcher. The affect on qt_tools was to break its --dodialog feature, which is a command-line switch to show the QuickTime export settings dialog.

Tonight I finally sat down and tracked it down. Don’t ask how I figured this out, it was all pure intuition, and I couldn’t tell ya. But it’s like this.

If the existing command line tool qt_export is placed in two subdirectories named Contents/MacOS then the dialog behaves correctly. If the directory names are changed by a single character, then the dialog has a “stuck behind” bug.

This has the disturbing (to me) implication that the OS’s process launch code actually looks at the full path to the executable and… does something… different… based. on. the. spelling. I do not approve.

But I’m happy to offer the updated qt_tools 2.7.


Postscriptum. In previous OS versions the same bug manifested, and was cured by adding a zero length ‘carb’ resource. In 10.5, the presence or absence of ‘carb’ seems to have no effect.


carb resource dialog got stuck behind carbon application leopard mac os x 10.5 broke my tool dialog remained inactive hidden dialog xcode make

2 comments
Daniel Jalkut // Sat 2008.07.26 23:5111:51 pm

Nice detective work! You’re a true hacker, David :)

David Van Brink // Sun 2008.07.27 07:477:47 am

Current mood: “grr”
But this ain’t LJ. :-)

oh, i dont know. what do you think?


David Van Brink // Sat 2008.04.19 01:03 // {mac os x}

MIDI Interlude

I’m still working on the USB MIDI controller comma a device comma retro. But during the debugging process I got distracted by the need to see, clearly, what MIDI values were being produced by the device.

And then there was the pesky interruption of, as we say, “The day job.” It’s usually pleasant enough, a corporate setting where I’m paid to write bugs. But from time to time it catches up, and I find that I have a night job… of fixing bugs. (Thankyou thankyou, I’ll be here all evening.)

Anyway, between this and that, I wrote such a tool. Here’s a screen capture of Omino Midigram, a Mac OS X MIDI visualizer and diagnostic tool.

midigramDemo.mov

click for
http://dvb.omino.com/blog/content/2008/midigram/midigramDemo.mov

It’s written using Apple Core MIDI, and the Trolltech Qt application framework, open source edition. I have to say, the Qt framework API is really, really good. And you know I’m picky about my API’s. This one is nice. Learning c++ wasn’t even difficult with their API. (Although a few years of Java experience may have made it easier than the last time I tried that.)

Omino Midigram can be downloaded here.

oh, i dont know. what do you think?


David Van Brink // Thu 2008.04.17 23:22 // {audio mac os x}

qt_tools 2.6 eats MIDI, tiny rev

I received a question from a qt_tools user asking, How do I convert a MIDI file to an audio file?

Curiously, although I worked at Apple for rather a few years focused on that particular problem, I’d never thought of using qt_tools that way. Turns out it’s easy if you specify the correct exporter, but I went ahead and added that into its “built-ins”.

qt_tools 2.6 will convert a MIDI file to AIFF with a command like:

$ qt_export this.mid that.aiff

Also shows the poster frame’s time in qt_info, as per a user request.

[[get qt_tools 2.6]]

oh, i dont know. what do you think?


David Van Brink // Mon 2007.12.10 00:04 // {mac os x}

qt_tools universal binary

I’ve just posted a universal binary build of qt_tools. No feature changes.

Download latest version here.

Yeesh, those differing Endiannesses sure can be annoying! Here’s a handful of development notes and observations, of interest only to deep geeks and search engines.

1. QTAtom data appears to always be big-endian. So inserting or extracting data must always be done endian-aware.

2. Here’s a nice little endian checker:

#define WE_LE ((*(short *)"12") == 0x3231)
// Evaluates to "true" on a little-endian machine, "false" on big-endian

3. I much prefer to write packing code which is unconditional, using the arithmetic properties rather than the known in-memory layout. This function packs a long to big-endian, on either flavor host.

OSErr nr_insert_deep_atom_long(QTAtomContainer ac,char *path,long long_of_data)
{
    unsigned char bytes[4];
    // pack bytes big-endian, as per qt_atom-ness.
    bytes[0] = (long_of_data >> 24) & 0xff;
    bytes[1] = (long_of_data >> 16) & 0xff;
    bytes[2] = (long_of_data >> 8) & 0xff;
    bytes[3] = (long_of_data >> 0) & 0xff;
	return nr_insert_deep_atom_data(ac,path,4,bytes);
}

4. I had some floating point code which changed behavior for the Intel build! Seriously! In some cases, double x; (some math); x = floor(x); x -= floor(x); would result in x being slightly non-zero, but not on the PPC build. Tricky, but easy to fix with an appropriate threshold.

5. Apple’s compiler is nifty. You can just say gcc -arch ppc -arch i386 to get universal objects, binaries. But can this be true: universal binary files have mandatory resource-fork contents? I just noticed that Fetch applies Stuffit compression during upload.

6. Wow, -gfull sure is important for debugging, but it changed the size of my complete machine-built release site from 5MB to 30MB! No symbols for release builds, thanks.

7. Automated tests! I cannot stress this enough. I have a little Perl test suite that exercises qt_tools’ features externally, and checks the results. Without that, the whole porting from big-endian to bi-endian would have been… much more than a weekend’s work. Having the basic feature-set nailed down by the tests means I don’t have to try to remember what the darn product is supposed to do! Just like you wouldn’t rely on manual builds — gcc, link, copy, whoops — that is, you use a Makefile, it’s nuts to rely on manual testing.

oh, i dont know. what do you think?


David Van Brink // Sat 2007.09.29 15:21 // {mac os x}

QT_Tools Version 2.4

http://dvb.omino.com/sw/qt_tools/

What is QT_Tools?

QT_Tools is a set of command line tools for Mac OS X for compressing and converting QuickTime movies and other QuickTime compatible files. What else is a “QuickTime compatible file”? Almost every standard image and audio format is QuickTime compatible. The main app in QT_Tools, qt_export uses QuickTime to easily convert between these formats.

Here are some examples.

# Resize a movie's width to 100, letting height scale appropriately
    qt_export originalMovie.mov newMovie.mov --size=100

# Resize a movie's rectangle 80 x 80, using Motion JPEG A
    qt_export originalMovie.mov newMovie.mov --size=80,80 --video=mjpa

# Extract the audio track of a QuickTime movie to a .wav file
    qt_export originalMovie.mov theSounds.wav

# Convert a PDF file to a JPEG file
    qt_export doc.pdf docPicture.jpg

What’s new in Version 2.4?

The “new” features for 2.4 are particularly unspectacular, because they are each about making qt_export work more like the way it obviously should. But in case you’re a user of previous versions, here’s what’s new:

  • qt_export. --size=width[,height]. for movie conversions, you can set the size on the command line
  • qt_export. Automatic choice of exporters. QT_Export will recognize many file extensions and “do the right thing”. For example, qt_export foo.wav foo.m4a will convert an audio file to AAC. Similarly, qt_export foo.png foo.tga will convert an image file to Targa format.
  • qt_info. Shows the frame rate. QT_Info now includes “media average sample rate” for each track.
  • qt_export. Image sequences bug. Previous versions of qt_export would get confused importing image sequences if any part of the path included numbers. Now, only the last digits found in a file name or path are used. (Thanks to Chris Perry for submitting that fix.)

Development Notes

I only work on this product very occasionally, usually because I need to use it for something. So it’s important that I have the process as streamlined as possible, to take best advantage of my meager available time.

When it’s time to do an upgrade, I scan my email folder for “qt_tools. Much of the correspondence is minor assistance to users. Some of it is feature requests. And a few are very specific bug reports, some with source-code patches included. So I decide which of these requests and bugfixes should get rolled in.

The utilities which comprise QT_Tools produce output which is specifically formatted to be reasonably parseable. Here’s an abridged example:

poly@thunderbird3 ~/junk: qt_info sweep.aif 
+                 movie name : sweep.aif 
+             movie duration : 2.000 (1200/600) 
+                 movie rate : 0.000000 
...
+          movie track count : 1 
+
+                track index : 1 
+                   track id : 1 
+      track create/mod time : 3273921828 / 3273921828 
+              track enabled : yes 
...
+              media handler : soun/appl Apple Sound Media Handler 
+         media data handler : alis/appl Apple Alias Data Handler 
+    media description count : 1 
+         media sample count : 88200 
+  media average sample rate : 44100.00 
+               sound format : twos 16-bit Big Endian 
+              bits/channels : 16 / 2 
+              sampling rate : 44100 

This helps a lot with integration to a production workflow (qt_tools gets used a lot in video and web production environments, and the odd animation project), and also for my own testing.

When I build the whole thing, this is what happens:

  • Bumps the build number
  • Builds binary tools
  • builds man pages
  • Executes a Perl-based test, with about 100 assertions about what should happen
  • Constructs of a disk image file
  • Constructs of the latest web site for the product

You can see how streamlined that is! No futzing about with web editing at the last second, it’s all part of the build. And all under the same source tree.

One fun bit of trivia: The man pages are all Perl files with POD markup. There’s no Perl code there, but Pod2Man was the easiest man-page-formatter I could easily find. It’s usually already installed. And I use Pod2Html for the automatically-built web site, and Pod2Text to provide the built-in –man option that each utility supports.

Caveats

It is not yet compiled for Intel. The source code is included with the product, and I’ve heard that it compiles and runs adequately, but, tragically, I’m still G4 based in my development. Soon, soon.

I actually don’t know if command line tools will run in interpreted mode on Intel Macintoshi…

OK. I guess that’s all. New version. Go get it.

1 comments
Daniel Jalkut // Sat 2007.09.29 17:575:57 pm

I LOVE qt_tools. I use it rarely but when I need it, it fits the bill perfectly. Thanks a lot for the continued work on this project.

oh, i dont know. what do you think?


David Van Brink // Sat 2007.09.8 13:53 // {mac os x}

Mac OS, X-Platform?

Drooling Fanboy

On the whole, I try to confine my “industry punditry” to lunch room and bathroom stall chitchat. But I’ll indulge in the filthy habit of going in public with it today because… Oh, there’s no real excuse, is there?

And, both because and despite my 10 year tour of duty at Froot.Com — 1988 to 1998 — I am still, of course, a drooling Apple fanboy.

I’ve been mentally composing this for a while, but a recent remark on Dan Jalkut’s red-sweater blog jogged me to set fingers to keyboard.

A Prediction

I predict that Apple will release something along the lines of “Cocoa For Windows” in the next couple of years.

Circumstantial Nonevidence

Yellow Box.

Some years ago, NeXT had a product known as “Yellow Box” which allowed NeXT applications to be compiled for Windows. I know this all too well, because I worked for a company which had — before my arrival — built their entire product on it, but essentially couldn’t ship it because of the licensing fees incurred. “Yellow Box” was the informal name of “WebObjects”, which had something to do with making server-based web applications… or something… but had the handy side effect of supporting existing NeXT application source code.

So what I’m saying is: The technology to execute Cocoa on Windows essentially exists… or did exist until recently.

X86.

Now that Macintoshes use Intel’s x86 CPU architecture, the temptation to run Windows apps and Mac OS X apps is ever greater. Dual-OS and virtualization solutions are nifty and all, but running everything under one OS might be tidier.

Safari & iTunes & QuickTime Player

The fact that Safari, iTunes, and QuickTime Player are all available on Windows demonstrates that some trailblazing work has been done along these lines, with modern (post-NeXT (ha ha)) Cocoa. Part of QuickTime includes a fairly substantial port of Carbon (Mac OS Classic) to Windows; it is possible the QuickTime Player and iTunes still use that. But Safari is almost certainly a Cocoa-based app.

Sell Software?

Apple has a pretty impressive catalog of application software these days. Between the “Pro” audio and video apps (Logic, Final Cut suite) and the consumer apps (iLife, iWork) it seems like there could be some business in selling software.

The iPod and Beyond

And of course, to provide ever-better integration with Apple’s revenue-important personal hardware products (iPod, iPhone, i-what-next?) they’ll continuously expand the desktop integration for them. Eventually there will be a feature that doesn’t make sense to wedge into iTunes!

What’s In It For Apple?

What’s the current market share for Apple personal computers these days? Something like, maybe, 5%? One could imagine them pursuing some of the other 95%, and that other 95% boots Windows. (Minus a sliver for Linux and other such geekly pursuits.) To target that market, they’ll have to ship a machine (an option, certainly) that boots Windows. And, within that market, they could leverage two advantages: Beautiful design, and every existing Mac OS X application.

Implications

All of the above implies that this “Cocoa on Windows” feature could be confined to Apple hardware, and/or Apple software. It’s hard to see any benefit to Apple to letting non-Apple Cocoa apps run on non-Apple hardware. Perhaps they’d license Cocoa-Box to end users, or to other PC manufacturers, or to Cocoa software developers. Or make it free, for the greater glory. Software is a strange, strange beast!




“30 years of personal computer market share figures”
from ars technica

4 comments
Daniel Jalkut // Sat 2007.09.8 15:123:12 pm

I’m not so optimistic. In fact I think I shouldn’t use the word optimistic, because I’m not sure I’d even really WANT our software to be able to run on Windows. It seems exceedingly unlikely that the overall user experience could be high without all the fancy integration points that Mac OS X provides.

But in the short term, check out Cocotron if you haven’t seen it already.

David Van Brink // Sat 2007.09.8 17:205:20 pm

“It seems exceedingly unlikely … fancy integration points…”

On the other hand: it’s amazing what a large well-funded team can actually create and get to work, when called upon to do so.

That is, if Steve said Do It, it’d get done. For example.

I feel your yuck, though.

Daniel Jalkut // Sat 2007.09.8 20:018:01 pm

Yeah – I guess if Steve wants to bring all the “integration points” along … :)

Steve // Mon 2007.09.17 20:238:23 pm

Steve says: Apple is a hardware company. Whatever it takes to sell more hardware, they will do. Right now they are busy with the huge fight they have on their hands fending off the pending loss of iTunes usage (and therefore, iPod revenue) as content owners seek to regain their cut.

And besides, I want LESS software, not MORE.

oh, i dont know. what do you think?


David Van Brink // Mon 2006.10.16 20:45 // {audio c code mac os x}

Core MIDI and Funny Noises

The Sound

midiOutStarter.mp3

click for
http://www.omino.com/snd/midiOutStarter.mp3

The Code

Here’s a super simple plain-old-C file that uses Core MIDI on Mac OS X to send random notes to all the channels:

/src/c/midi/midiOutStarter/midiOutStarter.c in new window download /src/c/midi/midiOutStarter/midiOutStarter.c to file hide /src/c/midi/midiOutStarter/midiOutStarter.c

And here is a Reason setup with some various cute sounds used for the MP3 above.

Huh?

Oh… I write MIDI software so infrequently these days that I need to keep around a starter-app, to remember how it’s done. Perhaps someone else might happen upon this example and benefit. Meanwhile, at least I know where to find it.

2 comments
Daniel Jalkut // Tue 2006.10.17 07:457:45 am

Very cool sounding. Sort of reminds me of some Harry Partch pieces I heard back in school. That might be a naive interpretation of “random notes” – but … all the same :)

w of wbl // Wed 2007.08.8 07:067:06 am

are you saying that nearly 100 years of electronic music can be summarized by this one piece of software?

oh, i dont know. what do you think?


/\/\/\/\

(c) 2003-2011 omino.com / contact poly@omino.com