[Clam-devel] Re: [PATCH] (but don't use it yet) scrolling spectrogram in annotator status

[David García Garzón]

I think you messed up it all with vmqt. No need for that. You needed to know 
such code but you are not forced to use it. My idea was to update vmqt 
spectrogram with the texture implementation we were building, not duplicating 
the ill vertex based on the new implementation. Some words on that later.

The scrolling spectrogram has sense on the NetworkEditor. Annotator just needs 
a spectrogram. That means that NetEditor just needs a local view of the 
spectrogram (latest frames) while the Annotator needs a full access to all 
the data (scrollable, of course but not in the sense of local view). Also 
that in the NetEditor we could loose some frames while on the Annotator we 
need to be precise. Translated to code the ScrollingSpectrogram is something 
for NetEditor and can be based on a FloatArrayDataSource which is simpler 
(but loosy!). Annotator needs a new data source, which is a 2D matrix so this 
could be the next step because is a more complex task.

So the first step is NetEditor scrolling but loosy spectrogram. How to address 
it? Take KeySpace code instead the renderer 2D one as starting point. 
KeySpace fills all the texels in a texture acording with an input float array 
data source. Instead the spectrogram must fill just one row with the texels 
with the gradient mapped values of the float array data source. Scroll can be 
performed simply by changing the texture coords assigned to the vertex of the 
single square KeySpace is drawing. All the bounds and the like should be 
provided by the DataSource.

Having an spectrogram monitor in NetEditor is an easier, screenshotable step.

Then it would be nice to refactor vmqt to use such texture based 
implementation, instead of the vertex implementation you duplicated back. In 
vmqt you won't have 'scroll' in the sense we said in NetEditor. The texture 
will be the same, Just taking different partial views of a very large 
textured quad.

After that, let's move to the Annotator we should address how to abstract a 
float matrix array as a data source: units, offsets, gaps, max and min of 
each of the 3 dimensions. Optionally labels in some of them. And raw data.

Also forget about the color choosing code. On future qt versions it could be 
very easy to edit a QGradient as a widget property, so at the moment just 
consider a single gradient and forget the code handling that. Anyway it is too 
verbose for its function.




El Saturday 11 August 2007 00:00:19 bennett kolasinski va escriure:
> Hi David (& list),
> Here's a patch containing what I've been working on as far as scrolling
> spectrogram goes.  It is basically a mashup of Keyspace &
> vmqt/render/vmSpectrogramRenderer... I'm sending it out to make sure I'm
> somewhat on the right track (it compiles and Annotator even will run and
> show a blank GL drawing space where the spectrogram will eventually be!).
>
> Right now I'm trying to figure out how to get the data displayed, and then
> I have to get it scrolling.  The scrolling will most likely rely upon
> playback time information that was being discussed in a thread started by
> Roman the other day-- Roman, if you haven't looked into it yet, I can focus
> on getting time information out of [Mono/Multichannel]AudioFileReaders.
>
> Best,
> Bennett