On Monday, 5 September 2016 at 05:08:53 UTC, Manu wrote:
A central premise of performance-oriented programming which I've
employed my entire career, is "where there is one, there is
probably
many", and if you do something to one, you should do it to many.
With this in mind, the code I have always written doesn't tend
to look
like this:
R manipulate(Thing thing);
Instead:
void manipulateThings(Thing *things, size_t numThings, R
*output,
size_t outputLen);
Written this way for clarity. Obviously, the D equiv uses
slices.
To chime in, processing in chunks is indeed absolutely key for
audio performance. Processing by element is only tolerable for
prototyping. I don't even use slices since but usually pointers
and length, since most slice length would be the same.
void processSamples(float* input, float* output, int samples);
Some kind of buffered input and output range concept would be
needed there if a lazy library was to be made.
Unfortunately for this case inputs and outputs are rather
diverse. Can't wait for a more formalized DbI introduction.
As for graphics, ae.utils.graphics usually give you a whole line
of pixels.
