There's a huge amount of work to do yet, but still we're making big
steps towards a really nice application.
In this post I'll try to tell something about its features (in a more technical way).
CarMa is built towards low-end hardware, but still with all modern features
and a responsive and eye-pleasing user interface.
It is ready for multi-core cpu's. Most parts are split up into background
threads already. This allows the CarMa framework to scale up seamless
to high-end hardware and make use of it efficiently.
I'll sum up a couple of my own design and coding-rules to clear up a couple
of design related-questions ahead:
keep the UI responsive (user should have the highest priority, instead of the OS f.i.),
try to keep the software low on resource/memory usage and don't fear technical
workarounds to optimize slow implementations..
The core manages all subsystems like audio, database,
skinning, external events, file- and imagecache and more. It is based
on a plugin-like architecture, which allows us to change, replace or
extend certain parts easily.
The core doesn't handle external (dll) plugins as of yet. We haven't started
coding this part. Also, there's no external API yet. These are planned
for a later version, shortly after launch
The application allows total freedom of skinning.
A skin contain a bunch of images (PNG preferred due to alphablending),
and a bunch of XML files to describe the individual screens and popups.
Images can be any format, although the preferred format is PNG.
Each object is a separate layer, all blended nicely with each other.
It can render 100's of layers without any noticeable performance loss.
Individual layers are updated if changed only.
The skin-developer has the option to use truetype or bitmapped fonts.
Bitmapped fonts are drawn faster but fixed sized,
TrueType fonts are scalable and support anti-aliasing but slow to draw.
Note: The documentation of the available objects will be found on our Wiki pages after launch
CarMa is completely based on scripting. If a skin doesn't contain any scripts,
it won't run either. It will probably show a nice picture, but it doesn't take
We've chosen for a lightweight script interpreter based on very
simplistic Pascal language. It can process scripts simultaneous and fast.
Don't worry, it is really simple and easy to learn. Scripts to perform basic
actions will be single commands anyway.
Almost all aspects of CarMa are accessible through scripting.
Volume/sound control, file handling, GPS handling, playlist control, etc.
Note: scripting documentation will be found on our Wiki pages.
CarMa supports GPS's out of the box. It enables skins to use the
realtime GPS parameters to update screen controls.
Only serial and NMEA based GPS devices are supported.
Most consumer GPS devices output NMEA,
and almost all of the USB-based devices provide a virtual COM port to use.
You probably shouldn't worry.
Note: multiple apps accessing a single GPS device is a problem.
When an application does, it locks the COM-port exclusively.
No other application can connect or use it.
There is a solution, however. XPort can be used to share a
single GPS device to multiple applications.
This is probably one of the most complex parts of CarMa.
Due to our experiences with some of the popular front-ends,
we had a couple of important requirements. To name a couple:
it has to be crash-proof, redundant, auto-recovery,
fast loading/saving/indexing, must support huge amounts of data, etc.
We evaluated and tested a handful of database engines, but in the end,
We chose memory-tables, and implemented the extra requirements.
The DB is fast, extremely compact, secure and crash-proof.
If there's a power-outage, an application crash or a Win-crash,
no data will be lost- and will resume from the last state before the crash.
CarMa provides a couple of filters to browse through the music collection.
These filters allow the user to browse the library in a logical way - Via ID3 tags
E.g.: by artists, by albums, by genre or year, etc.
No-Tec already wrote some about the playlists.
These playlists are user-selected or dynamically chosen by the system.
If the user wants, CarMa can try to select music based on the listening
statistics and ratings.
As you can see, a lot of work has already been done, but a lot of work
still needs to be done. In the end, it will be a very nice addition to
your CarPC we think!
And of course we're open to questions and suggestions!
We are more than happy to answer them.
Suggestions and requests can be left at the other topic.
Thanks for your patience!