Oops... okay, after some very helpful chatting w/ David on IRC this morning, I'm refocusing on NetworkEditor and Keyspace.  Here's a 1st patch that copies Keyspace in NetworkEditor into a new Spectrogram class. Actual spectrogram functionality coming shortly :)
<div><br class="webkit-block-placeholder"></div><div>B<br><br><div><span class="gmail_quote">On 8/12/07, <b class="gmail_sendername">David García Garzón</b> <<a href="mailto:dgarcia@iua.upf.edu">dgarcia@iua.upf.edu</a>
> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I think you messed up it all with vmqt. No need for that. You needed to know<br>such code but you are not forced to use it. My idea was to update vmqt
<br>spectrogram with the texture implementation we were building, not duplicating<br>the ill vertex based on the new implementation. Some words on that later.<br><br>The scrolling spectrogram has sense on the NetworkEditor. Annotator just needs
<br>a spectrogram. That means that NetEditor just needs a local view of the<br>spectrogram (latest frames) while the Annotator needs a full access to all<br>the data (scrollable, of course but not in the sense of local view). Also
<br>that in the NetEditor we could loose some frames while on the Annotator we<br>need to be precise. Translated to code the ScrollingSpectrogram is something<br>for NetEditor and can be based on a FloatArrayDataSource which is simpler
<br>(but loosy!). Annotator needs a new data source, which is a 2D matrix so this<br>could be the next step because is a more complex task.<br><br>So the first step is NetEditor scrolling but loosy spectrogram. How to address
<br>it? Take KeySpace code instead the renderer 2D one as starting point.<br>KeySpace fills all the texels in a texture acording with an input float array<br>data source. Instead the spectrogram must fill just one row with the texels
<br>with the gradient mapped values of the float array data source. Scroll can be<br>performed simply by changing the texture coords assigned to the vertex of the<br>single square KeySpace is drawing. All the bounds and the like should be
<br>provided by the DataSource.<br><br>Having an spectrogram monitor in NetEditor is an easier, screenshotable step.<br><br>Then it would be nice to refactor vmqt to use such texture based<br>implementation, instead of the vertex implementation you duplicated back. In
<br>vmqt you won't have 'scroll' in the sense we said in NetEditor. The texture<br>will be the same, Just taking different partial views of a very large<br>textured quad.<br><br>After that, let's move to the Annotator we should address how to abstract a
<br>float matrix array as a data source: units, offsets, gaps, max and min of<br>each of the 3 dimensions. Optionally labels in some of them. And raw data.<br><br>Also forget about the color choosing code. On future qt versions it could be
<br>very easy to edit a QGradient as a widget property, so at the moment just<br>consider a single gradient and forget the code handling that. Anyway it is too<br>verbose for its function.<br><br><br><br><br>El Saturday 11 August 2007 00:00:19 bennett kolasinski va escriure:
<br>> Hi David (& list),<br>> Here's a patch containing what I've been working on as far as scrolling<br>> spectrogram goes.  It is basically a mashup of Keyspace &<br>> vmqt/render/vmSpectrogramRende
rer... I'm sending it out to make sure I'm<br>> somewhat on the right track (it compiles and Annotator even will run and<br>> show a blank GL drawing space where the spectrogram will eventually be!).<br>>
<br>> Right now I'm trying to figure out how to get the data displayed, and then<br>> I have to get it scrolling.  The scrolling will most likely rely upon<br>> playback time information that was being discussed in a thread started by
<br>> Roman the other day-- Roman, if you haven't looked into it yet, I can focus<br>> on getting time information out of [Mono/Multichannel]AudioFileReaders.<br>><br>> Best,<br>> Bennett<br><br><br></blockquote>
</div><br></div>