npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@vveb-audio/core

v0.0.1-alpha

Published

A library on top of the Web Audio API for creating and rendering virtual audio processing graphs

Downloads

2

Readme

vveb-audio 🧛🎶

I vvant to make a virtual audio processing graph

Requirements

  • NodeJS (see the .nvmrc file for version)

Project Goals

This is a very new project, so there is a lot of groundwork to be laid.

The primary goal is to provide a library that allows a developer to create and manage a virtual audio processing graph.

This is built on top of the Web Audio API, essentially providing a state layer directly above it, similar to a virtual DOM.

The virtual audio graph should be easily serializable to JSON, so a configuration can be sent or stored as plain text data.

This should follow the rules of the Web Audio API, such as "A source node can take no input."

An indirect aim of this project is to enhance the Web Audio development experience with TypeScript, providing types not supported natively that can enforce rules and provide more specific type narrowing, such as the categorization of AudioNodes into kinds source, destination, and effect.

This library should be fully extensible with custom AudioNode subclasses created by its users.

Code Practices

  • All source files should be written in TypeScript
  • Employ multi-paradigm style, with preference for pure functions
  • Use of index.ts is encouraged, but only for re-exporting (no new variables)
  • Naming
    • Prefer medium/long variable names using full words (follow idea that a little verbose is better than too vague)
    • camelCase all variables, args, methods, etc.
    • TitleCase class names, enums, TypeScript types, TypeScript generics
    • SCREAMING_SNAKE_CASE constants
    • snake_case never
    • Do not use a prefixing practice, such as iMyInterface, eMyEnum, cMyClass.
    • Use verbs for functions (some exceptions, such as type narrowing functions like isType(something))
    • Use nouns for most data
    • Use isName for booleans
    • Use plural nouns for lists
    • Exported names should especially not be too vague. E.g., export createAudioNode is more quickly understood in context than just an export named create.
  • Prefer feature packaging over layer packaging
  • Organize code with bundle-splitting in mind, especially in cases where specific library/framework bindings are created, such as for React, which should never be part of the main module. Core utilities can be exported from the main module. Imports from libraries that can be bundle-split should be, such as lodash.
  • Library dependencies should be minimal, within reason
  • Prettier is used for automated formatting
  • ESLint is used for linting

Project major TODOs

  • Implement prototype for handling AudioParams
  • Refinement of VirtualAudioGraph in general (keep mutative class style for core graph utilities? make immutable state changes after mutation only in a React hooks submodule?)
  • Test coverage for everything
  • Review & update all JSDoc comments
  • Logging utility - default configurable print level 0-4 based on whether localhost, logs can be hooked into as event emitter
  • Support for custom AudioNode and BaseAudioContext subclasses (requires extendible config and supporting types for TS module augmentation)
  • React bindings
  • Demos
  • Build & publish process
  • Contribution docs
  • API docs