Now mind you, I’m not a graphics guy, so don’t expect too much. Also I notice that some of the renders have aliasing and artefacts; I would create new higher-quality renders but I don’t have a copy of Maya anymore. Nevertheless, they don’t look too shabby if I say so myself :).

The first animation is a recreation of my fan:

See this PDF for a nice step-by-step walkthrough, including a photo of the original. Slightly higher quality avi file here. Maya source file here.

The second animation is of a toy train. This one I created together with Bert:

See this PDF for some details about how the animation is made and some screenshots. Slightly higher quality avi file here.

Now, Roland is also planning to release a software package to edit sounds on the GAIA from your PC, which provides some extra possibilities, however it isn’t out yet and won’t be free.

But I found that Roland has made available a MIDI implementation document for the GAIA, also documenting a protocol to access its internal memory. So what I did is I started working on a little tool that can talk to the GAIA. It’s still in its early stages, but already it exposes some very interesting information. For example, I was able to extract a list of preset patch names — should come in handy!

There are currently two menus to issue commands and a log to show results. The first menu lets you play some test notes and send GM on/off control messages (looks like they just reset the GM though). The second menu is more interesting, it allows you to dump the system settings, as well as the settings of the currently selected patch (including edits). So now you can retrieve the exact patch settings, share them, reposition the controls, whatever!

Some plans for the future are to show the parameters in a little more visually appealing and structured way, and to eventually allow you to edit the parameters. I also want to add the ability to set the tempo to a specific BPM. An editor for arpeggios is also on the wish-list, and also there’s a bunch of reserved memory locations that may have something good lurking in them.

» Download the GAIA tool here

The source code is available. Consider it Apache 2.0 licensed for now, although I didn’t add license headers yet. If you want to contribute please go ahead, but let me know if you do. If you make any changes please contribute them back!

Update: As of version 0.1 it is possible to edit arpeggios, and as of version 0.3 you can organise your patches in a library. A first for the GAIA!

1. Glen Talloch 8 YO Blended Malt
2. The Famous Grouse
3. Glenmorangie Lasanta
4. Glenfiddich 15 YO, Solera Reserve
5. The Glenlivet 15 YO French Oak Reserve
6. Glen Grant 7 YO The Major’s Reserve
7. Tullamore Dew (open)
8. Connemara Peated Single Malt (open)

I’m not gonna do the whole grading thing but having a list of whiskies I’ve tried seems handy. I would use some kind of whisky database website but haven’t been able to find one…

Update: My collection at Whiskybase

http://www.msxcomputermagazine.nl/

They are soliciting the contributing authors to contact them in order to ask for permission to put their articles online. Their email-address is listed on the website.

I think this is a really great initiative, archiving these things is important. I was always already thinking all those magazines in the cupboard were really asking for some scanning :). Also good to hear that Frank and Wammes are involved. I hope they will also put MSX Club Magazines and the accompanying disks online.

It’s a shame that our author’s rights system makes these kind of preservation efforts a really complicated job. If you vote GroenLinks, maybe they will manage to do something about it! :)

But if you ask me, shallow clones aren’t really needed. Aside from being sort of against the point of having a DVCS, you don’t actually gain that much. I did some measurements (on Windows):

• Mozilla-central repository:
  • Files: 41926
  • Repository size: 241 MB
  • Working copy size: 287 MB (87,4 MB zipped)
  • Clone time: 276 seconds (0,8 MB/sec)
• Python trunk repository (going back to 1990!):
  • Files: 4199
  • Repository size: 97,1 MB
  • Working copy size: 55,7 MB (14,8 MB zipped)
  • Clone time: 82 seconds (1,2 MB/sec)
• Mercurial repository:
  • Files: 1144
  • Repository size: 15,4 MB
  • Working copy size: 6,86 MB (2,08 MB zipped)
  • Clone time: 25 seconds (0,6 MB/sec)
• Backbase 4 repository (converted from SVN):
  • Files: 4691
  • Repository size: 77,9 MB
  • Working copy size: 74,6 MB (33,6 MB zipped)
• Backbase cobrowse repository (converted from SVN):
  • Files: 1703
  • Repository size: 79,6 MB
  • Working copy size: 39,3 MB (24,0 MB zipped) (was 87,2 MB 400 revisions ago!)

The repository size is roughly what will be transferred over the wire when cloning. The zipped size gives an indication of the theoretical optimal case where you would retrieve just the files and no history. Note that this does not include metainformation which would also get transmitted with shallow clones — e.g. Python’s changelog is ~10 MB. Finally clone time is the time it takes to do hg clone -U, which skips updating the working directory so is a reasonable approximation of the time spent downloading and creating the repository.

Also of note are some further measurements I did with the Mozilla repository. When I copy it on my hard drive between different disks, it actually also takes a lot of time: 174 seconds! (The Python repository took 23 seconds.) Creating a working copy from the repository also takes a long time, 241 seconds. My guess is that this is likely because of the large amount of small files.

So in other words, even if you would cut the download time of the Mozilla repository by making the shallowest of clones, much cloning time is still spent creating the large amount of small files. A little math suggests that for this repository, you would only be able to bring down the clone time by some 20%.

Conclusion

Looking at these numbers, first of all, in most cases just thinking about how ‘shallow’ you want to clone a repository is probably already going to take more time than to just clone it ;p. And what would you gain? A slightly shorter clone time perhaps, but you lose the ability to look at the full history. And how often do you do a complete clone? Only the first time.

For local clones, Mercurial and git actually create hard links, so making a local clone is much faster (74 seconds Mozilla, 11 seconds Python) and hardly takes any disk space. Clones over a local network will of course be faster as well. And as for slow connections, because in the end the repository is completely hosted locally and few things require interaction with a central server, a DVCS is already very friendly towards those.

Finally, consider also that internet connections get faster every year, so even though repository size grows steadily over time, this does not necessarily have to become a problem. And hey, if it does, by that time Mercurial will have shallow cloning too :).