wavepot / wavepot Goto Github PK

The Service Worker integration currently is problematic. Updates to the sw.js often need the user to unregister the worker manually, something is going on.

Task: Investigate and resolve Service Worker problems for a better user and developer experience.

import sound from 'http://www.w3schools.com/html/horse.mp3'; for example.

Child of #4.

Now that we have successfully integrated low level WebMIDI seamlessly in wavepot (simply by changing the export name to live, and passing the CC values to the dsp function, we need to develop an abstraction that will translate the CC to the more useful float formats (0..1) or (-1..1) to be used in the context of wavepot dsp functions.

The Virtual MIDI Keyboard is a valuable tool for this, as we can setup Knobs and Sliders to test various interfaces, even more weird such as the Pitch Bender (which uses 127 CCs multiplied by the 127 values to achieve a 16384 size precision granularity (-8192..+8192), which we need to translate to a float (-1..1) so it's easily usable in the dsp functions.

An abstraction layer therefore is needed, changes will probably need to take place in the webmidi project and the wavepot project with the worklet.

Develop an abstraction over WebMIDI with the minimum interface possible.

The end user API in the wavepot context should allow for something like this (TBD):

import note from './lib/note/index.js'
import MIDI from './lib/webmidi/index.js'

export async function dsp () {
  // open MIDI input controller number 1, listen to channel 0 (all channels)
  const cc = new MIDI(1, 0)
  return t => {
    // input from our MIDI continuous controller number 10, i.e a note (1-128)
    // is fed to our our note() function to generate hz for the sine function
    return Math.sin(note(cc(10)) * t * Math.PI * 2)
  }
}

Integrate AudioWorklet (realtime) functions to be played alongside regular dsp block functions. Find a way to differentiate through the two.

Code that implements this lives in a POC version of wavepot and simply needs to be extracted and integrated to current version.

This will allow also for realtime inputs from WebMIDI to be applied to synths and effects, rather just than the block loop ableton-live-like mode that is the current implementation of wavepot dsp functions. API should be identical to block-loop functions so they are interchangeable, with some kind of differentiator (TBD) for the engine to consume.

Develop a Spatial Storage server to store and query grid points with specific precision and a limited maximum area, plus a client in JS to interface with it, preferably with regular HTTP endpoints and fetch().

Items stored are simple key:value types where key is a 2d grid point in x,y, i.e: 15231,42123 and the value needs to be a string of arbitrary length. Example API:

const result = await grid.put('15231,42123', 'foobar')

Queries take the form of bbox (bounding box) with coordinates of left,top and right,bottom, and should return all key:value pairs. Example API:

const points = await grid.bbox('10,10', '20,20')
console.log(points)
// { '12,13': 'foo', '15,16': 'bar' }

Bonus API to fetch a single value:

const value = await grid.get('12,13') // 'foo'

Helpful resources:

• Redis Geospatial
• RethinkDB Geospatial
  RethinkDB has the feature of changefeeds which allow for live updating of values to be streamed to the client. This can be helpful when multiple people are editing multiple grid points in the same view so we can maybe utilize this feature.

Develop a mechanism for WebGL visuals to be generated in wavepot code.

A good starting point is hydra-synth, and particularly its composable glsl functions that mount to regl - the only issue is that the licensing is AGPL in hydra-synth and that can be a blocker, but we can still borrow ideas, or ask @ojack for a relicensing of simpy the gl functions (which I believe are also picked up from the internet and their original licensing is not AGPL).

There is no code in the wavepot.com repository and the website appears to be broken.