🐛 [Earwurm] Various bug fixes

[beefchimi]

This PR addresses many issues / feature-requests for the project.

Resolved issues

• Fix node process not quitting while running tests #23
  • Fixed with latest vitest.
• [Sound] Add speed accessor #30
  • The speed accessor now works as expected.

Consumer facing changes

• Fix issue "stopping" a Sound that was never "started".
  • Now manually triggering #handleEnded when a Sound has never been played.
• Include a neverStarted: boolean; property in the SoundEndedEvent.
• New volume change event for Earwurm, Stack, and Sound.
• New mute change event for Earwurm, Stack, and Sound.
• New library change event for Earwurm.
• New queue change event for Stack.
• New speed change event for Sound.
• speed Setter now clamps the value between 0.25 and 4.
• New progress change event.
• New progress Getter.
• New state > ending value.
  • Can be used to distinguish a manual .stop() vs a natural "end".
• Renamed all statechange events to state.
• No longer setting mute = false when "pausing".
  • This avoids triggering the new mute change event.
• Avoid re-initializing an existing Stack when .add() is passed an identical id + path.
• Removed LibraryKeys type, instead using StackIds[] directly.
• Now exporting tokens object with some usual values.
• Updated docs/api.md to include details on all the newly added / changed code.

Project development changes

• Updated various project dependencies.
• Various test changes.
• Consistent use of async tests.
• New PrimitiveType.
• New utilities: arrayShallowEquals, assertNumber.
• New helpers: linearRamp.
• Simplified some utility arguments.

Known bugs

• We appear to end up drifting from the "current play position" and the "progress" when:
  • Sound is looping.
  • Speed is adjusted multiple times.
  • Thoughts:
    • Could be that playbackRate is not a direct "value multiplier" as we thought.
      • Worth investigating the topic of "audio time stretching".
    • Could be that the small gaps between UI and the capture of currentTime is the problem.
    • Could also be that I've made a mistake in my math.
  • Questions: Would detune produce a different result?
    • We would need a way to convert cents into a "multiplier" (or however the progress math works out).

Future tasks

• Update examples.md to include some of the new features.
• Apply transition to speed linear ramp.
  • This will complicate the progress calculations... but maybe it is as easy as:
    • If slowing down: subtract half of transitionDuration.
    • If speeding up: add half of transitionDuration.
• Investigate an async emitten.
  • Currently, we have an issue where we are not executing all of the ended subscriptions, as empty() appears to not allow any queued events to execute.
  • Perhaps we just need to pass empty an option for executeQueue?

Considerations

• Maybe we offer a linearRamp() method on Sound to allow custom changes over time?
  • This would perhaps make the transitions feature obselete?
• Consider a way to toggle transitions while Earwurm is already initialized.
  • We would need to allow a Getter/Setter.
  • Not sure how exactly this will influence Sounds that are already "prepared" and/or "playing/paused".
• Consider a "global setter method" on Earwurm and Stack that allows syncing prop values.
  • Something like earwurmManager.setAll('speed', 1.25).

[changeset-bot]

🦋 Changeset detected

Latest commit: de9c61d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
earwurm	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR