Should `MetaOscil` have used only one `Oscil`?

[tomcombriat]

and swapping between tables of similar length instead of swapping between Oscil?

The issue #293 made me think of that even though the problem is not exactly the same. Swapping between tables might incur a slight increase of performances (not need to align the Oscil on swap) and of memory.

Unfortunately that would break backward compatibility (except if we make MetaOscil friend of Oscil so that it can grab only the pointer of the table and make its way with it).

Opinions? Worth it?

[eclab]

MetaOscil has a number of memory inefficiencies that really hurt the Arduino.

• All the tables are typically the same length (certainly as provided in the Mozzi libraries), even though a wave of twice the frequency needs half the table size. If the tables varied in length, we could create MetaOscil oscillators with about twice as many tables in the same memory space, dramatically reducing aliasing or reducing memory consumption by a lot.

• Oscil objects consume enough dynamic RAM that it's really hard to use very many of them without running out.

• It seems that Oscil objects (not the tables, the objects) also consume some degree of flash, which also reduces my available space.

Permitting variable length tables and using just one Oscil per MetaOscil would help quite a lot in terms of memory in scenarios, such as the 328, where it's very limited.

[tomcombriat]

a wave of twice the frequency needs half the table size. If the tables varied in length,

Indeed, but is that possible without sacrificing performances? Oscil are templated classes, hence oscillators with different length table are different types, do you have an idea how to make that to work in a single MetaOscil (resorting to a "masterOscil" class, from which every Oscil would inherit, would probably have quite some performance problems as the type of the Oscil being worked on would need to be resolved at runtime, not compile-time).
Suggestions very welcome as always!

Oscil objects consume enough dynamic RAM that it's really hard to use very many of them without running out.

There have been discussions about changing some of the Q16n16 of that class to Q0n16` (see #244 ) but not done yet (or tested for that matter). It is a fairly light class though so that might not be a huge difference but indeed every bytes counts. The change proposed in this issue might help a bit also.

---

Permitting variable length tables and using just one Oscil per MetaOscil would help quite a lot in terms of memory in scenarios, such as the 328, where it's very limited.

The former might incur some performance difference, but if you find an efficient way to do that a PR is very welcome! The second indeed would save a bit of space by removing all the internal variables of Oscil which are duplicated in a MetaOscil. I record that to you this change might be worth it! Thanks for the feedback.

[eclab]

This seems like a C++ architectural Mozzi design choice rather than a performance issue. Rather than include length as part of the template, surely one could have just defined tables (inside Oscil) to be structs of the form { length, type_templated_data* }. My C++ foo is poor but multiple times I've been bitten by the templating, particularly when trying to make arrays of Oscils etc...

[tomcombriat]

This seems like a C++ architectural Mozzi design choice rather than a performance issue.

Well, this class is not templated out of misplaced pedantism, but for performances so that part of the member functions of Oscil are computed during compilation.
Having for instance ((OSCIL_F_BITS_AS_MULTIPLIER*NUM_TABLE_CELLS)/UPDATE_RATE); (l. 197 of Oscil) calculated at runtime would incur a performance drop which might not be acceptable on small platforms.
Also having NUM_TABLE_CELLS changeable would also incur a memory penalty (this has to be stored somewhere…).
Finally, this would break backward compatibility on a object which is quite used by some people I assume ;).

That being said, nothing prevents you to define your own MetaOsc with different table sizes and changing on the fly in a more custom-made oscillator.