amaroK VIS_PLAN  - Created: 22-11-2003

Abstract
========

In order to create a visualisation framework that is superior to anything
popular available for Linux today we should plan amaroK's thoroughly
before implementation. This document exists to map out our ideas and is
available for anyone to edit, please, if you have some good suggestion, or
experience with this kind of work, add some comments! Thanks, Max Howell


Formatting
==========

The document has no regimented formatting, but do try to keep the wordwrap set
the same! Feel free to recommend formatting if the document becomes
unmanageable.

Editing
=======

Whatever goes. Please correct my spelling!


Plan
====

My inital thoughts were to make visualisations a separate process rather than
separate thread. The reasoning being, a crash in the vis won't crash amaroK,
threads can be unmanageable, *nix is good for new processes, we can use DCOP to
control the vis and presumable we just need to pass a handle to the relevant
arts server to the vis and leave it. Since the music playing bit is already a
separate process it makes sense to make the visualisation separate too! Also
this may mean that these visuals could be separate from amaroK and just depend
on KDE.

I was also thinking that this means it may be possible to not use Qt to
do rendering. There are probably better libraries for high speed graphics and if
there isn't a way to make DCOP not depend on a QApplication, then maybe we could
write something. It would be sorted if we could make something that can react to
arts sound output in general.

I was also thinking it would be neat to embed the visuals somehow into amaroK,
so as the background in the playlist perhaps (I know, this would probably not
work well due to the need to re-render all the AA text all the time, but still
the idea is neat) This is similar to Sonique on Windows if anyone has ever used
it.

If we make the visualisations not amaroK specific it may be possible to embed
visualisations into the Kicker, onto the desktop, etc.

MCOP seems to be the best way to get the audio data to the visuals. Problem with
current FFT arts implementation is it seems to be stuck at 17 bands, can we
improve this? Do we want more than an FFT of the audio data? Would other data
be useful to visuals at all? Beat detection certainly would be a useful thing to
offer the visualisations, and it would certainly stop every visual implementing
its own detection.

[muesli: FFT is all you need. 17 bands although is a bit few. 32 would be
         desirable, after everything I read and know. Right now I'm expere-
         menting with the vector our analyzer uses. Quite promising up to now. ]

[Comment from muesli, to be integrated into the paragraphs above]

imho, it would be cool to offer this service via sockets. udp would fit per-
fectly, since it has to be realtime, anyways (better loose a packet and show
nothing, instead of a out-of-sync beat). e.g., you would be able to have
various of visualizations-clients connected to amarok, showing different
animations, at the same time. this would also remove the DCOP-dependency-chains
for the OpenGL clients.

right now, i can imagine two implementation methods:

A) transmit the frequency vector of the analyzer to the vis-client. beat-detection and
all that stuff gets done by the vis-client.

B) basic beat-detection and music analysis gets done by amarok itself. the
results of that process are sent to the vis-clients.

<mxcl> IMO it would be good to offer services like beat detection. This
way vis-writers have less to do and are more likely to write a vis since
beat-detection is already done, also it means beat-detection is likely to be better
as we will over time offer a really good implementation, and it means that if the user
has many visuals running, the beat-detection is only done once for all visualisations.

[/Comment by muesli]
