# HG changeset patch
# User Chris Cannam
# Date 1176726027 0
# Node ID d2ffb480ff33460b9f73c2f22d4a3cb1ef7b3f01
# Parent  b36895bda65222c48a271a35140519aa64018b8e
* Experiment with sizing the property stacks and using a frame on the overview
  widget with an eye to making the default empty window look a bit nicer

diff -r b36895bda652 -r d2ffb480ff33 data/model/FFTModel.h
--- a/data/model/FFTModel.h	Fri Mar 30 17:16:48 2007 +0000
+++ b/data/model/FFTModel.h	Mon Apr 16 12:20:27 2007 +0000
@@ -19,11 +19,37 @@
 #include "data/fft/FFTDataServer.h"
 #include "DenseThreeDimensionalModel.h"
 
+/**
+ * An implementation of DenseThreeDimensionalModel that makes FFT data
+ * derived from a DenseTimeValueModel available as a generic data grid.
+ * The FFT data is acquired using FFTDataServer.
+ */
+
 class FFTModel : public DenseThreeDimensionalModel
 {
     Q_OBJECT
 
 public:
+    /**
+     * Construct an FFT model derived from the given
+     * DenseTimeValueModel, with the given window parameters and FFT
+     * size (which may exceed the window size, for zero-padded FFTs).
+     * 
+     * If the model has multiple channels use only the given channel,
+     * unless the channel is -1 in which case merge all available
+     * channels.
+     * 
+     * If polar is true, the data will normally be retrieved from the
+     * FFT model in magnitude/phase form; otherwise it will normally
+     * be retrieved in "cartesian" real/imaginary form.  The results
+     * should be the same either way, but a "polar" model addressed in
+     * "cartesian" form or vice versa may suffer a performance
+     * penalty.
+     *
+     * The fillFromColumn argument gives a hint that the FFT data
+     * server should aim to start calculating FFT data at that column
+     * number if possible, as that is likely to be requested first.
+     */
     FFTModel(const DenseTimeValueModel *model,
              int channel,
              WindowType windowType,