Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redundant storage of deltas for partials #143

Open
dpwe opened this issue Aug 11, 2024 · 1 comment
Open

Redundant storage of deltas for partials #143

dpwe opened this issue Aug 11, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@dpwe
Copy link
Collaborator

dpwe commented Aug 11, 2024

The partials oscillator stores each set of partial trajectories by a sequence of partial_breakpoint_t elements in partial_breakpoints[]. The last three elements of a partial_breakpoint_t are ms_delta, amp_delta, freq_delta, which are redundant with the ms_offset, amp and freq of the next breakpoint entry for that oscillator (specifically, ms_delta is the increment in the ms_offset, and amp_delta and freq_delta are multiplicative scales to transform the current amp and freq into the next ones).

We could save three fields for each breakpoint entry by, instead, scanning ahead to the next entry for the current oscillator, reading its ms_offset, amp, freq, and calculating the deltas on-the-fly. This would also simplify adding partials, since the partial-construction system would not have to calculate the deltas.

@bwhitman bwhitman added the enhancement New feature or request label Aug 16, 2024
@AntoineDoinel69
Copy link

Would it make sense to also compress the remaining fields to uint16_t fixed-point values too?
It would still be easy to get back to the original floating point values at runtime, with a relatively minor loss of precision.

I mean, something like this:

  • frequency: 8.8 split, where MSB is semitones (same as midi note, but extended beyond 127), and LSB 256ths of a semitone.
  • amplitude: 0.16 no sign and fractional part only (since I presume it's always < 1.0 right?)
  • phase: 1.2.13 with sign, so with a range of -2.0000 to 1.9999 (and still allow for that -2.0 terminator thing)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants