Hello all!

I promised this new release for the end of the last year, but I delayed it a bit due some changes in my professional and personal life.

Anyway, basically this release is about bug fixing and performance improvement. It’s using less power now, and playing faster.

If you want to try this version, you can get the package here.

And bugs reports are always welcome, and needed ;)

ps.: I’m still trying to upload it to OVI, lets see…

Beat Maker is my “pet project” with Allyson Soares at INdT.

It is, basically, a drum loop emulator to be used by musicians during practicing sessions.

You just need to select the samples, define a BPM value and listen to the rhythm ;)

If you can’t wait for the official release at Ovi Store, you can try the beta version for n900 devices.

Remember: it’s a beta version of an open source software. The code can be found linked to my gitorious account.

The technical point of view:

I’m a little bit disappointed with phonon. After a long discussion I’ve realized that phonon could not be used on Beat Maker.

At this time I’m using an approach suggested by Adriano Rezende: play the sound using pulseaudio’s API. I know, it’s not portable. But hey, my target is N900 devices and it worked pretty well at the time.
However, it doesn’t scale. So, now, I’m working on a kind of “in-app-mixer”, which should solve this problem.

There is another problem, related to QTimer. Qt can’t guarantee the timing between the beats using QTimer events. Especially when you generate mouse events. Anyway, the mixer controller loop should solve this as well.

Big thanks to Adriano for the tips, and Allyson who made the excellent UI design.

I hope you enjoy it.
Suggestions are welcome =)

ps.: youtube video bellow

With a little help of Ademar, we’ve selected a good use case: a bouncing game.

The game

The flags

The flags I want to comment on this post are:

• QGraphicsScene::ItemIndexMethod
• QGraphicsView::OptimizationFlags
• QGraphicsView::ViewportUpdateMode

The results

* Those tests were performed on a Nokia 5800, type RM-356, with V51.0.006 firmware and Qt 4.6.3.
** The Y axis is measuring FPS: the higher, the better.

10 elements on the screen

First of all, I’ve tried the four ViewportUpdate methods, with 10 items on the screen, and the MinimalViewportUpdate and the SmartViewportUpdate gave me the highest FPS( 34 and 33.5) . Qt documentation shows NoIndex as the best option for dynamic scenes… well, the difference is small for few items, but it’s true =)

So, for the other tests, lets use the NoIndex flag.

What about optimization flags?

I took two results from the latest test (SmartViewportUpdate and BoundingRectViewportUpdate) and ran it again with two optimizationFlags: QGraphicsView::DontSavePainterState and QGraphicsView::DontAdjustForAntialiasing. So, optimizations flags brings us a little bit of improvement when we can control precisely how the items will be drawn.

20 elements

30 elements

40 elements

Lessons Learned

It’s important to select the correct ViewportUpdate method for your kind of scene. It can make the difference.

If there is a lot of dynamic elements, and if they are scattered throughout the scene, it’s cheaper to paint the whole screen (or, at least, the bounding rect) instead of trying to determinate the affected area.

To be honest I was expecting a better result from FullViewportUpdate, but I believe it would be better than BoundingRect if we use non-static background.

What if?

What if I use only one graphicsItem to paint all the balls? What if a ball was not an item but an object with a render method?

I got a little bit surprised, it wasn’t the result I was expecting – it’s worst. It only gets to be better when I put more than 60 items on the screen.

Will I throw the code in the garbage can?

No! As the result of the tests and with a creative help of Nara – INdT designer – I’m releasing a playable alpha version of this game, called by Chubba-Lubba. It’s not finished, since it’s still missing the icon, sounds and scores features, but it’s testable =)

Symbian package here!

When we started to develop symbian applications at INdT we, as open source developers, decided to find a way to keep using linux as our development environment.
On the beginning we didn’t have yet an official way to compile our applications on linux, so we used (and still use) Lizardo’s patchs that enables gnupoc to compile Qt-symbian applications on Linux.

First tip:

Personally I think finding errors on gnupoc output is an exhaustive job. So, the first tip for those who’re using Lizardo’s approach is to use a small piece of code in your .bashrc

function makes60
{
  make debug-gcce 2>&1 | while read line
  do
    echo -e $(echo $line |
      sed 's@\\@\\\\@g' |
      sed "s/.*error.*/\\\e[0;31m(&)\\\e[0;31m/I" |
      sed "s/warning/\\\E[33m(&)\\\E[0;37m/gI" |
      sed "s/No such file/\\\E[33m(&)\\\E[0;37m/gI"
      )
  tput sgr0;
done;
}

By calling makes60, every error/warning message will be highlighted in read/yellow.
It's a simple tweak, but it is very useful.

So, we can compile our application, easily read the compiler messages... Now what?

Analyzing the process:

Let me list our development phases:

• Coding: OK with vim
• Compiling: OK with gcce and some tweaks
• Debugging: (As we work almost only with default Qt API, we build for linux first and debug there). So, it's almost OK.
• Packaging .sis: OK with make sis
• Send to device, install and test: It's a slow process yet.

Testing on the device is a very difficult/slow task on linux. We don't have a debugger. We don't even have any output message (Ok, we have: with stdioserver writing on an txt file. Too hard!).

How does it works for Windows developers? Carbide++ and TRK!

Of course we don't want to install Carbide++ on linux. So, can we use TRK with linux? Yes, we can! First of all you need to get the TRK application in Carbide++ package or in newly released Nokia SDK.

Installing TRK:

1. Send and execute TRK.sis on the device.
2. Open TRK application / Options / Settings,  and select Connection = USB instead of bluetooth.
3. Go to TRK mainscreen / Options / Connect.

If your USB cable is plugged you will receive a "Status: Connected" message on your phone.

Now you need to create a serial connection between the device and your linux machine. If you're using a 2.6.33 kernel you don't need to do that. Otherwise you need to create it manually.

Before you do that you need some information about the device. It can be retrieved with:

[danilo@docbrown ~]$ lsusb  | grep Nokia
Bus 001 Device 011: ID 0421:0154 Nokia Mobile Phones

So, my vendor ID is 0421, and my product ID is 0154.  Remember to use your own numbers =)
And then you can load the usbserial mobule with the command:

sudo modprobe usbserial vendor=0x0421 product=0x0154

If everything went OK you should see a message like this:

[danilo@docbrown ~]$ dmesg | grep ttyUSB
[34063.949446] usb 1-4.3.1.4: generic converter now attached to ttyUSB0

Your serial port was created on /dev/ttyYSB0.

Ok, perfect! But how to communicate with TRK?

Trolls are working on that, but for now we’re using the runonphone tool. It’s the same tool used by QtCreator on Windows and you can get it by cloning Qt Repository and compiling the /tools/runonphone folder.

On device testing

After compiled, runonphone can be used by passing the serial port, the sis package and the executable file to it.
runonphone -p /dev/ttyUSB0 -s test_package.sis test_package.exe

As you probably noticed all your qWarning() messages are being redirected to runonphone output. Which is very nice!

On device debugging

We don’t have an interative gdb tool as we have on windows, but Qt guys are close and I’m sure we will have good news in a few days.

Concluding

I’m sure that Symbian development on Linux is near, and it will be massively adopted when those tools became part of QtCreator for linux. For those who can’t wait, or think that VIM is the best IDE ever, I hope those tips can help you. =)

And for those who’re working with Qt for symbian, remember to join the #qt-symbian on Freenode.

When I was trying to pairing my keyboard, I could see that Su-8W is a pre-configurated keyboard, and with a little of patience, I dicovered the file who manages this: /usr/share/X11/xkb/symbols/nokia_vndr/su-8w.

With 5 minutes by reading this file you can be familiarized with file syntax. And, with 10 minutes, you can note that THERE IS NOT A LAYOUT DEFINITION FOR PORTUGUESE/SPANISH. So, now I know why the Portuguese layout doesn’t work =).

But, Ok. Lets try to fix it.

If I select portuguese layout, and there is no portuguese layout, I assume that it’ll use us-intl, right? But, in the begining of the intl definition exists a anoying comment: “I can’t belive! It’s not intl”. Hummm…

Lets ignore this, and go on… What do I need? Dead_keys in `,~,",',^, and ç when I press “ALTgr + c”.

I’ll not explain all the changes I did (it’s not too much, just 4 boring lines), is easier to download and replace the old file by this one, or see the diff. [ADVISE: DO NOT FORGET TO BACKUP THE OLD FILE]

And Voilà, Accents and Cedilla working like a charm.

The right workaround for it is create a valid portuguese layout, but just for testing proposes you can alter the intl layout.

Ok, that is it,

Cheers!