slurmulon / gig Goto Github PK

We need to be able to nest intervals that process collections of elements. For example:

@Time = 4|4

:Scales = [
  2 -> Scale('C Lydian')
  2 -> Scale('G Ionian')
]

:Chords = [
  2 -> Chord('Cmaj7')
  2 -> Chord('Gmaj7')
]

!Play {
  :Scales
  :Chords
}

In the Set ({}), the :Scales and :Chords will overlap and will be played at the same time.

In the nested List ([]), each Chord or Scale will be played for 2 measures at a time using their own contextual/internal timers.

The simplest way I know to do this is to introduce a recursive "context" abstraction.

This will also require changes to bach, such that Sets can be defined without a duration value.

I just renamed this module to bach-player, but I realized that this is annoying for development (always have to tab for the project name) and also makes it ambiguous what platform this player actually applies to (default is JS, but not everybody would know that).

I've concluded that it's better to give the project a more generic and abstract name than a straight forward one.

gig means a band performance, while gigue is a lively piece of Baroque music, which Bach wrote a lot of.

gig is unsurprisingly taken on NPM (we could just scope to an organization or something), but gigue is awkward to pronounce (like "jeeg")

Right now only List collections (i.e. sequential) are supported.

We need to also support Set collections, where each Element is played asynchronously.

https://github.com/slurmulon/bach#beats

We first need to first support translating a time position in a track (e.g. 00:30) into the closest beat and measure cursors.

We then need to calculate the size of the interval at the beat and measure cursors. The size of the interval will be offset by the difference between the standard/default interval and the time remaining until the next interval.

More formally, if C is the timestamp found at the seeked position, E is the scheduled/expected invocation timestamp of the next interval, and R is the amount of time remaining (in ms) until the next interval, then:

R = E - C

Right now the timer backing juke is not sufficient because it is prone to drift (it's based on setInterval, or rather a modified version of it that tries to remain accurate but doesn't really work).

The timer found in heartbeets may be more accurate than stateful-dynamic-interval because it is using the requestAnimationFrame feature of modern browsers.

We may also want to try worker-timers as well, since it spins up instances of setInterval and setTimeout in Web Worker scripts and can run in parallel, therefore improving the accuracy.

• https://github.com/arjunmehta/heartbeats
• https://github.com/chrisguttandin/worker-timers
• https://github.com/turuslan/HackTimer

We need to support Rest elements.

This actually might work already due to how the module is written, but at the very least this needs to be verified + tested.

Instead of accepting audio as an argument to the Track constructor, we should instead parse bach's @Audio header, automatically following the URL to the audio bytestream and loading it into memory.

This does not have to initially support streaming audio, although it does sound like a useful feature for the future.