One of the big questions for me to resolve just now is how tightly bound an instance of PixelMapGen should be to an instance of PixelAudioMapper.
We want PixelMapGen to be reusable, i.e., not so tightly bound to PixelAudioMapper as to be inaccessible to other code.
This suggests that PixelMapGen is initialized outside PixelAudioMapper then and passed to it.
PixelAudioMapper relies on PixelMapGen to generate lookup tables (LUTs) that map an audio sample array to a pixel array.
Once PixelAudioMapper has initialized its LUTs, PixelMapGen can be passed to another PixelAudioMapper.
So, should PixelMapGen act like a singleton, where the width and height values and the LUTs never vary, after they are generated? That's the second question.
Take into account that real-time multi-media performance is a goal of this library, so speedups are welcome
This is a major reason for using LUTs and arrays of coordinates, rather then math to update our arrays, map clicks on the image to audio offsets, etc.
LUTs also advance the potential for using OpenGL shaders to run the imaging routines, at some later time.
We also use threading to make interaction and time-dependent events more responsive.
Threading is used when playing audio samples: mouse-clicks are used to find positions in an audio buffer
It seems to make more sense in a multi-threaded environment not to share resources so as not to arrive at conflicts.
Processing overhead in my applications is very low and PixelMapGen instances are only read from, not written to.
Nevertheless, it probably makes sense for each PixelAudioMapper to have its own copy of required LUTs, rather than calling a PixelMapGen instance.
PixelMapGen provides methods to copy its resources, which only need to be calculated once, and they can be obtained at application initialization.
We use more memory by replicating LUTs, but in current architectures that is hardly a problem. In any case, we can also call PixelMapGen if we prefer.
In real-time performance situations, initialing all required resources for the performance up front is desirable, anyhow. Another question: do we want a no-argument constructor for PixelMapGen?
A constructor requiring width and height seems really useful if we're handling bitmaps as one of our arrays.
Generality isn't really lost if a bitmap can have a height (or width) of 1, making it effectively 1D and of any cardinality we want.
Clearly this doesn't work for every generator: A Hilbert curve, for example, has some well-defined restrictions
A Hilbert curve could be initialized with a "depth" argument, so there's an argument for having a one-argument constructor.
If we do this, we need to set local fields first, before calling generate().
Clearly, generate() should be called at the end of child class constructors.
A no-arg constructor allows us to instantiate a PixelMapGen without setting any of its properties. This is potentially a source of problems.
I also can't see any advantages to the no-arg constructor. Delaying initialization is not an advantage for real-time performance. Do it all up front.
One of the big questions for me to resolve just now is how tightly bound an instance of PixelMapGen should be to an instance of PixelAudioMapper.
So, should PixelMapGen act like a singleton, where the width and height values and the LUTs never vary, after they are generated? That's the second question.
In real-time performance situations, initialing all required resources for the performance up front is desirable, anyhow. Another question: do we want a no-argument constructor for PixelMapGen?
generate().generate()should be called at the end of child class constructors.