VIS_PLAN

   1 Amarok VIS_PLAN  - Created: 22-11-2003
   2
   3
   4 Abstract
   5 ========
   6 In order to create a visualisation framework that is superior to anything
   7 popular available for Linux today we should plan Amarok's thoroughly
   8 before implementation. This document exists to map out our ideas and is
   9 available for anyone to edit, please, if you have some good suggestion, or
  10 experience with this kind of work, add some comments! Thanks, Max Howell
  11
  12
  13 Formatting
  14 ==========
  15 The document has no regimented formatting, but do try to keep the wordwrap set
  16 the same! Feel free to recommend formatting if the document becomes
  17 unmanageable.
  18
  19
  20 Plan
  21 ====
  22 My initial thoughts were to make visualisations a separate process rather than
  23 separate thread. The reasoning being, a crash in the vis won't crash Amarok,
  24 threads can be unmanageable, *nix is good for new processes, we can use DCOP to
  25 control the vis and presumable we just need to pass a handle to the relevant
  26 arts server to the vis and leave it. Since the music playing bit is already a
  27 separate process it makes sense to make the visualisation separate too! Also
  28 this may mean that these visuals could be separate from Amarok and just depend
  29 on KDE.
  30
  31 I was also thinking that this means it may be possible to not use Qt to
  32 do rendering. There are probably better libraries for high speed graphics and if
  33 there isn't a way to make DCOP not depend on a QApplication, then maybe we could
  34 write something. It would be sorted if we could make something that can react to
  35 arts sound output in general.
  36 <markey> we could use SDL for 2d and OpenGL for 3d rendering.
  37
  38 I was also thinking it would be neat to embed the visuals somehow into Amarok,
  39 so as the background in the playlist perhaps (I know, this would probably not
  40 work well due to the need to re-render all the AA text all the time, but still
  41 the idea is neat) This is similar to Sonique on Windows if anyone has ever used
  42 it.
  43
  44 If we make the visualisations not Amarok specific it may be possible to embed
  45 visualisations into the Kicker, onto the desktop, etc.
  46
  47 Do we want more than an FFT of the audio data? Would other data
  48 be useful to visuals at all? Beat detection certainly would be a useful thing to
  49 offer the visualisations, and it would certainly stop every visual implementing
  50 its own detection.
  51
  52
  53 Vis Process Architecture
  54 ========================
  55 I suggest having a separate process for each visualization. Each vis process would
  56 only load one visualization plugin. This way we have good crash safety and it's also
  57 possible to develop and ship plugins separately from Amarok. So we have one "vis loader
  58 skeleton" in Amarok, which will be instanciated whenever we need a vis. This loader could
  59 get started with the vis plugin as cli argument. It would also contain all the socket and
  60 interface needed to communicate with Amarok.
  61
  62 We should take care to keep the design as simple as possible.
  63
  64 <mxcl> Why make visualisations plugins as well as binaries? It seems sensible to have
  65 visualisations as separate processes and then communicate with amK through the socket.
  66 Why have the extra layer of plugins if you're going to force each process to only load
  67 one plugin anyway?
  68
  69
  70 Merging Analyzer and Vis
  71 ========================
  72 If we decide on unifying vis and analyzer, the question arises how to get the rendered
  73 bitmap graphic back into Amarok's playerwidget. It seems we have the following options:
  74
  75 * Writing it into a shared memory buffer. Amarok must then read the buffer and bitBlt()
  76   the pixmap into the framebuffer
  77 * Transferring the pixmap over a Unix socket (or UDP network socket). This can amount to
  78   several megabytes per second. After the transfer Amarok must bitBlt() it to the
  79   framebuffer.
  80 * Writing it directly into the framebuffer at the desired position, like a video overlay.
  81   There might be technical problems doing so, and it will be difficult when the user
  82   moves the window.
  83
  84
  85
  86 [Comment from muesli, to be integrated into the paragraphs above]
  87
  88 imho, it would be cool to offer this service via sockets. udp would fit per-
  89 fectly, since it has to be realtime, anyways (better loose a packet and show
  90 nothing, instead of a out-of-sync beat). e.g., you would be able to have
  91 various of visualizations-clients connected to amarok, showing different
  92 animations, at the same time. this would also remove the DCOP-dependency-chains
  93 for the OpenGL clients.
  94
  95 right now, i can imagine two implementation methods:
  96
  97 A) transmit the frequency vector of the analyzer to the vis-client. beat-detection and
  98 all that stuff gets done by the vis-client.
  99
 100 B) basic beat-detection and music analysis gets done by amarok itself. the
 101 results of that process are sent to the vis-clients.
 102
 103 <mxcl> IMO it would be good to offer services like beat detection. This
 104 way vis-writers have less to do and are more likely to write a vis since
 105 beat-detection is already done, also it means beat-detection is likely to be better
 106 as we will over time offer a really good implementation, and it means that if the user
 107 has many visuals running, the beat-detection is only done once for all visualisations.
 108
 109 [/Comment by muesli]
 110
 111
 112
 113
 114 //FIXME <markey> beat detection code temporarily moved here
 115
 116         /*
 117                     // Muesli's Beat Detection - A Night's Oddysee
 118                     // shift old elements
 119                     for ( uint x = 0; x < 18; ++x )
 120                         for ( uint y = 42; y > 0; --y ) m_beatEnergy[x][y] = m_beatEnergy[x][y - 1];
 121
 122                     // get current energy values
 123                     for ( uint x = 0; x < pScopeVector->size(); ++x ) m_beatEnergy[x][0] = pScopeVector->at(x);
 124
 125                     // compare to old elements and get averages
 126                     double beatAvg[18];
 127         //            double beatVariance[18];
 128         //            double beatMood[18];
 129
 130                     for ( uint x = 0; x < 18; ++x )
 131                     {
 132                         beatAvg[x] = 0;
 133                         for ( uint y = 1; y < 44; ++y )  beatAvg[x] += m_beatEnergy[x][y];
 134
 135                         beatAvg[x] = beatAvg[x] / 43;
 136                     }
 137         */
 138         /*            for ( uint x = 0; x < 18; ++x )
 139                     {
 140                         beatVariance[x] = 0;
 141                         for ( uint y = 0; y < 42; ++y )  beatVariance[x] += (pow((m_beatEnergy[x][y] - beatAvg[x]), 2) / 43);
 142                     }
 143
 144                     for ( uint x = 0; x < 18; ++x )
 145                         beatMood[x] = (-0.0025714 * beatVariance[x]) + 1.5142857;
 146         */
 147
 148         // do we have a beat? let's dance!
 149         /*            int total_hits = 0;
 150                     for ( uint x = 0; x < 18; ++x )
 151                     {
 152                         double factor = cos( x * 4 ) * 18;
 153                         factor = beatAvg[x] * factor;
 154
 155                         if ( m_beatEnergy[x][0] > factor )
 156                         {
 157                             total_hits++;
 158                             kDebug() << "*CLAP* factor: " << factor << " - x: " << x << " - average energy: " << beatAvg[x] << " - current peak: " << m_beatEnergy[x][0] << endl;
 159                         }
 160                     }
 161
 162                     if ( total_hits > 3 ) kDebug() << "***CLAPCLAPCLAP***" << endl;
 163         */