Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 ... 50
Date: 16/11/2005
Everytime I open iTunes it askes me to find the files in my play lists. Eh? What you say iTunes? The files are in the same damn spot they were last time. iTunes is teh Suck!

So I thought google will fix this for me. After consulting google (who failed me) I found this. Which sure makes for interesting reading. I want to believe all that crap about the labels screwing the musicians but there are a few little problems with their anti-label rhetoric. Lets see:
  • making music costs money.
  • artists generally need support while writing/recording, that costs money.
  • getting artists "out there" costs money.
  • labels pay for all that, they should get a cut.
downhillbattle don't really get it, they want the muso's to get a better deal and want to screw the labels. But there wouldn't be any "art" if not for the labels. Imagine if you will that Coldplay had no label to pay for their recording and advertising. They'd still be play pubs in the UK, appreciated by a few half-drunk brits.

I know the cost of recording is now a lot lower with the advent of modern gear, but advertising is still a major part of the visibility of an up and coming artist. A great artist with no money is not going to connect with many people by selling direct over the 'net. They don't produce fantastic recordings because of budget issues, and even if they leap frog that issue they don't get seen by anyone. Labels still have a part to play, and they shouldn't be cut out of the picture.

That said I would think twice about signing up with a label. As a muso myself I would try and go with a small independant label that wants to spend very conservatively and has their head screwed on straight.
(0) Comments | Add Comment

Mac Mini DVI Pinout?
Date: 15/11/2005
There already exists a converter for the Mini (and Powermac) that gives you Composite Video and S-Video out of the DVI port. But it means you can't have the main display plugged in as well. The adapter is not doing any signal conversion, just exposing the right pins in the DVI cable as an RCA jack and an S-Video jack. But what pins would those be?

So my devious mind went to work, and I see no reason why you couldn't (in theory) have a pass-through converter that exposes the composite and S-Video signal AND the DVI signal. So you can have BOTH tv-out and your main display happening at the same time. Niiiiiice!

But from my reading of the DVI interface specification (pinouts) there is no "composite video" or "s-video" pins, just analogue RGB and sync. So dear reader, what exactly is the pinout on the Mini, something different?

If given half a chance I'd like to try cobbling up a Composite & DVI adapter up from scratch. Hopefully short of buying the Apple adapter and ripping it apart to see how it's done.
(2) Comments | Add Comment

If msdev.exe crashes on startup then...
Date: 9/11/2005
... read this. Basically it comes down to deleting the registry key HKCU\Software\Microsoft\DevStudio\6.0\Layout and things will return to normal. Microsoft Visual C++ v6 was crashing every time I tried to start it. Even after a reboot and cleaning of the process list. In my case the crash address was 0x77f57ec4 / 0x00140000. This might help someone, somewhere, sometime...
(0) Comments | Add Comment

i.Mage Update
Date: 26/10/2005
Today I updated i.Mage for the first time in 11 months... yeah I've been slack I know. The new build brings with it a number of UI fixes, bugs squashed and speed improvements. Most telling is I finally got rid of that horrible select/paste tool and made it just a select tool, retasking the brush tool to actually paint with the brush. So now I think it'll match most users mental model of how a paint application should work.

Strangely enough I came to the realisation of just how bad the UI in this area was because I was re-writing the help file to explain the usage correctly. And I just couldn't bring myself to explain this quirky select/paste behaviour in the help file, so I had to rewrite the app to match the help.

It's an interesting way of going about it, writing the help and then making the application comply, but it certainly did highlight a few things for me. An exercise worth doing if you write software. If something is hard to explain in the help then maybe it's just not user friendly enough, and you need to fix your app rather than spend many paragraphs explaining it in the help.
(1) Comment | Add Comment

iTunes Australia
Date: 25/10/2005
Well after my previous rant about the iTunes Music Store (US) I thought it was only "fair" if I checked out the new Australian iTunes Store.

The only things I wanted to know are:
  1. Does it have various obscure local bands that I like?
  2. Is it fast?
  3. Does it let me pay with PayPal?

Short answer: don't know, NO and NO!

Long answer: I tried finding some songs I wanted and well so far the page hasn't loaded after 5 minutes so I have no idea if the catalogue is any good. It's slow. In fact it's so slow it makes dial up look positively snappy. I think they have employees that read the incoming HTTP requests out, and someone writes it down, walks over to the library catalogue of songs they have... works out the search results, writes it down, hands it back to the data entry employee (there is just one, who is really busy) who then types up the results in HTML and sends it back out the 300 baud modem to me. It is faster to find and download a song over p2p than it is to see if ITMS even has the song. There is a 6 letter word for that.

And no ITMS Australia does NOT support PayPal like the US store, because... because... uh I have no idea why. Theres a freakin' PayPal Australia site and everything!
(2) Comments | Add Comment

User Interface Code-fu
Date: 21/10/2005
Note: This is aimed purely at coders, so don't get too worried if it doesn't make any sense.

Background: In the world of programming user interfaces it is common to have an object wrap each user interface element (window), which virtual methods that trigger when various things happen, like "OnMouseClick" and "OnPaint". These methods are implemented by the application to add functionality to the base controls provided by the application framework. In C++ these are virtual member functions in the parent C++ window class.

Ideally the code inside these event handlers, as implemented by the specific application, would take minimal time to run and be generally well behaved. But in reality it sometimes needs to do a lot of work in the event handler and can do nasty things like delete the current window object processing an event. So I'm getting to grips with this in Lgi and I've come up with a reasonably neat solution.

Firstly for the issue of long running event handlers, you often want to know that the handler "hung" for a while. This is reasonably easy to check, just take a tick count at the start, and another at the end and work out the milliseconds the handler ran for. If it's over some threshold you can change the post event handler behaviour. I do this in the list control when the application puts up a right click menu and "hangs" the event handler. Normally I trigger a timer to check if the user has started a drag and drop operation, but if the handler hangs, a d'n'd operation should NOT be started.

The second issue is the one of the event handler destroying the window during it's processing of the event. Now you could setup a complicated system of return values on the events to indicate whether the application has deleted the window, but that is prone to error because it puts the responsibility on the application to "Do The Right Thing(TM)". I'd prefer a system that doesn't require any smarts on the application side to work correctly. So I came up with a better way (And sorry if it's obvious). Basically the problem with the current object being deleted during the event handler is that you can not access any of the member variables or methods after the event handler. However anything on the stack is still fair game, and I use this fact to get notification of the objects destruction. e.g. my code to call the event handler now looks like this:

bool DeleteFlag = false;
this->pDeleteFlag = &DeleteFlag;
if (DeleteFlag)
this->pDeleteFlag = NULL;

I have put a pointer to the delete flag in the object so that in the destructor of the object I can return information of the destruction event to some interested party (i.e the event handler calling code furthur up the call stack):
    if (pDeleteFlag)
        *pDeleteFlag = true;
    // other stuff....
This way if the event handler deletes the object, the flag on the stack gets set, and I can trap that AFTER the event handler has returned and the current object no longer exists. Nice, neat and robust.
(0) Comments | Add Comment