Compare commits
15 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 3af2210c5e | |||
| d6aa73fd28 | |||
| f0083cfe45 | |||
| 66f32dd678 | |||
| 7faf1e1366 | |||
| e6ae16ca51 | |||
| 6af5250501 | |||
| 7c0dd9a6cc | |||
| 5f6b2223e1 | |||
| 864157ac84 | |||
| c89ee5ddb3 | |||
| 5a255350b4 | |||
| 8919524432 | |||
| f79a64de60 | |||
| 3fdeccdb23 |
@@ -1,19 +0,0 @@
|
||||
{
|
||||
"env": {
|
||||
"node": true,
|
||||
"browser": true,
|
||||
"es2021": true
|
||||
},
|
||||
"extends": ["eslint:recommended"],
|
||||
"overrides": [],
|
||||
"parserOptions": {
|
||||
"ecmaVersion": "latest",
|
||||
"sourceType": "module"
|
||||
},
|
||||
"plugins": ["import"],
|
||||
"rules": {
|
||||
"no-unused-vars": ["warn", { "destructuredArrayIgnorePattern": ".", "ignoreRestSiblings": false }],
|
||||
"import/no-extraneous-dependencies": ["error", {"devDependencies": true}]
|
||||
},
|
||||
"files": ["**/*.mjs", "**/*.js"]
|
||||
}
|
||||
@@ -1,37 +0,0 @@
|
||||
name: Build and Deploy
|
||||
|
||||
on: [workflow_dispatch]
|
||||
|
||||
# Allow one concurrent deployment
|
||||
concurrency:
|
||||
group: "pages"
|
||||
cancel-in-progress: true
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: docker
|
||||
env:
|
||||
SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: 9.12.2
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: 20
|
||||
# cache: "pnpm"
|
||||
- name: Install Dependencies
|
||||
run: pnpm install
|
||||
|
||||
- name: Build
|
||||
run: pnpm build
|
||||
|
||||
- name: Deploy
|
||||
run: |
|
||||
eval $(ssh-agent -s)
|
||||
echo "$SSH_PRIVATE_KEY" | ssh-add -
|
||||
apt update && apt install -y rsync
|
||||
mkdir ~/.ssh
|
||||
ssh-keyscan matrix.toplap.org > ~/.ssh/known_hosts
|
||||
rsync -atv --delete --delete-after --progress ./website/dist/ strudel@matrix.toplap.org:/home/strudel/deploy
|
||||
@@ -1,26 +0,0 @@
|
||||
name: Strudel tests
|
||||
|
||||
on: [push, pull_request]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: docker
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [20]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- name: apt install ztd
|
||||
run: apt update && apt install -y zstd
|
||||
- uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: 9.12.2
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: ${{ matrix.node-version }}
|
||||
cache: "pnpm"
|
||||
- run: pnpm install
|
||||
- run: pnpm run format-check
|
||||
- run: pnpm run lint
|
||||
- run: pnpm test
|
||||
@@ -0,0 +1,19 @@
|
||||
name: Strudel tests
|
||||
|
||||
on: [push, pull_request]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [16, 17]
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: ${{ matrix.node-version }}
|
||||
cache: 'npm'
|
||||
- run: npm install
|
||||
- run: npm test
|
||||
@@ -1,5 +1,4 @@
|
||||
dist
|
||||
out
|
||||
!docs/dist
|
||||
dist-*
|
||||
cabal-dev
|
||||
@@ -27,107 +26,4 @@ node_modules/
|
||||
.DS_Store
|
||||
repl-parcel
|
||||
mytunes.ts
|
||||
doc
|
||||
out
|
||||
.parcel-cache
|
||||
repl_old
|
||||
tutorial.rendered.mdx
|
||||
doc.json
|
||||
talk/public/EmuSP12
|
||||
talk/public/samples
|
||||
server/samples/old
|
||||
repl/stats.html
|
||||
coverage
|
||||
public/icons/apple-splash-*
|
||||
dev-dist
|
||||
Dirt-Samples
|
||||
tidal-drum-machines
|
||||
webaudiofontdata
|
||||
src-tauri/target
|
||||
|
||||
# BEGIN JetBrains -> END JetBrains
|
||||
|
||||
# for JetBrains IDE users, e.g. WebStorm. Source: https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
|
||||
# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio, WebStorm and Rider
|
||||
# Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839
|
||||
|
||||
# User-specific stuff
|
||||
.idea/**/workspace.xml
|
||||
.idea/**/tasks.xml
|
||||
.idea/**/usage.statistics.xml
|
||||
.idea/**/dictionaries
|
||||
.idea/**/shelf
|
||||
|
||||
# AWS User-specific
|
||||
.idea/**/aws.xml
|
||||
|
||||
# Generated files
|
||||
.idea/**/contentModel.xml
|
||||
|
||||
# Sensitive or high-churn files
|
||||
.idea/**/dataSources/
|
||||
.idea/**/dataSources.ids
|
||||
.idea/**/dataSources.local.xml
|
||||
.idea/**/sqlDataSources.xml
|
||||
.idea/**/dynamic.xml
|
||||
.idea/**/uiDesigner.xml
|
||||
.idea/**/dbnavigator.xml
|
||||
|
||||
# Gradle
|
||||
.idea/**/gradle.xml
|
||||
.idea/**/libraries
|
||||
|
||||
# Gradle and Maven with auto-import
|
||||
# When using Gradle or Maven with auto-import, you should exclude module files,
|
||||
# since they will be recreated, and may cause churn. Uncomment if using
|
||||
# auto-import.
|
||||
# .idea/artifacts
|
||||
# .idea/compiler.xml
|
||||
# .idea/jarRepositories.xml
|
||||
# .idea/modules.xml
|
||||
# .idea/*.iml
|
||||
# .idea/modules
|
||||
# *.iml
|
||||
# *.ipr
|
||||
|
||||
# CMake
|
||||
cmake-build-*/
|
||||
|
||||
# Mongo Explorer plugin
|
||||
.idea/**/mongoSettings.xml
|
||||
|
||||
# File-based project format
|
||||
*.iws
|
||||
|
||||
# IntelliJ
|
||||
out/
|
||||
|
||||
# mpeltonen/sbt-idea plugin
|
||||
.idea_modules/
|
||||
|
||||
# JIRA plugin
|
||||
atlassian-ide-plugin.xml
|
||||
|
||||
# Cursive Clojure plugin
|
||||
.idea/replstate.xml
|
||||
|
||||
# SonarLint plugin
|
||||
.idea/sonarlint/
|
||||
|
||||
# Crashlytics plugin (for Android Studio and IntelliJ)
|
||||
com_crashlytics_export_strings.xml
|
||||
crashlytics.properties
|
||||
crashlytics-build.properties
|
||||
fabric.properties
|
||||
|
||||
# Editor-based Rest Client
|
||||
.idea/httpRequests
|
||||
|
||||
# Android studio 3.1+ serialized cache file
|
||||
.idea/caches/build_file_checksums.ser
|
||||
|
||||
# END JetBrains -> BEGIN JetBrains
|
||||
|
||||
samples/*
|
||||
!samples/README.md
|
||||
.idea/
|
||||
doc
|
||||
@@ -1,16 +0,0 @@
|
||||
*.md
|
||||
*.json
|
||||
*.yml
|
||||
*.
|
||||
**/out
|
||||
**/dist
|
||||
packages/mini/krill-parser.js
|
||||
packages/xen/tunejs.js
|
||||
paper
|
||||
pnpm-lock.yaml
|
||||
pnpm-workspace.yaml
|
||||
**/dev-dist
|
||||
website/.astro
|
||||
!tidal-drum-machines.json
|
||||
!tidal-drum-machines-alias.json
|
||||
.pnpm-store
|
||||
@@ -1,15 +1,16 @@
|
||||
{
|
||||
"printWidth": 120,
|
||||
"useTabs": false,
|
||||
"tabWidth": 2,
|
||||
"semi": true,
|
||||
"singleQuote": true,
|
||||
"jsxSingleQuote": false,
|
||||
"trailingComma": "all",
|
||||
"bracketSpacing": true,
|
||||
"bracketSameLine": false,
|
||||
"arrowParens": "always",
|
||||
"proseWrap": "preserve",
|
||||
"htmlWhitespaceSensitivity": "css",
|
||||
"endOfLine": "lf"
|
||||
}
|
||||
"printWidth": 120,
|
||||
"useTabs": false,
|
||||
"tabWidth": 2,
|
||||
"semi": true,
|
||||
"singleQuote": true,
|
||||
"jsxSingleQuote": false,
|
||||
"trailingComma": "all",
|
||||
"bracketSpacing": true,
|
||||
"jsxBracketSameLine": false,
|
||||
"arrowParens": "always",
|
||||
"proseWrap": "preserve",
|
||||
"htmlWhitespaceSensitivity": "css",
|
||||
"endOfLine": "lf"
|
||||
}
|
||||
|
||||
@@ -2,9 +2,5 @@
|
||||
"cSpell.words": [
|
||||
"subspan",
|
||||
"vals"
|
||||
],
|
||||
"yaml.schemas": {
|
||||
"https://json.schemastore.org/github-workflow.json": "file:///home/felix/projects/strudel/.github/workflows/deploy.yml"
|
||||
},
|
||||
"testing.automaticallyOpenPeekView": "never"
|
||||
]
|
||||
}
|
||||
@@ -1,241 +0,0 @@
|
||||
# 🌀 Contributing to Strudel 🌀
|
||||
|
||||
Thanks for wanting to contribute!!! There are many ways you can add value to this project
|
||||
|
||||
## Move to codeberg
|
||||
|
||||
We are currently in the process of moving from github to codeberg -- not everything is working, please bear with us.
|
||||
|
||||
To update your local clone, you can run this command:
|
||||
|
||||
```
|
||||
git remote set-url origin git@codeberg.org:uzu/strudel.git
|
||||
```
|
||||
|
||||
|
||||
## Communication Channels
|
||||
|
||||
To get in touch with the contributors, either
|
||||
|
||||
- [join the Tidal Discord Channel](https://discord.com/invite/HGEdXmRkzT) and go to the #strudel channel
|
||||
- Find related discussions on the [tidal club forum](https://club.tidalcycles.org/)
|
||||
|
||||
## Ask a Question
|
||||
|
||||
If you have any questions about strudel, make sure you've glanced through the
|
||||
[docs](https://strudel.cc/learn/) to find out if it answers your question.
|
||||
If not, use one of the Communication Channels above!
|
||||
|
||||
Don't be afraid to ask! Your question might be of great value for other people too.
|
||||
|
||||
## Give Feedback
|
||||
|
||||
No matter if you've used the Strudel REPL or if you are using the strudel packages, we are happy to hear some feedback.
|
||||
Use one of the Communication Channels listed above and drop us a line or two!
|
||||
|
||||
## Share Music
|
||||
|
||||
If you made some music with strudel, you can give back some love and share what you've done!
|
||||
Your creation could also be part of the random selection in the REPL if you want.
|
||||
Use one of the Communication Channels listed above.
|
||||
|
||||
## Improve the Docs
|
||||
|
||||
If you find some weak spots in the [docs](https://strudel.cc/workshop/getting-started/),
|
||||
you can edit each file directly on codeburg. (we are currently fixing the "Edit this page" links in the right sidebar)
|
||||
|
||||
## Propose a Feature
|
||||
|
||||
If you want a specific feature that is not part of strudel yet, feel free to use one of the communication channels above.
|
||||
Maybe you even want to help with the implementation of that feature!
|
||||
|
||||
## Report a Bug
|
||||
|
||||
If you've found a bug, or some behaviour that does not seem right, you are welcome to file an [issue](https://codeberg.org/uzu/strudel/issues).
|
||||
Please check that it has not been reported before.
|
||||
|
||||
## Fix a Bug
|
||||
|
||||
To fix a bug that has been reported,
|
||||
|
||||
1. check that nobody else is already fixing it and respond to the issue to let people know you're on it
|
||||
2. fork the repository
|
||||
3. make sure you've setup the project (see below)
|
||||
4. hopefully fix the bug
|
||||
5. make sure the tests pass
|
||||
6. send a pull request
|
||||
|
||||
## Write Tests
|
||||
|
||||
There are still many tests that have not been written yet! Reading and writing tests is a great opportunity to get familiar with the codebase.
|
||||
You can find the tests in each package in the `test` folder. To run all tests, run `pnpm test` from the root folder.
|
||||
|
||||
## Project Setup
|
||||
|
||||
To get the project up and running for development, make sure you have installed:
|
||||
|
||||
- [git](https://git-scm.com/)
|
||||
- [node](https://nodejs.org/en/) >= 18
|
||||
- [pnpm](https://pnpm.io/) (`curl -fsSL https://get.pnpm.io/install.sh | env PNPM_VERSION=8.11.0 sh -`)
|
||||
|
||||
then, do the following:
|
||||
|
||||
```sh
|
||||
git clone https://codeberg.org/uzu/strudel.git && cd strudel
|
||||
pnpm i # install at root to symlink packages
|
||||
pnpm start # start repl
|
||||
```
|
||||
|
||||
Those commands might look slightly different for your OS.
|
||||
Please report any problems you've had with the setup instructions!
|
||||
|
||||
## Code Style
|
||||
|
||||
To make sure the code changes only where it should, we are using prettier to unify the code style.
|
||||
|
||||
- You can format all files at once by running `pnpm codeformat` from the project root
|
||||
- Run `pnpm format-check` from the project root to check if all files are well formatted
|
||||
|
||||
If you use VSCode, you can
|
||||
|
||||
1. install [the prettier extension](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)
|
||||
2. open command palette and run "Format Document With..."
|
||||
3. Choose "Configure Default Formatter..."
|
||||
4. Select prettier
|
||||
|
||||
## ESLint
|
||||
|
||||
To prevent unwanted runtime errors, this project uses [eslint](https://eslint.org/).
|
||||
|
||||
- You can check for lint errors by running `pnpm lint`
|
||||
|
||||
There are also eslint extensions / plugins for most editors.
|
||||
|
||||
## Running Tests
|
||||
|
||||
- Run all tests with `pnpm test`
|
||||
- Run all tests with UI using `pnpm test-ui`
|
||||
|
||||
## Running all CI Checks
|
||||
|
||||
When opening a PR, the CI runner will automatically check the code style and eslint, as well as run all tests.
|
||||
You can run the same check with `pnpm check`
|
||||
|
||||
## Package Workflow
|
||||
|
||||
The project is split into multiple [packages](https://codeberg.org/uzu/strudel/src/branch/main/packages) with independent versioning.
|
||||
When you run `pnpm i` on the root folder, [pnpm workspaces](https://pnpm.io/workspaces) will install all dependencies of all subpackages. This will allow any js file to import `@strudel/<package-name>` to get the local version,
|
||||
allowing to develop multiple packages at the same time.
|
||||
|
||||
## Package Publishing
|
||||
|
||||
To publish all packages that have been changed since the last release, run:
|
||||
|
||||
```sh
|
||||
npm login
|
||||
|
||||
# this will increment all the versions in package.json files of non private packages to selected versions
|
||||
npx lerna version --no-private
|
||||
|
||||
# publish all packages inside /packages using pnpm! don't use lerna to publish!!
|
||||
pnpm --filter "./packages/**" publish --dry-run
|
||||
|
||||
# the last command was only a dry-run. if everything looks ok, run this:
|
||||
|
||||
pnpm --filter "./packages/**" publish --access public
|
||||
```
|
||||
|
||||
To manually publish a single package, increase the version in the `package.json`, then run `pnpm publish`.
|
||||
Important: Always publish with `pnpm`, as `npm` does not support overriding main files in `publishConfig`, which is done in all the packages.
|
||||
|
||||
|
||||
## useful commands
|
||||
|
||||
```sh
|
||||
#regenerate the test snapshots (ex: when updating or creating new pattern functions)
|
||||
pnpm snapshot
|
||||
|
||||
#start the OSC server
|
||||
pnpm run osc
|
||||
|
||||
#build the standalone version
|
||||
pnpm tauri build
|
||||
```
|
||||
|
||||
## version tag patching
|
||||
|
||||
here's a little guide on how to patch patterns in the database to prevent breaking old patterns due to breaking changes in newer versions.
|
||||
|
||||
the general tactic is to use `// @version x.y` to tag a pattern with a specific strudel version. when a pattern is evaluated, this metadata will de-activate any breaking changes that came after the specified version.
|
||||
for example, in version 1.1, the default value for `fanchor` was changed from `0.5` to `0`.
|
||||
if play a pattern that was made before that change, sounds that use filter evenlopes can sound very different, so by adding `// @version 1.0` will make it sound like it used to.
|
||||
before releasing a new version with breaking changes, we can edit all patterns in the database, inserting the version tag they were created under:
|
||||
|
||||
as an example, to release version 1.2, do the following:
|
||||
|
||||
1. get date range
|
||||
|
||||
```sh
|
||||
# get date of last version:
|
||||
git log -1 --format=%aI @strudel/core@1.1.0
|
||||
# 2024-05-31T23:07:26+02:00
|
||||
|
||||
# get date of current version:
|
||||
git log -1 --format=%aI @strudel/core@1.2.0
|
||||
# 2025-05-01T12:39:24+02:00
|
||||
# might also use todays timestamp if version is not yet released
|
||||
```
|
||||
|
||||
now we know, all patterns between these 2 dates have to receive a version tag (unless they already have one).
|
||||
|
||||
2. get patterns in question
|
||||
|
||||
```sql
|
||||
SELECT *
|
||||
FROM code_v1
|
||||
WHERE code NOT LIKE '%@version%'
|
||||
AND created_at > '2024-05-31T23:07:26+02:00'
|
||||
AND created_at < '2025-05-01T12:39:24+02:00'
|
||||
ORDER BY created_at ASC;
|
||||
```
|
||||
|
||||
this gives us all unversioned patterns that were saved between 1.1.0 and 1.2.0. in this case, it's 9373 patterns!
|
||||
|
||||
3. insert version tags
|
||||
|
||||
we are now ready to insert the version tag to these patterns.
|
||||
before updating thousands of patterns, it's probably a good idea to test if a single one gets udpated:
|
||||
|
||||
```sql
|
||||
UPDATE code_v1
|
||||
SET code = code || E'\n// @version 1.1'
|
||||
WHERE hash = 'Ns2sMB40yIw4';
|
||||
```
|
||||
|
||||
after [verifying](https://strudel.cc/?Ns2sMB40yIw4) that the version tag has been added, let's insert it everywhere:
|
||||
|
||||
```sql
|
||||
UPDATE code_v1
|
||||
SET code = code || E'\n// @version 1.1'
|
||||
WHERE code NOT LIKE '%@version%'
|
||||
AND created_at > '2024-05-31T23:07:26+02:00'
|
||||
AND created_at < '2025-05-01T12:39:24+02:00'
|
||||
```
|
||||
|
||||
4. verify
|
||||
|
||||
we can verify that the edits worked by querying all patterns that contain the new version tag:
|
||||
|
||||
```sql
|
||||
SELECT *
|
||||
FROM code_v1
|
||||
WHERE code LIKE '%@version 1.1%'
|
||||
AND created_at > '2024-05-31T23:07:26+02:00'
|
||||
AND created_at < '2025-05-01T12:39:24+02:00'
|
||||
ORDER BY created_at ASC;
|
||||
```
|
||||
|
||||
|
||||
## Have Fun
|
||||
|
||||
Remember to have fun, and that this project is driven by the passion of volunteers!
|
||||
@@ -1,21 +0,0 @@
|
||||
FROM node:24
|
||||
|
||||
WORKDIR /app
|
||||
|
||||
RUN npm install pnpm --global
|
||||
|
||||
COPY pnpm-workspace.yaml ./
|
||||
COPY package.json pnpm-lock.yaml ./
|
||||
COPY packages/ ./packages/
|
||||
COPY examples/ ./examples/
|
||||
RUN mkdir -p website/public
|
||||
COPY website/package.json ./website/
|
||||
|
||||
RUN pnpm install
|
||||
|
||||
|
||||
COPY . .
|
||||
|
||||
EXPOSE 4321
|
||||
|
||||
CMD ["pnpm", "dev"]
|
||||
@@ -1,5 +1,5 @@
|
||||
GNU AFFERO GENERAL PUBLIC LICENSE
|
||||
Version 3, 19 November 2007
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
Version 3, 29 June 2007
|
||||
|
||||
Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
@@ -7,15 +7,17 @@
|
||||
|
||||
Preamble
|
||||
|
||||
The GNU Affero General Public License is a free, copyleft license for
|
||||
software and other kinds of works, specifically designed to ensure
|
||||
cooperation with the community in the case of network server software.
|
||||
The GNU General Public License is a free, copyleft license for
|
||||
software and other kinds of works.
|
||||
|
||||
The licenses for most software and other practical works are designed
|
||||
to take away your freedom to share and change the works. By contrast,
|
||||
our General Public Licenses are intended to guarantee your freedom to
|
||||
the GNU General Public License is intended to guarantee your freedom to
|
||||
share and change all versions of a program--to make sure it remains free
|
||||
software for all its users.
|
||||
software for all its users. We, the Free Software Foundation, use the
|
||||
GNU General Public License for most of our software; it applies also to
|
||||
any other work released this way by its authors. You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
@@ -24,34 +26,44 @@ them if you wish), that you receive source code or can get it if you
|
||||
want it, that you can change the software or use pieces of it in new
|
||||
free programs, and that you know you can do these things.
|
||||
|
||||
Developers that use our General Public Licenses protect your rights
|
||||
with two steps: (1) assert copyright on the software, and (2) offer
|
||||
you this License which gives you legal permission to copy, distribute
|
||||
and/or modify the software.
|
||||
To protect your rights, we need to prevent others from denying you
|
||||
these rights or asking you to surrender the rights. Therefore, you have
|
||||
certain responsibilities if you distribute copies of the software, or if
|
||||
you modify it: responsibilities to respect the freedom of others.
|
||||
|
||||
A secondary benefit of defending all users' freedom is that
|
||||
improvements made in alternate versions of the program, if they
|
||||
receive widespread use, become available for other developers to
|
||||
incorporate. Many developers of free software are heartened and
|
||||
encouraged by the resulting cooperation. However, in the case of
|
||||
software used on network servers, this result may fail to come about.
|
||||
The GNU General Public License permits making a modified version and
|
||||
letting the public access it on a server without ever releasing its
|
||||
source code to the public.
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must pass on to the recipients the same
|
||||
freedoms that you received. You must make sure that they, too, receive
|
||||
or can get the source code. And you must show them these terms so they
|
||||
know their rights.
|
||||
|
||||
The GNU Affero General Public License is designed specifically to
|
||||
ensure that, in such cases, the modified source code becomes available
|
||||
to the community. It requires the operator of a network server to
|
||||
provide the source code of the modified version running there to the
|
||||
users of that server. Therefore, public use of a modified version, on
|
||||
a publicly accessible server, gives the public access to the source
|
||||
code of the modified version.
|
||||
Developers that use the GNU GPL protect your rights with two steps:
|
||||
(1) assert copyright on the software, and (2) offer you this License
|
||||
giving you legal permission to copy, distribute and/or modify it.
|
||||
|
||||
An older license, called the Affero General Public License and
|
||||
published by Affero, was designed to accomplish similar goals. This is
|
||||
a different license, not a version of the Affero GPL, but Affero has
|
||||
released a new version of the Affero GPL which permits relicensing under
|
||||
this license.
|
||||
For the developers' and authors' protection, the GPL clearly explains
|
||||
that there is no warranty for this free software. For both users' and
|
||||
authors' sake, the GPL requires that modified versions be marked as
|
||||
changed, so that their problems will not be attributed erroneously to
|
||||
authors of previous versions.
|
||||
|
||||
Some devices are designed to deny users access to install or run
|
||||
modified versions of the software inside them, although the manufacturer
|
||||
can do so. This is fundamentally incompatible with the aim of
|
||||
protecting users' freedom to change the software. The systematic
|
||||
pattern of such abuse occurs in the area of products for individuals to
|
||||
use, which is precisely where it is most unacceptable. Therefore, we
|
||||
have designed this version of the GPL to prohibit the practice for those
|
||||
products. If such problems arise substantially in other domains, we
|
||||
stand ready to extend this provision to those domains in future versions
|
||||
of the GPL, as needed to protect the freedom of users.
|
||||
|
||||
Finally, every program is threatened constantly by software patents.
|
||||
States should not allow patents to restrict development and use of
|
||||
software on general-purpose computers, but in those that do, we wish to
|
||||
avoid the special danger that patents applied to a free program could
|
||||
make it effectively proprietary. To prevent this, the GPL assures that
|
||||
patents cannot be used to render the program non-free.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
@@ -60,7 +72,7 @@ modification follow.
|
||||
|
||||
0. Definitions.
|
||||
|
||||
"This License" refers to version 3 of the GNU Affero General Public License.
|
||||
"This License" refers to version 3 of the GNU General Public License.
|
||||
|
||||
"Copyright" also means copyright-like laws that apply to other kinds of
|
||||
works, such as semiconductor masks.
|
||||
@@ -537,45 +549,35 @@ to collect a royalty for further conveying from those to whom you convey
|
||||
the Program, the only way you could satisfy both those terms and this
|
||||
License would be to refrain entirely from conveying the Program.
|
||||
|
||||
13. Remote Network Interaction; Use with the GNU General Public License.
|
||||
|
||||
Notwithstanding any other provision of this License, if you modify the
|
||||
Program, your modified version must prominently offer all users
|
||||
interacting with it remotely through a computer network (if your version
|
||||
supports such interaction) an opportunity to receive the Corresponding
|
||||
Source of your version by providing access to the Corresponding Source
|
||||
from a network server at no charge, through some standard or customary
|
||||
means of facilitating copying of software. This Corresponding Source
|
||||
shall include the Corresponding Source for any work covered by version 3
|
||||
of the GNU General Public License that is incorporated pursuant to the
|
||||
following paragraph.
|
||||
13. Use with the GNU Affero General Public License.
|
||||
|
||||
Notwithstanding any other provision of this License, you have
|
||||
permission to link or combine any covered work with a work licensed
|
||||
under version 3 of the GNU General Public License into a single
|
||||
under version 3 of the GNU Affero General Public License into a single
|
||||
combined work, and to convey the resulting work. The terms of this
|
||||
License will continue to apply to the part which is the covered work,
|
||||
but the work with which it is combined will remain governed by version
|
||||
3 of the GNU General Public License.
|
||||
but the special requirements of the GNU Affero General Public License,
|
||||
section 13, concerning interaction through a network will apply to the
|
||||
combination as such.
|
||||
|
||||
14. Revised Versions of this License.
|
||||
|
||||
The Free Software Foundation may publish revised and/or new versions of
|
||||
the GNU Affero General Public License from time to time. Such new versions
|
||||
will be similar in spirit to the present version, but may differ in detail to
|
||||
the GNU General Public License from time to time. Such new versions will
|
||||
be similar in spirit to the present version, but may differ in detail to
|
||||
address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the
|
||||
Program specifies that a certain numbered version of the GNU Affero General
|
||||
Program specifies that a certain numbered version of the GNU General
|
||||
Public License "or any later version" applies to it, you have the
|
||||
option of following the terms and conditions either of that numbered
|
||||
version or of any later version published by the Free Software
|
||||
Foundation. If the Program does not specify a version number of the
|
||||
GNU Affero General Public License, you may choose any version ever published
|
||||
GNU General Public License, you may choose any version ever published
|
||||
by the Free Software Foundation.
|
||||
|
||||
If the Program specifies that a proxy can decide which future
|
||||
versions of the GNU Affero General Public License can be used, that proxy's
|
||||
versions of the GNU General Public License can be used, that proxy's
|
||||
public statement of acceptance of a version permanently authorizes you
|
||||
to choose that version for the Program.
|
||||
|
||||
@@ -633,29 +635,40 @@ the "copyright" line and a pointer to where the full notice is found.
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This program is free software: you can redistribute it and/or modify
|
||||
it under the terms of the GNU Affero General Public License as published by
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation, either version 3 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU Affero General Public License for more details.
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU Affero General Public License
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program. If not, see <https://www.gnu.org/licenses/>.
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
If your software can interact with users remotely through a computer
|
||||
network, you should also make sure that it provides a way for users to
|
||||
get its source. For example, if your program is a web application, its
|
||||
interface could display a "Source" link that leads users to an archive
|
||||
of the code. There are many ways you could offer source, and different
|
||||
solutions will be better for different programs; see section 13 for the
|
||||
specific requirements.
|
||||
If the program does terminal interaction, make it output a short
|
||||
notice like this when it starts in an interactive mode:
|
||||
|
||||
<program> Copyright (C) <year> <name of author>
|
||||
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
|
||||
This is free software, and you are welcome to redistribute it
|
||||
under certain conditions; type `show c' for details.
|
||||
|
||||
The hypothetical commands `show w' and `show c' should show the appropriate
|
||||
parts of the General Public License. Of course, your program's commands
|
||||
might be different; for a GUI interface, you would use an "about box".
|
||||
|
||||
You should also get your employer (if you work as a programmer) or school,
|
||||
if any, to sign a "copyright disclaimer" for the program, if necessary.
|
||||
For more information on this, and how to apply and follow the GNU AGPL, see
|
||||
For more information on this, and how to apply and follow the GNU GPL, see
|
||||
<https://www.gnu.org/licenses/>.
|
||||
|
||||
The GNU General Public License does not permit incorporating your program
|
||||
into proprietary programs. If your program is a subroutine library, you
|
||||
may consider it more useful to permit linking proprietary applications with
|
||||
the library. If this is what you want to do, use the GNU Lesser General
|
||||
Public License instead of this License. But first, please read
|
||||
<https://www.gnu.org/licenses/why-not-lgpl.html>.
|
||||
|
||||
@@ -1,49 +1,43 @@
|
||||
# strudel
|
||||
|
||||
Live coding patterns on the web
|
||||
https://strudel.cc/
|
||||
[](https://github.com/tidalcycles/strudel/actions)
|
||||
|
||||
- Try it here: <https://strudel.cc>
|
||||
- Docs: <https://strudel.cc/learn>
|
||||
- Technical Blog Post: <https://loophole-letters.vercel.app/strudel>
|
||||
- 1 Year of Strudel Blog Post: <https://loophole-letters.vercel.app/strudel1year>
|
||||
- 2 Years of Strudel Blog Post: <https://strudel.cc/blog/#year-2>
|
||||
An experiment in making a [Tidal](https://github.com/tidalcycles/tidal/) using web technologies. This is unstable software, please tread carefully.
|
||||
|
||||
## Running Locally
|
||||
Try it here: https://strudel.tidalcycles.org/
|
||||
|
||||
After cloning the project, you can run the REPL locally:
|
||||
Tutorial: https://strudel.tidalcycles.org/tutorial/
|
||||
|
||||
1. Install [Node.js](https://nodejs.org/)
|
||||
2. Install [pnpm](https://pnpm.io/installation)
|
||||
3. Install dependencies by running the following command:
|
||||
```bash
|
||||
pnpm i
|
||||
```
|
||||
4. Run the development server:
|
||||
```bash
|
||||
pnpm dev
|
||||
```
|
||||
## Local development
|
||||
|
||||
## Using Strudel In Your Project
|
||||
Run the REPL locally:
|
||||
|
||||
This project is organized into many [packages](./packages), which are also available on [npm](https://www.npmjs.com/search?q=%40strudel).
|
||||
```bash
|
||||
npm install
|
||||
npx lerna bootstrap
|
||||
cd repl
|
||||
npm install
|
||||
npm run start
|
||||
```
|
||||
|
||||
Read more about how to use these in your own project [here](https://strudel.cc/technical-manual/project-start).
|
||||
## Publish Packages
|
||||
|
||||
You will need to abide by the terms of the [GNU Affero Public Licence v3](LICENSE). As such, Strudel code can only be shared within free/open source projects under the same license -- see the license for details.
|
||||
To publish, just run:
|
||||
|
||||
Licensing info for the default sound banks can be found over on the [dough-samples](https://github.com/felixroos/dough-samples/blob/main/README.md) repository.
|
||||
```sh
|
||||
npx lerna version
|
||||
```
|
||||
|
||||
## Contributing
|
||||
This will publish all packages that changed since the last version.
|
||||
|
||||
There are many ways to contribute to this project! See [contribution guide](./CONTRIBUTING.md). You can find the full list of contributors [here](https://codeberg.org/uzu/strudel/activity/contributors).
|
||||
## Style
|
||||
|
||||
For now, please try to copy the style of surrounding code. VS Code users can install the 'prettier' add-on which will use the .prettierrc configuration file for automatic formatting.
|
||||
|
||||
## Community
|
||||
|
||||
There is a #strudel channel on the TidalCycles discord: <https://discord.com/invite/HGEdXmRkzT>
|
||||
There is a #strudel channel on the TidalCycles discord: https://discord.com/invite/HGEdXmRkzT
|
||||
|
||||
You can also ask questions and find related discussions on the tidal club forum: <https://club.tidalcycles.org/>
|
||||
You can also ask questions and find related discussions on the tidal club forum: https://club.tidalcycles.org/
|
||||
|
||||
The discord and forum is shared with the haskell (tidal) and python (vortex) siblings of this project.
|
||||
|
||||
We also have a mastodon account: <a rel="me" href="https://social.toplap.org/@strudel">social.toplap.org/@strudel</a>
|
||||
The discord and forum is shared with the haskell (tidal) and python (vortex) siblings of this project.
|
||||
@@ -1,22 +0,0 @@
|
||||
import { queryCode, testCycles } from '../test/runtime.mjs';
|
||||
import * as tunes from '../website/src/repl/tunes.mjs';
|
||||
import { describe, bench } from 'vitest';
|
||||
import { calculateSteps } from '../packages/core/index.mjs';
|
||||
|
||||
const tuneKeys = Object.keys(tunes);
|
||||
|
||||
describe('renders tunes', () => {
|
||||
tuneKeys.forEach((key) => {
|
||||
describe(key, () => {
|
||||
calculateSteps(true);
|
||||
bench(`+steps`, async () => {
|
||||
await queryCode(tunes[key], testCycles[key] || 1);
|
||||
});
|
||||
calculateSteps(false);
|
||||
bench(`-steps`, async () => {
|
||||
await queryCode(tunes[key], testCycles[key] || 1);
|
||||
});
|
||||
calculateSteps(true);
|
||||
});
|
||||
});
|
||||
});
|
||||
@@ -0,0 +1 @@
|
||||
strudel.tidalcycles.org
|
||||
@@ -0,0 +1,16 @@
|
||||
{
|
||||
"files": {
|
||||
"main.css": "/static/css/main.0d689283.css",
|
||||
"main.js": "/static/js/main.77e38ada.js",
|
||||
"static/js/787.8f7ec9e0.chunk.js": "/static/js/787.8f7ec9e0.chunk.js",
|
||||
"static/media/logo.svg": "/static/media/logo.ac95051720b3dccfe511e0e02d8e1029.svg",
|
||||
"index.html": "/index.html",
|
||||
"main.0d689283.css.map": "/static/css/main.0d689283.css.map",
|
||||
"main.77e38ada.js.map": "/static/js/main.77e38ada.js.map",
|
||||
"787.8f7ec9e0.chunk.js.map": "/static/js/787.8f7ec9e0.chunk.js.map"
|
||||
},
|
||||
"entrypoints": [
|
||||
"static/css/main.0d689283.css",
|
||||
"static/js/main.77e38ada.js"
|
||||
]
|
||||
}
|
||||
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
@@ -1,16 +0,0 @@
|
||||
all: iclc2023.pdf iclc2023.html
|
||||
|
||||
clean:
|
||||
rm iclc2023.pdf iclc2023.html
|
||||
|
||||
iclc2023.html: iclc2023.md citations.json
|
||||
pandoc --template=pandoc/iclc.html --citeproc --number-sections iclc2023.md -o iclc2023.html
|
||||
|
||||
iclc2023.pdf: iclc2023.md citations.json pandoc/iclc.latex pandoc/iclc.sty
|
||||
pandoc --template=pandoc/iclc.latex --citeproc --number-sections iclc2023.md -o iclc2023.pdf
|
||||
|
||||
iclc2023.docx: iclc2023.md citations.json
|
||||
pandoc --citeproc --number-sections iclc2023.md -o iclc2023.docx
|
||||
|
||||
iclc2023x.pdf: iclc2023.md citations.json pandoc/iclc.latex pandoc/iclc.sty
|
||||
pandoc --template=pandoc/iclc.latex --citeproc --number-sections iclc2023.md --pdf-engine=xelatex -o iclc2023x.pdf
|
||||
@@ -1,22 +0,0 @@
|
||||
# paper
|
||||
|
||||
## iclc2023
|
||||
|
||||
from the strudel project root:
|
||||
|
||||
```sh
|
||||
npm run iclc
|
||||
npm run iclc-nocite # try this if you get an error
|
||||
```
|
||||
|
||||
## old
|
||||
|
||||
Work in progress on a paper about strudel
|
||||
|
||||
To build you will need
|
||||
|
||||
- pandoc
|
||||
- pandoc-url2cite (`npm install -g pandoc-url2cite`)
|
||||
- latex/xelatex
|
||||
- python
|
||||
- pandocfilters (`pip3 install pandocfilters`)
|
||||
@@ -1,214 +0,0 @@
|
||||
---
|
||||
bibliography: citations.json
|
||||
date: 2022-06-24
|
||||
title: "Strudel: Algorithmic Patterns for the Web"
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
This paper introduces Strudel (or sometimes 'StrudelCycles'), an
|
||||
alternative implementation of the Tidal (or 'TidalCycles') live coding
|
||||
system, using the JavaScript programming language. Strudel is an attempt
|
||||
to make live coding more accessible, by creating a system that runs
|
||||
entirely in the browser, while opening Tidal's approach to algorithmic
|
||||
patterns [@mcleanAlgorithmicPattern2020a] up to modern audio/visual web
|
||||
technologies. The Strudel REPL is a live code editor dedicated to
|
||||
manipulating Strudel patterns while they play, with builtin visual
|
||||
feedback. While Strudel is written in JavaScript, the API is optimized
|
||||
for simplicity and readability by applying code transformations on the
|
||||
syntax tree level, allowing language operations that would otherwise be
|
||||
impossible. The application supports multiple ways to output sound,
|
||||
including Tone.js, Web Audio nodes, OSC (Open Sound Control) messages,
|
||||
Web Serial and Web MIDI. The project is split into multiple packages,
|
||||
allowing granular reuse in other applications. Apart from TidalCycles,
|
||||
Strudel draws inspiration from many prior existing projects like
|
||||
TidalVortex [@mcleanTidalVortexZero2022], Gibber
|
||||
[@robertsGibberLiveCoding2012], Estuary
|
||||
[@ogbornEstuaryBrowserbasedCollaborative2017], Hydra [@jackHydra2022],
|
||||
Ocarina [@solomonPurescriptocarina2022] and Feedforward
|
||||
[@mcleanFeedforward2020].
|
||||
|
||||
# Porting from Haskell
|
||||
|
||||
The original Tidal is implemented as a domain specific language (DSL),
|
||||
embedded in the Haskell pure functional programming language, taking
|
||||
advantage of Haskell's terse syntax and advanced, 'strong' type system.
|
||||
Javascript on the other hand, is a multi-paradigm programming language,
|
||||
with a dynamic type system. Because Tidal leans heavily on many of
|
||||
Haskell's more unique features, it was not always clear that it could
|
||||
meaningfully be ported to a multi-paradigm scripting language. However,
|
||||
this already proved to be the case with an earlier port to Python
|
||||
\[TidalVortex; @mcleanTidalVortexZero2022\], and we have now
|
||||
successfully implemented Tidal's pure functional representation of
|
||||
patterns in Strudel, including partial application, and functor,
|
||||
applicative and monad structures. Over the past few months since the
|
||||
project started in January 2022, a large part of Tidal's functionality
|
||||
has already been ported, including its mini-notation for polymetric
|
||||
sequences, and a large part of its library of pattern manipulations. The
|
||||
result is a terse and highly composable system, where just about
|
||||
everything is a pattern, that may be transformed and combined with other
|
||||
patterns in a myriad of ways.
|
||||
|
||||
# Representing Patterns
|
||||
|
||||
Patterns are the essence of Tidal. Its patterns are abstract entities
|
||||
that represent flows of time as functions, adapting a technique called
|
||||
pure functional reactive programming. Taking a time span as its input, a
|
||||
Pattern can output a set of events that happen within that time span. It
|
||||
depends on the structure of the Pattern how the events are located in
|
||||
time. From now on, this process of generating events from a time span
|
||||
will be called **querying**. Example:
|
||||
|
||||
<MiniRepl tune={`const pattern = sequence(c3, [e3, g3]);
|
||||
const events = pattern.query(0, 1);
|
||||
console.log(events.map(e => e.show()))`} />
|
||||
|
||||
In this example, we create a pattern using the `sequence` function and
|
||||
**query** it for the time span from `0` to `1`. Those numbers represent
|
||||
units of time called **cycles**. The length of one cycle depends on the
|
||||
tempo, which defaults to one cycle per second. The resulting events are:
|
||||
|
||||
<MiniRepl tune={`[{ value: 'c3', begin: 0, end: 1/2 },
|
||||
{ value: 'e3', begin: 1/2, end: 3/4 },
|
||||
{ value: 'g3', begin: 3/4, end: 1 }]`} />
|
||||
|
||||
Each event has a value, a begin time and an end time, where time is
|
||||
represented as a fraction. In the above case, the events are placed in
|
||||
sequential order, where c3 takes the first half, and e3 and g3 together
|
||||
take the second half. This temporal placement is the result of the
|
||||
`sequence` function, which divides its arguments equally over one cycle.
|
||||
If an argument is an array, the same rule applies to that part of the
|
||||
cycle. In the example, e3 and g3 are divided equally over the second
|
||||
half of the whole cycle.
|
||||
|
||||
In the REPL, the user only has to type in the pattern itself, the
|
||||
querying will be handled by the scheduler. The scheduler will repeatedly
|
||||
query the pattern for events, which then will be used for playback.
|
||||
|
||||
{width="43%"}
|
||||
|
||||
# Making Patterns
|
||||
|
||||
In practice, the end-user live coder will not deal with constructing
|
||||
patterns directly, but will rather build patterns using Strudel's
|
||||
extensive combinator library to create, combine and transform patterns.
|
||||
|
||||
The live coder may use the `sequence` function as already seen above, or
|
||||
more often the mini-notation for even terser notation of rhythmic
|
||||
sequences. Such sequences are often treated only a starting point for
|
||||
manipulation, where they then are undergo pattern transformations such
|
||||
as repetition, symmetry, interference/combination or randomisation,
|
||||
potentially at multiple timescales. Because Strudel patterns are
|
||||
represented as pure functions of time rather than as data structures,
|
||||
very long and complex generative results can be represented and
|
||||
manipulated without having to store the resulting sequences in memory.
|
||||
|
||||
# Pattern Example
|
||||
|
||||
The following example showcases how patterns can be utilized to create
|
||||
musical complexity from simple parts, using repetition and interference:
|
||||
|
||||
<MiniRepl tune={`"<0 2 [4 6](3,4,1) 3*2>".scale('D minor')
|
||||
.off(1/4, scaleTranspose(2))
|
||||
.off(1/2, scaleTranspose(6))
|
||||
.legato(.5)
|
||||
.echo(4, 1/8, .5)
|
||||
.tone((await piano()).chain(out()))
|
||||
.pianoroll()`} />
|
||||
|
||||
The pattern starts with a rhythm of numbers in mini notation, which are
|
||||
interpreted inside the scale of D minor. Without the scale function, the
|
||||
first line can be expressed as:
|
||||
|
||||
<MiniRepl tune={`"<d3 f3 [a3 c3](3, 4, 1) g3*2>"`} />
|
||||
|
||||
This line could also be expressed without mini notation:
|
||||
|
||||
<MiniRepl tune={`slowcat(d3, f3, [a3, c3].euclid(3, 4, 1), g3.fast(2))`} />
|
||||
|
||||
Here is a short description of all the functions used:
|
||||
|
||||
- `slowcat`: play elements sequentially, where each lasts one cycle
|
||||
- `brackets`: elements inside brackets are divided equally over the
|
||||
time of their parent
|
||||
- `euclid(p, s, o)`: place p pulses evenly over s steps, with offset o
|
||||
[@toussaintEuclideanAlgorithmGenerates2005]
|
||||
- `fast(n)`: speed up by n. `g3.fast(2)` will play g3 two times.
|
||||
- `off(n, f)`: copy each event, offset it by n cycles and apply
|
||||
function f
|
||||
- `legato(n)`: multiply duration of event with n
|
||||
- `echo(t, n, v)`: copy each event t times, with n cycles in between
|
||||
each copy, decreasing velocity by v
|
||||
- `tone(instrument)`: play back each event with the given Tone.js
|
||||
instrument
|
||||
- `pianoroll()`: visualize events as midi notes in a pianoroll
|
||||
|
||||
# Ways to make Sound
|
||||
|
||||
To generate sound, Strudel supports different outputs:
|
||||
|
||||
- Tone.js
|
||||
- Web Audio API
|
||||
- WebDirt, a js recreation of Tidal's *Dirt* sample engine
|
||||
- OSC via osc-js
|
||||
- MIDI via WebMIDI
|
||||
|
||||
Tone.js proved to be limited for the use case of Strudel, where each
|
||||
individual event could potentially have a completely different audio
|
||||
graph. While the Web Audio API takes a *fire-and-forget* approach,
|
||||
creating a lot of Tone.js instruments and effects causes performance
|
||||
issues quickly. For that reason, we chose to search for alternatives.
|
||||
|
||||
Strudel's Web Audio API output creates a new audio graph for each event.
|
||||
It currently supports basic oscillators, sample playback, envelopes,
|
||||
filters and an experimental support for soundfonts.
|
||||
|
||||
WebDirt [@ogbornDktr0WebDirt2022] was created as part of the Estuary
|
||||
Live Coding System [@ogbornEstuaryBrowserbasedCollaborative2017], and
|
||||
proved to be a solid choice for handling samples in Strudel as well.
|
||||
|
||||
Using OSC, it is possible to send messages to SuperDirt
|
||||
[@SuperDirt2022], which is what Tidal does to generate sound. The
|
||||
downside of using OSC is that it requires the user to install
|
||||
SuperCollider and its sc3plugins library, which can be difficult.
|
||||
|
||||
The MIDI output can be used to send MIDI messages to either external
|
||||
instruments or to other programs on the same device. Web MIDI is
|
||||
currently only supported on Chromium-based browsers.
|
||||
|
||||
# Future Outlook
|
||||
|
||||
The project is still young, with many features on the horizon. As
|
||||
general guiding principles, Strudel aims to be
|
||||
|
||||
1. accessible
|
||||
2. consistent with Tidal's approach to pattern
|
||||
3. modular and extensible
|
||||
|
||||
For the future, it is planned to integrate alternative sound engines
|
||||
such as Glicol [@lanChaosprintGlicol2022] and Faust
|
||||
[@FaustProgrammingLanguage2022]. To improve compatibility with Tidal,
|
||||
more Tidal functions are planned to be ported, as well as full
|
||||
compatibility with SuperDirt. Besides sound, other ways to render events
|
||||
are being explored, such as graphical, and choreographic output. We are
|
||||
also looking into alternative ways of editing patterns, including
|
||||
multi-user editing for network music, parsing a novel syntax to escape
|
||||
the constraints of javascript, and developing hardware/e-textile
|
||||
interfaces.
|
||||
|
||||
# Links
|
||||
|
||||
The Strudel REPL is available at <https://strudel.cc>,
|
||||
including an interactive tutorial. The repository is at
|
||||
<https://codeberg.org/uzu/strudel/releases>, all the code is open source
|
||||
under the GPL-3.0 License.
|
||||
|
||||
# Acknowledgments
|
||||
|
||||
Thanks to the Strudel and wider Tidal, live coding, webaudio and
|
||||
free/open source software communities for inspiration and support. Alex
|
||||
McLean's work on this project is supported by a UKRI Future Leaders
|
||||
Fellowship \[grant number MR/V025260/1\].
|
||||
|
||||
# References {#references .unnumbered}
|
||||
@@ -1,137 +0,0 @@
|
||||
---
|
||||
title: 'Strudel: Algorithmic Patterns for the Web'
|
||||
date: '2022-06-24'
|
||||
bibliography: citations.json
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
This paper introduces Strudel (or sometimes 'StrudelCycles'), an alternative implementation of the Tidal (or 'TidalCycles') live coding system, using the JavaScript programming language. Strudel is an attempt to make live coding more accessible, by creating a system that runs entirely in the browser, while opening Tidal's approach to algorithmic patterns [@mcleanAlgorithmicPattern2020a] up to modern audio/visual web technologies. The Strudel REPL is a live code editor dedicated to manipulating Strudel patterns while they play, with builtin visual feedback. While Strudel is written in JavaScript, the API is optimized for simplicity and readability by applying code transformations on the syntax tree level, allowing language operations that would otherwise be impossible. The application supports multiple ways to output sound, including Tone.js, Web Audio nodes, OSC (Open Sound Control) messages, Web Serial and Web MIDI. The project is split into multiple packages, allowing granular reuse in other applications. Apart from TidalCycles, Strudel draws inspiration from many prior existing projects like TidalVortex [@mcleanTidalVortexZero2022], Gibber [@robertsGibberLiveCoding2012], Estuary [@ogbornEstuaryBrowserbasedCollaborative2017], Hydra [@jackHydra2022], Ocarina [@solomonPurescriptocarina2022] and Feedforward [@mcleanFeedforward2020].
|
||||
|
||||
# Porting from Haskell
|
||||
|
||||
The original Tidal is implemented as a domain specific language (DSL), embedded in the Haskell pure functional programming language, taking advantage of Haskell's terse syntax and advanced, 'strong' type system. Javascript on the other hand, is a multi-paradigm programming language, with a dynamic type system. Because Tidal leans heavily on many of Haskell's more unique features, it was not always clear that it could meaningfully be ported to a multi-paradigm scripting language. However, this already proved to be the case with an earlier port to Python [TidalVortex; @mcleanTidalVortexZero2022], and we have now successfully implemented Tidal's pure functional representation of patterns in Strudel, including partial application, and functor, applicative and monad structures. Over the past few months since the project started in January 2022, a large part of Tidal's functionality has already been ported, including its mini-notation for polymetric sequences, and a large part of its library of pattern manipulations. The result is a terse and highly composable system, where just about everything is a pattern, that may be transformed and combined with other patterns in a myriad of ways.
|
||||
|
||||
# Representing Patterns
|
||||
|
||||
Patterns are the essence of Tidal. Its patterns are abstract entities that represent flows of time as functions, adapting a technique called pure functional reactive programming.
|
||||
Taking a time span as its input, a Pattern can output a set of events that happen within that time span.
|
||||
It depends on the structure of the Pattern how the events are located in time.
|
||||
From now on, this process of generating events from a time span will be called **querying**.
|
||||
Example:
|
||||
|
||||
```js
|
||||
const pattern = sequence(c3, [e3, g3]);
|
||||
const events = pattern.query(0, 1);
|
||||
console.log(events.map(e => e.show()))
|
||||
```
|
||||
|
||||
In this example, we create a pattern using the `sequence` function and **query** it for the time span from `0` to `1`.
|
||||
Those numbers represent units of time called **cycles**. The length of one cycle depends on the tempo, which defaults to one cycle per second.
|
||||
The resulting events are:
|
||||
|
||||
```js
|
||||
[{ value: 'c3', begin: 0, end: 1/2 },
|
||||
{ value: 'e3', begin: 1/2, end: 3/4 },
|
||||
{ value: 'g3', begin: 3/4, end: 1 }]
|
||||
```
|
||||
|
||||
Each event has a value, a begin time and an end time, where time is represented as a fraction.
|
||||
In the above case, the events are placed in sequential order, where c3 takes the first half, and e3 and g3 together take the second half.
|
||||
This temporal placement is the result of the `sequence` function, which divides its arguments equally over one cycle.
|
||||
If an argument is an array, the same rule applies to that part of the cycle. In the example, e3 and g3 are divided equally over the second half of the whole cycle.
|
||||
|
||||
In the REPL, the user only has to type in the pattern itself, the querying will be handled by the scheduler.
|
||||
The scheduler will repeatedly query the pattern for events, which then will be used for playback.
|
||||
|
||||
{ width=43% }
|
||||
|
||||
# Making Patterns
|
||||
|
||||
In practice, the end-user live coder will not deal with constructing patterns directly, but will rather build patterns using Strudel's extensive combinator library to create, combine and transform patterns.
|
||||
|
||||
The live coder may use the `sequence` function as already seen above, or more often the mini-notation for even terser notation of rhythmic sequences. Such sequences are often treated only a starting point for manipulation, where they then are undergo pattern transformations such as repetition, symmetry, interference/combination or randomisation, potentially at multiple timescales. Because Strudel patterns are represented as pure functions of time rather than as data structures, very long and complex generative results can be represented and manipulated without having to store the resulting sequences in memory.
|
||||
|
||||
# Pattern Example
|
||||
|
||||
The following example showcases how patterns can be utilized to create musical complexity from simple parts, using repetition and interference:
|
||||
|
||||
```js
|
||||
"<0 2 [4 6](3,4,1) 3*2>".scale('D minor')
|
||||
.off(1/4, scaleTranspose(2))
|
||||
.off(1/2, scaleTranspose(6))
|
||||
.legato(.5)
|
||||
.echo(4, 1/8, .5)
|
||||
.tone((await piano()).chain(out()))
|
||||
.pianoroll()
|
||||
```
|
||||
|
||||
The pattern starts with a rhythm of numbers in mini notation, which are interpreted inside the scale of D minor.
|
||||
Without the scale function, the first line can be expressed as:
|
||||
|
||||
```js
|
||||
"<d3 f3 [a3 c3](3, 4, 1) g3*2>"
|
||||
```
|
||||
|
||||
This line could also be expressed without mini notation:
|
||||
|
||||
```js
|
||||
slowcat(d3, f3, [a3, c3].euclid(3, 4, 1), g3.fast(2))
|
||||
```
|
||||
|
||||
Here is a short description of all the functions used:
|
||||
|
||||
- `slowcat`: play elements sequentially, where each lasts one cycle
|
||||
- `brackets`: elements inside brackets are divided equally over the time of their parent
|
||||
- `euclid(p, s, o)`: place p pulses evenly over s steps, with offset o [@toussaintEuclideanAlgorithmGenerates2005]
|
||||
- `fast(n)`: speed up by n. `g3.fast(2)` will play g3 two times.
|
||||
- `off(n, f)`: copy each event, offset it by n cycles and apply function f
|
||||
- `legato(n)`: multiply duration of event with n
|
||||
- `echo(t, n, v)`: copy each event t times, with n cycles in between each copy, decreasing velocity by v
|
||||
- `tone(instrument)`: play back each event with the given Tone.js instrument
|
||||
- `pianoroll()`: visualize events as midi notes in a pianoroll
|
||||
|
||||
# Ways to make Sound
|
||||
|
||||
To generate sound, Strudel supports different outputs:
|
||||
|
||||
- Tone.js
|
||||
- Web Audio API
|
||||
- WebDirt, a js recreation of Tidal's *Dirt* sample engine
|
||||
- OSC via osc-js
|
||||
- MIDI via WebMIDI
|
||||
|
||||
Tone.js proved to be limited for the use case of Strudel, where each individual event could potentially have a completely different audio graph.
|
||||
While the Web Audio API takes a *fire-and-forget* approach, creating a lot of Tone.js instruments and effects causes performance issues quickly. For that reason, we chose to search for alternatives.
|
||||
|
||||
Strudel's Web Audio API output creates a new audio graph for each event. It currently supports basic oscillators, sample playback, envelopes, filters and
|
||||
an experimental support for soundfonts.
|
||||
|
||||
WebDirt [@ogbornDktr0WebDirt2022] was created as part of the Estuary Live Coding System [@ogbornEstuaryBrowserbasedCollaborative2017], and proved to be a solid choice for handling samples in Strudel as well.
|
||||
|
||||
Using OSC, it is possible to send messages to SuperDirt [@SuperDirt2022], which is what Tidal does to generate sound.
|
||||
The downside of using OSC is that it requires the user to install SuperCollider and its sc3plugins library, which can be difficult.
|
||||
|
||||
The MIDI output can be used to send MIDI messages to either external instruments or to other programs on the same device.
|
||||
Web MIDI is currently only supported on Chromium-based browsers.
|
||||
|
||||
# Future Outlook
|
||||
|
||||
The project is still young, with many features on the horizon. As general guiding principles, Strudel aims to be
|
||||
|
||||
1. accessible
|
||||
2. consistent with Tidal's approach to pattern
|
||||
3. modular and extensible
|
||||
|
||||
For the future, it is planned to integrate alternative sound engines such as Glicol [@lanChaosprintGlicol2022] and Faust [@FaustProgrammingLanguage2022]. To improve compatibility with Tidal, more Tidal functions are planned to be ported, as well as full compatibility with SuperDirt. Besides sound, other ways to render events are being explored, such as graphical, and choreographic output. We are also looking into alternative ways of editing patterns, including multi-user editing for network music, parsing a novel syntax to escape the constraints of javascript, and developing hardware/e-textile interfaces.
|
||||
|
||||
# Links
|
||||
|
||||
The Strudel REPL is available at <https://strudel.cc>, including an interactive tutorial.
|
||||
The repository is at <https://codeberg.org/uzu/strudel/releases>, all the code is open source under the GPL-3.0 License.
|
||||
|
||||
# Acknowledgments
|
||||
|
||||
Thanks to the Strudel and wider Tidal, live coding, webaudio and free/open source software communities for inspiration and support. Alex McLean's work on this project is supported by a UKRI Future Leaders Fellowship [grant number MR/V025260/1].
|
||||
|
||||
# References
|
||||
@@ -1,97 +0,0 @@
|
||||
**Submission ID:** 8
|
||||
|
||||
**Title:** Strudel: live coding patterns on the Web
|
||||
|
||||
**Status:** Accept
|
||||
|
||||
**Reviewer 1:**
|
||||
|
||||
Author Comments: * Summary of the contribution:\
|
||||
This paper describes Strudel, a Web-based implementation of Tidal Cycles. It is generally a good overview of the system which could help prospective users understand how it works beyond the manual, and it provides many code examples. The most interesting contribution is the comparison between the Haskell and JavaScript features for this case.
|
||||
|
||||
* On theme (1-5):\
|
||||
1
|
||||
|
||||
* Citation quality (1-5):\
|
||||
5
|
||||
|
||||
* Missing references:\
|
||||
not answered
|
||||
|
||||
* Suggested improvements:\
|
||||
This paper is a good introduction to Strudel. The style is mostly illustrative, but it is hard to understand where the Tidal syntax is being introduced vs where the specific Strudel features are used. Thus, the best way to improve it would be to focus on Strudel. Also, it would be good to give a better hint on what output method would be preferable. Also the title of Section 9 should compare Strudel to Tidal or Haskell to JavaScript.
|
||||
|
||||
The paper is driven by examples, but many are a bit difficult to follow, here are some issues:\
|
||||
Section 4 - the mini-notation example does not look terser despite the text.\
|
||||
Section 5 - echo funciton is not used.\
|
||||
Sections 7.11 and 7.12 - the same (mini-notation) example is used so it is not clear what relation there is between transpilation and using mini-notation. Also please reference peggy\
|
||||
Sectin 7.3.2 The sawtooth waveform has been used in all examples, so it would be clearer if it was used here (maybe cutoff as well).
|
||||
|
||||
Generally, beyond the language differences, what does Strudel contribute with respect to Haskell-based Tidal? I would say that there is a lot to be gained in terms of installation, availability and potential for collaboration.
|
||||
|
||||
* Clarity (1-5):\
|
||||
4
|
||||
|
||||
* Corrections required:\
|
||||
No contentious / incorrect claims
|
||||
|
||||
* Other Changes if Published:\
|
||||
not answered
|
||||
|
||||
* Correct Template used?\
|
||||
Yes
|
||||
|
||||
* All materials provided?\
|
||||
Yes
|
||||
|
||||
* Wordcount respected?\
|
||||
Yes
|
||||
|
||||
* Have any deviations, errors or omissions impacted your ability to give a fair review?\
|
||||
No
|
||||
|
||||
**Reviewer 2:**
|
||||
|
||||
Author Comments: * Summary of the contribution:\
|
||||
This proposal presents Strudel, an online, JavaScript-native approach to algorithmic pattern composition that in many ways mirrors TidalCycles. TidalCycles, developed by one of the authors, is a key software piece for live coding. Perhaps the most difficult aspects of Tidal are related to Haskell and Haskell's dependency system that makes it very difficult to install. Haskell in itself is a difficult language to grasp; if Tidal users would like to expand and 'personalise' the possibilities of the software, they would have to get familiar with the particularities of Haskell. JavaScript is a multi-paradigm language that is used for web development can make pattern-based, algorithmic composition more popular. The process of bringing Tidal's paradigm to a dynamic type system seems to be an important part of this research. I enjoy and find very interesting the dialectical process that occurs between Strudel and Tidal, where the implementation of Tidal concepts in Strudel simultaneously transforms Tidal, either by introspection (finding bugs, etc.) or by bringing back to Tidal new insights that are clear in JavaScript. I think moving to TypeScript makes sense; perhaps a small section where the decision to use JavaScript is discussed a little further could be helpful for readers (beyond accessibility). Overall, this paper is clear and presents software that is a key development for live coding and will be a great addition to the next ICLC.
|
||||
|
||||
* On theme (1-5):\
|
||||
4
|
||||
|
||||
* Citation quality (1-5):\
|
||||
5
|
||||
|
||||
* Missing references:\
|
||||
not answered
|
||||
|
||||
* Suggested improvements:\
|
||||
Tidal-Strudel parity seems to be on the immediate horizon, but I wonder if this parity is transient and if the ultimate goal of Strudel is to ultimately diverge from Tidal. Perhaps the project is in its early stages, and this is not clear, but it would be interesting to get some insights on the authors' intentions. Personally, I think that a key discussion that needs to happen in live coding communities and development nodes is that of what is understood as multilingual live coding. Tidal's paradigm is implemented in a number of programming languages (as well as platforms such as Estuary), each with its own set of features and challenges: some are functional reactive programming, type strict oriented, while others are multi-paradigm, dynamic type oriented, etc. This seems to suggest that it is possible for many programming languages to adopt one single understanding of how to make music. Perhaps further considerations should be made as to whether we need one single grammar to name and express all music structures or whether we need environments and software that help difference to proliferate in terms of music/sound art/art idiosyncrasies. Perhaps questions in this direction are beyond the scope of this paper and I hope this comment is taken as productive feedback for the authors.
|
||||
|
||||
* Clarity (1-5):\
|
||||
4
|
||||
|
||||
* Corrections required:\
|
||||
Nothing contentious or incorrect to note.
|
||||
|
||||
* Other Changes if Published:\
|
||||
The example shown on page 3 under "Pattern Example" seems to be different from its explanation. The explanations do not mention scale but mention echo, which is not present in the example. I would double check all the code examples inc ase I missed something like this.
|
||||
|
||||
* Correct Template used?\
|
||||
Yes
|
||||
|
||||
* All materials provided?\
|
||||
Yes
|
||||
|
||||
* Wordcount respected?\
|
||||
Yes
|
||||
|
||||
* Have any deviations, errors or omissions impacted your ability to give a fair review?\
|
||||
no
|
||||
|
||||
* General remarks:\
|
||||
This proposal presents Strudel, an online, JavaScript-native approach to algorithmic pattern composition that in many ways mirrors TidalCycles. TidalCycles, developed by one of the authors, is a key software piece for live coding. Perhaps the most difficult aspects of Tidal are related to Haskell and Haskell's dependency system that makes it very difficult to install. Haskell in itself is a difficult language to grasp; if Tidal users would like to expand and 'personalise' the possibilities of the software, they would have to get familiar with the particularities of Haskell. JavaScript is a multi-paradigm language that can make pattern-based, algorithmic composition more popular. The process of bringing Tidal's paradigm to a dynamic type system seems to be an important part of this research. I enjoy and find very interesting the dialectical process that occurs between Strudel and Tidal, where the implementation of Tidal concepts in Strudel simultaneously transforms Tidal, either by introspection (finding bugs, etc.) or by bringing back to Tidal new insights that are clear in JavaScript. I think moving to TypeScript makes sense; perhaps a small section where the decision to use JavaScript is discussed a little further could be helpful for readers (beyond accessibility). I am curious, did the authors consider PureScript? I can see how, in terms of popularity, PureScript is a lateral move coming from Haskell, but an explicit explanation about the (maybe) obvious candidates would be interesting.\
|
||||
Tidal-Strudel parity seems to be on the immediate horizon, but I wonder if this parity is transient and if the ultimate goal of Strudel is to ultimately diverge from Tidal. Perhaps the project is in its early stages, and this is not clear, but it would be interesting to get some insights on the authors' intentions. Personally, I think that a key discussion that needs to happen in live coding communities and development nodes is that of what is understood as multilingual live coding. Tidal's paradigm is implemented in a number of programming languages (as well as platforms such as Estuary), each with its own set of features and challenges: some are functional reactive programming, type strict oriented, while others are multi-paradigm, dynamic type oriented, etc. This seems to suggest that it is possible for many programming languages to adopt one single understanding of how to make music. Perhaps further considerations should be made as to whether we need one single grammar to name and express all music structures or whether we need environments and software that help difference to proliferate in terms of music/sound art/art idiosyncrasies. Perhaps questions in this direction are beyond the scope of this paper and I hope this last comment is taken as productive feedback for the authors.
|
||||
|
||||
Overall, this paper is clear and presents software that is a key development for live coding and will be a great addition to the next ICLC.
|
||||
|
||||
PS. The example shown on page 3 under "Pattern Example" seems to be different from its explanation. The explanations do not mention scale but mention echo, which is not present in the example.
|
||||
@@ -1,954 +0,0 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<meta http-equiv="Content-Style-Type" content="text/css" />
|
||||
<meta name="generator" content="pandoc" />
|
||||
<meta name="date" content="2022-12-14" />
|
||||
<title>Strudel: live coding patterns on the Web</title>
|
||||
<style type="text/css">
|
||||
code {
|
||||
white-space: pre;
|
||||
}
|
||||
</style>
|
||||
<style type="text/css">
|
||||
pre > code.sourceCode {
|
||||
white-space: pre;
|
||||
position: relative;
|
||||
}
|
||||
pre > code.sourceCode > span {
|
||||
display: inline-block;
|
||||
line-height: 1.25;
|
||||
}
|
||||
pre > code.sourceCode > span:empty {
|
||||
height: 1.2em;
|
||||
}
|
||||
.sourceCode {
|
||||
overflow: visible;
|
||||
}
|
||||
code.sourceCode > span {
|
||||
color: inherit;
|
||||
text-decoration: inherit;
|
||||
}
|
||||
div.sourceCode {
|
||||
margin: 1em 0;
|
||||
}
|
||||
pre.sourceCode {
|
||||
margin: 0;
|
||||
}
|
||||
@media screen {
|
||||
div.sourceCode {
|
||||
overflow: auto;
|
||||
}
|
||||
}
|
||||
@media print {
|
||||
pre > code.sourceCode {
|
||||
white-space: pre-wrap;
|
||||
}
|
||||
pre > code.sourceCode > span {
|
||||
text-indent: -5em;
|
||||
padding-left: 5em;
|
||||
}
|
||||
}
|
||||
pre.numberSource code {
|
||||
counter-reset: source-line 0;
|
||||
}
|
||||
pre.numberSource code > span {
|
||||
position: relative;
|
||||
left: -4em;
|
||||
counter-increment: source-line;
|
||||
}
|
||||
pre.numberSource code > span > a:first-child::before {
|
||||
content: counter(source-line);
|
||||
position: relative;
|
||||
left: -1em;
|
||||
text-align: right;
|
||||
vertical-align: baseline;
|
||||
border: none;
|
||||
display: inline-block;
|
||||
-webkit-touch-callout: none;
|
||||
-webkit-user-select: none;
|
||||
-khtml-user-select: none;
|
||||
-moz-user-select: none;
|
||||
-ms-user-select: none;
|
||||
user-select: none;
|
||||
padding: 0 4px;
|
||||
width: 4em;
|
||||
color: #aaaaaa;
|
||||
}
|
||||
pre.numberSource {
|
||||
margin-left: 3em;
|
||||
border-left: 1px solid #aaaaaa;
|
||||
padding-left: 4px;
|
||||
}
|
||||
div.sourceCode {
|
||||
}
|
||||
@media screen {
|
||||
pre > code.sourceCode > span > a:first-child::before {
|
||||
text-decoration: underline;
|
||||
}
|
||||
}
|
||||
code span.al {
|
||||
color: #ff0000;
|
||||
font-weight: bold;
|
||||
} /* Alert */
|
||||
code span.an {
|
||||
color: #60a0b0;
|
||||
font-weight: bold;
|
||||
font-style: italic;
|
||||
} /* Annotation */
|
||||
code span.at {
|
||||
color: #7d9029;
|
||||
} /* Attribute */
|
||||
code span.bn {
|
||||
color: #40a070;
|
||||
} /* BaseN */
|
||||
code span.bu {
|
||||
color: #008000;
|
||||
} /* BuiltIn */
|
||||
code span.cf {
|
||||
color: #007020;
|
||||
font-weight: bold;
|
||||
} /* ControlFlow */
|
||||
code span.ch {
|
||||
color: #4070a0;
|
||||
} /* Char */
|
||||
code span.cn {
|
||||
color: #880000;
|
||||
} /* Constant */
|
||||
code span.co {
|
||||
color: #60a0b0;
|
||||
font-style: italic;
|
||||
} /* Comment */
|
||||
code span.cv {
|
||||
color: #60a0b0;
|
||||
font-weight: bold;
|
||||
font-style: italic;
|
||||
} /* CommentVar */
|
||||
code span.do {
|
||||
color: #ba2121;
|
||||
font-style: italic;
|
||||
} /* Documentation */
|
||||
code span.dt {
|
||||
color: #902000;
|
||||
} /* DataType */
|
||||
code span.dv {
|
||||
color: #40a070;
|
||||
} /* DecVal */
|
||||
code span.er {
|
||||
color: #ff0000;
|
||||
font-weight: bold;
|
||||
} /* Error */
|
||||
code span.ex {
|
||||
} /* Extension */
|
||||
code span.fl {
|
||||
color: #40a070;
|
||||
} /* Float */
|
||||
code span.fu {
|
||||
color: #06287e;
|
||||
} /* Function */
|
||||
code span.im {
|
||||
color: #008000;
|
||||
font-weight: bold;
|
||||
} /* Import */
|
||||
code span.in {
|
||||
color: #60a0b0;
|
||||
font-weight: bold;
|
||||
font-style: italic;
|
||||
} /* Information */
|
||||
code span.kw {
|
||||
color: #007020;
|
||||
font-weight: bold;
|
||||
} /* Keyword */
|
||||
code span.op {
|
||||
color: #666666;
|
||||
} /* Operator */
|
||||
code span.ot {
|
||||
color: #007020;
|
||||
} /* Other */
|
||||
code span.pp {
|
||||
color: #bc7a00;
|
||||
} /* Preprocessor */
|
||||
code span.sc {
|
||||
color: #4070a0;
|
||||
} /* SpecialChar */
|
||||
code span.ss {
|
||||
color: #bb6688;
|
||||
} /* SpecialString */
|
||||
code span.st {
|
||||
color: #4070a0;
|
||||
} /* String */
|
||||
code span.va {
|
||||
color: #19177c;
|
||||
} /* Variable */
|
||||
code span.vs {
|
||||
color: #4070a0;
|
||||
} /* VerbatimString */
|
||||
code span.wa {
|
||||
color: #60a0b0;
|
||||
font-weight: bold;
|
||||
font-style: italic;
|
||||
} /* Warning */
|
||||
</style>
|
||||
<link rel="stylesheet" href="css/iclc.css" />
|
||||
</head>
|
||||
<body>
|
||||
<div id="header">
|
||||
<h1 class="title">Strudel: live coding patterns on the Web</h1>
|
||||
<ul id="authorlist">
|
||||
<li>true</li>
|
||||
<li>true</li>
|
||||
</ul>
|
||||
<h3 class="date">2022-12-14</h3>
|
||||
</div>
|
||||
|
||||
<h2 class="abstract">Abstract</h2>
|
||||
<div id="abstract">
|
||||
<p>
|
||||
This paper introduces Strudel, which brings the TidalCycles approach to live coding algorithmic patterns to
|
||||
native JavaScript and the web. We begin by giving a little background of the first year of development, before
|
||||
sharing some detail about its implementation and examples of use. We go on to outline the wide range of
|
||||
synthesis and other outputs available in Strudel, including WebAudio, MIDI, OSC (for SuperDirt), WebSerial and
|
||||
CSound, and introduce Strudel’s REPL live editor, including its built-in visualisations. We then compare Strudel
|
||||
with Tidal, the trade-offs involved between JavaScript and Haskell, and the unique capabilities offered by
|
||||
Strudel for aligning patterns.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<h1 data-number="1" id="introduction"><span class="header-section-number">1</span> Introduction</h1>
|
||||
<p>
|
||||
In the following paper, we introduce <em>Strudel</em>, an alternative implementation of the TidalCycles (or
|
||||
‘Tidal’ for short) live coding system, using the JavaScript programming language. Strudel is an attempt to make
|
||||
live coding more accessible, by creating a system that runs entirely in the browser, while opening Tidal’s
|
||||
approach to algorithmic patterns
|
||||
<span class="citation" data-cites="mcleanAlgorithmicPattern2020a">(Mclean 2020)</span> up to modern audio/visual
|
||||
web technologies. The Strudel REPL is a live code editor dedicated to manipulating patterns while they play, with
|
||||
builtin visual feedback. While Strudel is written in JavaScript, the API is optimized for simplicity and
|
||||
readability by applying code transformations on the syntax tree level, allowing language operations that would
|
||||
otherwise be impossible. The application supports multiple ways to output sound, including Tone.js, Web Audio
|
||||
Nodes, OSC (Open Sound Control) messages, Web Serial, Web MIDI and Csound. The project is split into multiple
|
||||
packages, allowing granular reuse in other applications. Apart from TidalCycles, Strudel draws inspiration from
|
||||
many prior existing projects like TidalVortex
|
||||
<span class="citation" data-cites="mcleanTidalVortexZero2022">(McLean et al. 2022)</span>, Gibber
|
||||
<span class="citation" data-cites="robertsGibberLiveCoding2012">(Roberts and Kuchera-morin 2012)</span>, Estuary
|
||||
<span class="citation" data-cites="ogbornEstuaryBrowserbasedCollaborative2017">(Ogborn et al. 2017)</span>, Hydra
|
||||
<span class="citation" data-cites="jackHydra2022">(Jack [2022] 2022)</span>, Ocarina
|
||||
<span class="citation" data-cites="solomonPurescriptocarina2022">(Solomon [2021] 2022)</span> and Feedforward
|
||||
<span class="citation" data-cites="mcleanFeedforward2020">(McLean 2020)</span>. This paper expands the Strudel
|
||||
Demo paper for the Web Audio Conference 2022
|
||||
<span class="citation" data-cites="StrudelWAC2022">(Roos and McLean 2022)</span>.
|
||||
</p>
|
||||
<p>
|
||||
The first tentative commit to the Strudel project was on 22nd January 2022 by Alex McLean, with the core
|
||||
representation implemented over the following few days. Although this was his first attempt at a JavaScript-based
|
||||
application, by 27th January, Alex had managed to upload the initial version to the ‘npm’ javascript package
|
||||
database, sharing with the wider community for comment. By 4th February, Felix Roos had discovered Strudel and
|
||||
contributed a ‘REPL’ user interface to it, and then contributed a scheduler the next day, so that Strudel could
|
||||
already make sound. At this point, Alex and Felix shared ownership to the repository, and the project has since
|
||||
proved to be a productive confluence of Felix’s own work into music representation and visualisation, with Alex’s
|
||||
experience with making Tidal. Felix has since become the primary contributor to Strudel, with Alex continuing to
|
||||
jump between developing both Strudel and Tidal. Aspects of Strudel’s development have therefore fed back into
|
||||
TidalCycles, and both systems have maintained a shared conceptual underpinning. We plan to continue working
|
||||
towards feature parity between these systems, although within the syntactical trade-offs and library ecosystems of
|
||||
JavaScript and Haskell, some divergence is inevitable and healthy.
|
||||
</p>
|
||||
<p>
|
||||
Over the first year of its life, Strudel is now a fully-fledged live coding environment, porting Tidal’s core
|
||||
represention of patterns, pattern transformations, and mininotation for polymetric sequences, combined with a
|
||||
wealth of features for synthesising and visualising those patterns.
|
||||
</p>
|
||||
<h1 data-number="2" id="from-tidal-to-strudel-and-back">
|
||||
<span class="header-section-number">2</span> From Tidal to Strudel and back
|
||||
</h1>
|
||||
<p>
|
||||
As mentioned above, the original Tidal is implemented as a domain specific language (DSL) embedded in the Haskell
|
||||
pure functional programming language, and takes advantage of Haskell’s terse syntax and advanced, ‘strong’ type
|
||||
system. JavaScript on the other hand, is a multi-paradigm programming language, with a dynamic type system.
|
||||
Because Tidal leans heavily on many of Haskell’s more unique features, it was not always clear that it could
|
||||
meaningfully be ported to a multi-paradigm scripting language. However, this possibility was already demonstrated
|
||||
with an earlier port to Python [TidalVortex;
|
||||
<span class="citation" data-cites="mcleanTidalVortexZero2022">McLean et al. (2022)</span>], and we have now
|
||||
successfully implemented Tidal’s pure functional representation of patterns in Strudel, including partial
|
||||
application, currying, and the functor, applicative and monadic structures that underlie Tidal’s expressive
|
||||
pattern transformations. The result is a terse and highly composable system, where everything is either a pattern,
|
||||
or a function for combining and manipulating patterns, offering a rich creative ground for exploration.
|
||||
</p>
|
||||
<p>
|
||||
This development process has been far from a one-way port, however. The process of porting Tidal’s concepts has
|
||||
also opened up new possibilities, some just from revisiting every design decision, and some from the particular
|
||||
affordances and constraints offered by JavaScript. This has lead to new features (and indeed bugfixes) that have
|
||||
found their way back to Tidal where appropriate, and ongoing work that we will return to in the conclusion of this
|
||||
paper.
|
||||
</p>
|
||||
<h1 data-number="3" id="representing-patterns">
|
||||
<span class="header-section-number">3</span> Representing Patterns
|
||||
</h1>
|
||||
<p>
|
||||
Patterns are the essence of Tidal. Its patterns are abstract entities that represent flows of time as functions,
|
||||
adapting a technique called pure functional reactive programming. Taking a time span as its input, a Pattern can
|
||||
output a set of events that happen within that time span. It depends on the structure of the Pattern how the
|
||||
events are located in time. From now on, this process of generating events from a time span will be called
|
||||
<strong>querying</strong>. Example:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb1">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="kw">const</span> pattern <span class="op">=</span> <span class="fu">sequence</span>(c3<span class="op">,</span> [e3<span class="op">,</span> g3])</span>
|
||||
<span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a><span class="kw">const</span> events <span class="op">=</span> pattern<span class="op">.</span><span class="fu">queryArc</span>(<span class="dv">0</span><span class="op">,</span> <span class="dv">1</span>)</span>
|
||||
<span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a><span class="bu">console</span><span class="op">.</span><span class="fu">log</span>(events<span class="op">.</span><span class="fu">map</span>(e <span class="kw">=></span> e<span class="op">.</span><span class="fu">show</span>()))</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
In this example, we create a pattern using the <code>sequence</code> function and <strong>query</strong> it for
|
||||
the time span from <code>0</code> to <code>1</code>. Those numbers represent units of time called
|
||||
<strong>cycles</strong>. The length of one cycle depends on the tempo, which defaults to one cycle per second. The
|
||||
resulting events are:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb2">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a>[{ <span class="dt">value</span><span class="op">:</span> <span class="st">'c3'</span><span class="op">,</span> <span class="dt">begin</span><span class="op">:</span> <span class="dv">0</span><span class="op">,</span> <span class="dt">end</span><span class="op">:</span> <span class="dv">1</span><span class="op">/</span><span class="dv">2</span> }<span class="op">,</span></span>
|
||||
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a>{ <span class="dt">value</span><span class="op">:</span> <span class="st">'e3'</span><span class="op">,</span> <span class="dt">begin</span><span class="op">:</span> <span class="dv">1</span><span class="op">/</span><span class="dv">2</span><span class="op">,</span> <span class="dt">end</span><span class="op">:</span> <span class="dv">3</span><span class="op">/</span><span class="dv">4</span> }<span class="op">,</span></span>
|
||||
<span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a>{ <span class="dt">value</span><span class="op">:</span> <span class="st">'g3'</span><span class="op">,</span> <span class="dt">begin</span><span class="op">:</span> <span class="dv">3</span><span class="op">/</span><span class="dv">4</span><span class="op">,</span> <span class="dt">end</span><span class="op">:</span> <span class="dv">1</span> }]</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
Each event has a value, a begin time and an end time, where time is represented as a fraction. In the above case,
|
||||
the events are placed in sequential order, where c3 takes the first half, and e3 and g3 together take the second
|
||||
half. This temporal placement is the result of the <code>sequence</code> function, which divides its arguments
|
||||
equally over one cycle. If an argument is an array, the same rule applies to that part of the cycle. In the
|
||||
example, e3 and g3 are divided equally over the second half of the whole cycle.
|
||||
</p>
|
||||
<p>
|
||||
The above examples do not represent how Strudel is used in practice. In the live coding editor, the user only has
|
||||
to type in the pattern itself, the querying will be handled by the scheduler. The scheduler will repeatedly query
|
||||
the pattern for events, which are then scheduled as sound synthesis or other event triggers. Also, the above event
|
||||
data structure has been simplified for readability.
|
||||
</p>
|
||||
<figure>
|
||||
<img
|
||||
src="images/strudel-screenshot2.png"
|
||||
style="width: 60%"
|
||||
alt="Screenshot of the Strudel ‘REPL’ live coding editor, including piano-roll visualisation."
|
||||
/>
|
||||
<figcaption aria-hidden="true">
|
||||
Screenshot of the Strudel ‘REPL’ live coding editor, including piano-roll visualisation.
|
||||
</figcaption>
|
||||
</figure>
|
||||
<h1 data-number="4" id="making-patterns"><span class="header-section-number">4</span> Making Patterns</h1>
|
||||
<p>
|
||||
In practice, the end-user live coder will not deal with constructing patterns directly, but will rather build
|
||||
patterns using Strudel’s extensive combinator library to create, combine and transform patterns.
|
||||
</p>
|
||||
<p>
|
||||
The live coder will rarely use the <code>sequence</code> function as seen above, as sequencing is implicit in many
|
||||
functions. For example in the following, the <code>note</code> function constructs a pattern of notes, sequencing
|
||||
its arguments in the same manner as the previous example.
|
||||
</p>
|
||||
<div class="sourceCode" id="cb3">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="fu">note</span>(c3<span class="op">,</span> [e3<span class="op">,</span> g3])</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
Perhaps more often, they will use the mini-notation for even terser notation of rhythmic sequences: [^This last
|
||||
example is also valid Tidal code, albeit the parenthesis is not required in its Haskell syntax in this case. Tidal
|
||||
does not support passing sequences as lists directly to the <code>note</code> function, however.].
|
||||
</p>
|
||||
<div class="sourceCode" id="cb4">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="fu">note</span>(<span class="st">"c3 [e3 g3]"</span>)</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
Such sequences are often treated only a starting point for manipulation, where they then undergo pattern
|
||||
transformations such as repetition, symmetry, interference/combination or randomisation, potentially at multiple
|
||||
timescales. Because Strudel patterns are represented as pure functions of time rather than as data structures,
|
||||
very long and complex generative results can be represented and manipulated without having to store the resulting
|
||||
sequences in memory.
|
||||
</p>
|
||||
<h1 data-number="5" id="pattern-example"><span class="header-section-number">5</span> Pattern Example</h1>
|
||||
<p>
|
||||
The following example showcases how patterns can be utilized to create musical complexity from simple parts, using
|
||||
repetition and interference:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb5">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a><span class="st">"<0 2 [4 6](3,4,1) 3>"</span></span>
|
||||
<span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a><span class="op">.</span><span class="fu">off</span>(<span class="dv">1</span><span class="op">/</span><span class="dv">4</span><span class="op">,</span> <span class="fu">add</span>(<span class="dv">2</span>))</span>
|
||||
<span id="cb5-3"><a href="#cb5-3" aria-hidden="true" tabindex="-1"></a><span class="op">.</span><span class="fu">off</span>(<span class="dv">1</span><span class="op">/</span><span class="dv">2</span><span class="op">,</span> <span class="fu">add</span>(<span class="dv">6</span>))</span>
|
||||
<span id="cb5-4"><a href="#cb5-4" aria-hidden="true" tabindex="-1"></a><span class="op">.</span><span class="fu">scale</span>(<span class="st">'D minor'</span>)</span>
|
||||
<span id="cb5-5"><a href="#cb5-5" aria-hidden="true" tabindex="-1"></a><span class="op">.</span><span class="fu">legato</span>(<span class="op">.</span><span class="dv">25</span>)</span>
|
||||
<span id="cb5-6"><a href="#cb5-6" aria-hidden="true" tabindex="-1"></a><span class="op">.</span><span class="fu">note</span>()<span class="op">.</span><span class="fu">s</span>(<span class="st">"sawtooth square"</span>)</span>
|
||||
<span id="cb5-7"><a href="#cb5-7" aria-hidden="true" tabindex="-1"></a><span class="op">.</span><span class="fu">delay</span>(<span class="op">.</span><span class="dv">8</span>)<span class="op">.</span><span class="fu">delaytime</span>(<span class="op">.</span><span class="dv">125</span>)</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
The pattern starts with a rhythm of numbers in mini notation, which are later interpreted inside the scale of D
|
||||
minor. The first line could also be expressed without mini notation:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb6">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="fu">cat</span>(<span class="dv">0</span><span class="op">,</span> <span class="dv">2</span><span class="op">,</span> [<span class="dv">4</span><span class="op">,</span> <span class="dv">6</span>]<span class="op">.</span><span class="fu">euclid</span>(<span class="dv">3</span><span class="op">,</span> <span class="dv">4</span><span class="op">,</span> <span class="dv">1</span>)<span class="op">,</span> <span class="dv">3</span>)</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
These numbers then undergo various pattern transformations. Here is a short description of all the functions used:
|
||||
</p>
|
||||
<ul>
|
||||
<li><code>cat</code>: play elements sequentially, where each lasts one cycle</li>
|
||||
<li><code>brackets</code>: elements inside brackets are divided equally over the time of their parent</li>
|
||||
<li>
|
||||
<code>.euclid(p, s, o)</code>: place p pulses evenly over s steps, with offset o
|
||||
<span class="citation" data-cites="toussaintEuclideanAlgorithmGenerates2005">(Toussaint 2005)</span>
|
||||
</li>
|
||||
<li>
|
||||
<code>.off(n, f)</code>: layers a pattern on top of itself, with the new layer offset by n cycles, and with
|
||||
function f applied
|
||||
</li>
|
||||
<li><code>.legato(n)</code>: multiply the duration of all events in a pattern by a factor of n</li>
|
||||
<li>
|
||||
<code>.echo(t, n, v)</code>: copy each event t times, with n cycles in between each copy, decreasing velocity by
|
||||
v
|
||||
</li>
|
||||
<li><code>.note()</code>: interpretes values as notes</li>
|
||||
<li><code>.s(name)</code>: play back each event with the given sound</li>
|
||||
<li><code>.delay(wet)</code>: add delay</li>
|
||||
<li><code>.delaytime(t)</code>: set delay time</li>
|
||||
</ul>
|
||||
<p>Much of the above will be familiar to Tidal users.</p>
|
||||
<!-- This example shows some of Strudel's unique support for chords and transposition familiar to students of Western music theory. This differs a little from Tidal's approach and thanks to the integration of the javascript library XXX (*TODO* ? or is this all your work Felix?), Strudel's support for tonal transformations such as voice leading is perhaps respects more advanced than Tidal. -->
|
||||
<h1 data-number="6" id="ways-to-make-sound-and-other-events">
|
||||
<span class="header-section-number">6</span> Ways to make Sound (and other events)
|
||||
</h1>
|
||||
<p>To generate sound, Strudel supports bindings for different outputs:</p>
|
||||
<ul>
|
||||
<li>Tone.js (deprecated)</li>
|
||||
<li>Web Audio API</li>
|
||||
<li>WebDirt, a js recreation of Tidal’s <em>Dirt</em> sample engine (deprecated)</li>
|
||||
<li>OSC via osc-js, compatible with superdirt</li>
|
||||
<li>Csound via the Csound WebAssembly build</li>
|
||||
<li>MIDI via WebMIDI</li>
|
||||
<li>Serial via WebSerial</li>
|
||||
</ul>
|
||||
<p>
|
||||
At first, we used Tone.js as sound output, but it proved to be limited for the use case of Strudel, where each
|
||||
individual event could potentially have a completely different audio graph. While the Web Audio API takes a
|
||||
<em>fire-and-forget</em> approach, creating a lot of Tone.js instruments and effects causes performance issues
|
||||
quickly. For that reason, we chose to search for alternatives.
|
||||
</p>
|
||||
<p>
|
||||
Strudel’s new default output uses the Web Audio API to create a new audio graph for each event. It currently
|
||||
supports basic oscillators, sample playback, various effects and an experimental support for soundfonts.
|
||||
</p>
|
||||
<p>
|
||||
WebDirt <span class="citation" data-cites="ogbornDktr0WebDirt2022">(Ogborn [2016] 2022)</span> was created as part
|
||||
of the Estuary Live Coding System
|
||||
<span class="citation" data-cites="ogbornEstuaryBrowserbasedCollaborative2017">(Ogborn et al. 2017)</span>, and
|
||||
proved to be a solid choice for handling samples in Strudel as well. We are however focused on working more
|
||||
directly with the Web Audio API to be able to integrate new features more tightly.
|
||||
</p>
|
||||
<p>
|
||||
Using the OSC protocol via Strudel’s provided Node.js-based OSC proxy server, it is possible to send network
|
||||
messages to trigger events. This is mainly used to render sound using SuperDirt
|
||||
<span class="citation" data-cites="SuperDirt2022">(<em>SuperDirt</em> [2015] 2022)</span>, which is the
|
||||
well-developed Supercollider-based synthesis framework that Tidal live coders generally use as standard.
|
||||
</p>
|
||||
<p>
|
||||
Recently, the experimental integration of Csound proved to bring a new dimension of sound design capabilities to
|
||||
Strudel. Thanks to the WebAssembly distribution of this classic system
|
||||
<span class="citation" data-cites="CsoundWebAssembly">(Yi, Lazzarini, and Costello 2018)</span>, Csound
|
||||
‘orchestra’ synthesisers can be embedded in and then patterned with Strudel code.
|
||||
</p>
|
||||
<p>
|
||||
MIDI output can also be used to send MIDI messages to either external instruments or to other programs on the same
|
||||
device. Unlike OSC, Strudel is able to send MIDI directly without requiring additional proxy software, but only
|
||||
from web browsers that support it (at the time of writing, this means Chromium-based browsers).
|
||||
</p>
|
||||
<p>
|
||||
Finally, Strudel supports Serial output, for example to trigger events via microcontrollers. This has already been
|
||||
explored for robot choreography by Kate Sicchio and Alex McLean, via a performance presented at the International
|
||||
Conference on Live Interfaces 2022.
|
||||
</p>
|
||||
<h1 data-number="7" id="the-strudel-repl"><span class="header-section-number">7</span> The Strudel REPL</h1>
|
||||
<p>
|
||||
While Strudel can be used as a library in any JavaScript codebase, its main, reference user interface is the
|
||||
Strudel REPL[^REPL stands for read, evaluate, print/play, loop. It is friendly jargon for an interactive
|
||||
programming interface from computing heritage, usually for a commandline interface but also applied to live coding
|
||||
editors.], which is a browser-based live coding environment. This live code editor is dedicated to manipulating
|
||||
Strudel patterns while they play. The REPL features built-in visual feedback, which highlights which elements in
|
||||
the patterned (mini-notation) sequences are influencing the event that is currently being played. This feedback is
|
||||
designed to support both learning and live use of Strudel.
|
||||
</p>
|
||||
<p>
|
||||
Besides a UI for playback control and meta information, the main part of the REPL interface is the code editor
|
||||
powered by CodeMirror. In it, the user can edit and evaluate pattern code live, using one of the available
|
||||
synthesis outputs to create music and/or sound art. The control flow of the REPL follows 3 basic steps:
|
||||
</p>
|
||||
<ol type="1">
|
||||
<li>
|
||||
The user writes and updates code. Each update transpiles and evaluates it to create a
|
||||
<code>Pattern</code> instance
|
||||
</li>
|
||||
<li>
|
||||
While the REPL is running, the <code>Scheduler</code> queries the active <code>Pattern</code> by a regular
|
||||
interval, generating <code>Events</code> (also known as <code>Haps</code> in Strudel) for the next time span.
|
||||
</li>
|
||||
<li>
|
||||
For each scheduling tick, all generated <code>Events</code> are triggered by calling their
|
||||
<code>onTrigger</code> method, which is set by the output.
|
||||
</li>
|
||||
</ol>
|
||||
<figure>
|
||||
<img
|
||||
src="https://github.com/tidalcycles/strudel/raw/talk/talk/public/strudelflow.png?raw=true"
|
||||
style="width: 43%"
|
||||
alt="REPL control flow"
|
||||
/>
|
||||
<figcaption aria-hidden="true">REPL control flow</figcaption>
|
||||
</figure>
|
||||
<h2 data-number="7.1" id="user-code"><span class="header-section-number">7.1</span> User Code</h2>
|
||||
<p>To create a <code>Pattern</code> from the user code, two steps are needed:</p>
|
||||
<ol type="1">
|
||||
<li>Transpile the JS input code to make it functional</li>
|
||||
<li>Evaluate the transpiled code</li>
|
||||
</ol>
|
||||
<h3 data-number="7.1.1" id="transpilation-evaluation">
|
||||
<span class="header-section-number">7.1.1</span> Transpilation & Evaluation
|
||||
</h3>
|
||||
<p>
|
||||
In the JavaScript world, using transpilation is a common practise to be able to use language features that are not
|
||||
supported by the base language. Tools like <code>babel</code> will transpile code that contains unsupported
|
||||
language features into a version of the code without those features.
|
||||
</p>
|
||||
<p>
|
||||
In the same tradition, Strudel can add a transpilation step to simplify the user code in the context of live
|
||||
coding. For example, the Strudel REPL lets the user create mini notation patterns using just double quoted
|
||||
strings, while single quoted strings remain what they are:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb7">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a><span class="st">"c3 [e3 g3]*2"</span></span></code></pre>
|
||||
</div>
|
||||
<p>is transpiled to:</p>
|
||||
<div class="sourceCode" id="cb8">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb8-1"><a href="#cb8-1" aria-hidden="true" tabindex="-1"></a><span class="fu">mini</span>(<span class="st">"c3 [e3 g3]*2"</span>)<span class="op">.</span><span class="fu">withMiniLocation</span>([<span class="dv">1</span><span class="op">,</span><span class="dv">0</span><span class="op">,</span><span class="dv">0</span>]<span class="op">,</span>[<span class="dv">1</span><span class="op">,</span><span class="dv">14</span><span class="op">,</span><span class="dv">14</span>])</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
Here, the string is wrapped in <code>mini</code>, which will create a pattern from a mini notation string.
|
||||
Additionally, the <code>withMiniLocation</code> method passes the original source code location of the string to
|
||||
the pattern, which enables highlighting active events.
|
||||
</p>
|
||||
<p>
|
||||
Other convenient features like pseudo variables, operator overloading and top level await are possible with
|
||||
transpilation.
|
||||
</p>
|
||||
<p>After the transpilation, the code is ready to be evaluated into a <code>Pattern</code>.</p>
|
||||
<p>
|
||||
Behind the scenes, the user code string is parsed with <code>acorn</code>, turning it into an Abstract Syntax Tree
|
||||
(AST). The AST allows changing the structure of the code before generating the transpiled version using
|
||||
<code>escodegen</code>.
|
||||
</p>
|
||||
<h3 data-number="7.1.2" id="mini-notation"><span class="header-section-number">7.1.2</span> Mini Notation</h3>
|
||||
<p>
|
||||
While the transpilation allows JavaScript to express Patterns in a less verbose way, it is still preferable to use
|
||||
the Mini Notation as a more compact way to express rhythm. Strudel aims to provide the same Mini Notation features
|
||||
and syntax as used in Tidal.
|
||||
</p>
|
||||
<p>
|
||||
The Mini Notation parser is implemented using <code>peggy</code>, which allows generating performant parsers for
|
||||
Domain Specific Languages (DSLs) using a concise grammar notation. The generated parser turns the Mini Notation
|
||||
string into an AST which is used to call the respective Strudel functions with the given structure. For example,
|
||||
<code>"c3 [e3 g3]*2"</code> will result in the following calls:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb9">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a><span class="fu">seq</span>(</span>
|
||||
<span id="cb9-2"><a href="#cb9-2" aria-hidden="true" tabindex="-1"></a> <span class="fu">reify</span>(<span class="st">'c3'</span>)<span class="op">.</span><span class="fu">withLocation</span>([<span class="dv">1</span><span class="op">,</span><span class="dv">1</span><span class="op">,</span><span class="dv">1</span>]<span class="op">,</span> [<span class="dv">1</span><span class="op">,</span><span class="dv">4</span><span class="op">,</span><span class="dv">4</span>])<span class="op">,</span></span>
|
||||
<span id="cb9-3"><a href="#cb9-3" aria-hidden="true" tabindex="-1"></a> <span class="fu">seq</span>(</span>
|
||||
<span id="cb9-4"><a href="#cb9-4" aria-hidden="true" tabindex="-1"></a> <span class="fu">reify</span>(<span class="st">'e3'</span>)<span class="op">.</span><span class="fu">withLocation</span>([<span class="dv">1</span><span class="op">,</span><span class="dv">5</span><span class="op">,</span><span class="dv">5</span>]<span class="op">,</span> [<span class="dv">1</span><span class="op">,</span><span class="dv">8</span><span class="op">,</span><span class="dv">8</span>])<span class="op">,</span></span>
|
||||
<span id="cb9-5"><a href="#cb9-5" aria-hidden="true" tabindex="-1"></a> <span class="fu">reify</span>(<span class="st">'g3'</span>)<span class="op">.</span><span class="fu">withLocation</span>([<span class="dv">1</span><span class="op">,</span><span class="dv">8</span><span class="op">,</span><span class="dv">8</span>]<span class="op">,</span> [<span class="dv">1</span><span class="op">,</span><span class="dv">10</span><span class="op">,</span><span class="dv">10</span>])<span class="op">,</span></span>
|
||||
<span id="cb9-6"><a href="#cb9-6" aria-hidden="true" tabindex="-1"></a> )<span class="op">.</span><span class="fu">fast</span>(<span class="dv">2</span>)</span>
|
||||
<span id="cb9-7"><a href="#cb9-7" aria-hidden="true" tabindex="-1"></a>)</span></code></pre>
|
||||
</div>
|
||||
<h3 data-number="7.1.3" id="highlighting-locations">
|
||||
<span class="header-section-number">7.1.3</span> Highlighting Locations
|
||||
</h3>
|
||||
<p>
|
||||
As seen in the examples above, both the JS and the Mini Notation parser add source code locations using
|
||||
<code>withMiniLocation</code> and <code>withLocation</code> methods. While the JS parser adds locations relative
|
||||
to the user code as a whole, the Mini Notation adds locations relative to the position of the mini notation
|
||||
string. The absolute location of elements within Mini Notation can be calculated by simply adding both locations
|
||||
together. This absolute location can be used to highlight active events in real time.
|
||||
</p>
|
||||
<h2 data-number="7.2" id="scheduling-events"><span class="header-section-number">7.2</span> Scheduling Events</h2>
|
||||
<p>
|
||||
After an instance of <code>Pattern</code> is obtained from the user code, it is used by the scheduler to get
|
||||
queried for events. Once started, the scheduler runs at a fixed interval to query active pattern for events
|
||||
withing the current interval’s time span. A simplified implementation looks like this:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb10">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb10-1"><a href="#cb10-1" aria-hidden="true" tabindex="-1"></a><span class="kw">let</span> pattern <span class="op">=</span> <span class="fu">seq</span>(<span class="st">'c3'</span><span class="op">,</span> [<span class="st">'e3'</span><span class="op">,</span> <span class="st">'g3'</span>])<span class="op">;</span> <span class="co">// pattern from user</span></span>
|
||||
<span id="cb10-2"><a href="#cb10-2" aria-hidden="true" tabindex="-1"></a><span class="kw">let</span> interval <span class="op">=</span> <span class="fl">0.5</span><span class="op">;</span> <span class="co">// query interval in seconds</span></span>
|
||||
<span id="cb10-3"><a href="#cb10-3" aria-hidden="true" tabindex="-1"></a><span class="kw">let</span> time <span class="op">=</span> <span class="dv">0</span><span class="op">;</span> <span class="co">// beginning of current time span</span></span>
|
||||
<span id="cb10-4"><a href="#cb10-4" aria-hidden="true" tabindex="-1"></a><span class="kw">let</span> minLatency <span class="op">=</span> <span class="op">.</span><span class="dv">1</span><span class="op">;</span> <span class="co">// min time before a hap should trigger</span></span>
|
||||
<span id="cb10-5"><a href="#cb10-5" aria-hidden="true" tabindex="-1"></a><span class="pp">setInterval</span>(() <span class="kw">=></span> {</span>
|
||||
<span id="cb10-6"><a href="#cb10-6" aria-hidden="true" tabindex="-1"></a> <span class="kw">const</span> haps <span class="op">=</span> pattern<span class="op">.</span><span class="fu">queryArc</span>(time<span class="op">,</span> time <span class="op">+</span> interval)<span class="op">;</span></span>
|
||||
<span id="cb10-7"><a href="#cb10-7" aria-hidden="true" tabindex="-1"></a> time <span class="op">+=</span> interval<span class="op">;</span> <span class="co">// increment time</span></span>
|
||||
<span id="cb10-8"><a href="#cb10-8" aria-hidden="true" tabindex="-1"></a> haps<span class="op">.</span><span class="fu">forEach</span>((hap) <span class="kw">=></span> {</span>
|
||||
<span id="cb10-9"><a href="#cb10-9" aria-hidden="true" tabindex="-1"></a> <span class="kw">const</span> deadline <span class="op">=</span> hap<span class="op">.</span><span class="at">whole</span><span class="op">.</span><span class="at">begin</span> <span class="op">-</span> time <span class="op">+</span> minLatency<span class="op">;</span></span>
|
||||
<span id="cb10-10"><a href="#cb10-10" aria-hidden="true" tabindex="-1"></a> <span class="fu">onTrigger</span>(hap<span class="op">,</span> deadline<span class="op">,</span> duration)<span class="op">;</span></span>
|
||||
<span id="cb10-11"><a href="#cb10-11" aria-hidden="true" tabindex="-1"></a> })<span class="op">;</span></span>
|
||||
<span id="cb10-12"><a href="#cb10-12" aria-hidden="true" tabindex="-1"></a>}<span class="op">,</span> interval <span class="op">*</span> <span class="dv">1000</span>)<span class="op">;</span> <span class="co">// query each "interval" seconds</span></span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
Note that the above code is simplified for illustrative purposes. The actual implementation has to work around
|
||||
imprecise callbacks of <code>setInterval</code>. More about the implementation details can be read in
|
||||
<a href="https://loophole-letters.vercel.app/web-audio-scheduling">this blog post</a>.
|
||||
</p>
|
||||
<p>
|
||||
The fact that <code>Pattern.queryArc</code> is a pure function that maps a time span to a set of events allows us
|
||||
to choose any interval we like without changing the resulting output. It also means that when the pattern is
|
||||
changed from outside, the next scheduling callback will work with the new pattern, keeping its clock running.
|
||||
</p>
|
||||
<p>
|
||||
The latency between the time the pattern is evaluated and the change is heard is between
|
||||
<code>minLatency</code> and <code>interval + minLatency</code>, in our example between 100ms and 600ms. In
|
||||
Strudel, the current query interval is 50ms with a minLatency of 100ms, meaning the latency is between 50ms and
|
||||
150ms.
|
||||
</p>
|
||||
<h2 data-number="7.3" id="output"><span class="header-section-number">7.3</span> Output</h2>
|
||||
<p>
|
||||
The last step is to trigger each event in the chosen output. This is where the given time and value of each event
|
||||
is used to generate audio or any other form of time based output. The default output of the Strudel REPL is the
|
||||
WebAudio output. To understand what an output does, we first have to understand what control parameters are.
|
||||
</p>
|
||||
<h3 data-number="7.3.1" id="control-parameters">
|
||||
<span class="header-section-number">7.3.1</span> Control Parameters
|
||||
</h3>
|
||||
<p>
|
||||
To be able to manipulate multiple aspects of sound in parallel, so called control parameters are used to shape the
|
||||
value of each event. Example:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb11">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="fu">note</span>(<span class="st">"c3 e3"</span>)<span class="op">.</span><span class="fu">cutoff</span>(<span class="dv">1000</span>)<span class="op">.</span><span class="fu">s</span>(<span class="st">'sawtooth'</span>)</span>
|
||||
<span id="cb11-2"><a href="#cb11-2" aria-hidden="true" tabindex="-1"></a> <span class="op">.</span><span class="fu">queryArc</span>(<span class="dv">0</span><span class="op">,</span> <span class="dv">1</span>)<span class="op">.</span><span class="fu">map</span>(hap <span class="kw">=></span> hap<span class="op">.</span><span class="at">value</span>)</span>
|
||||
<span id="cb11-3"><a href="#cb11-3" aria-hidden="true" tabindex="-1"></a><span class="co">/* [</span></span>
|
||||
<span id="cb11-4"><a href="#cb11-4" aria-hidden="true" tabindex="-1"></a><span class="co"> { note: 'c3', cutoff: 1000, s: 'sawtooth' }</span></span>
|
||||
<span id="cb11-5"><a href="#cb11-5" aria-hidden="true" tabindex="-1"></a><span class="co"> { note: 'e3', cutoff: 1000, s: 'sawtooth' }</span></span>
|
||||
<span id="cb11-6"><a href="#cb11-6" aria-hidden="true" tabindex="-1"></a><span class="co">] */</span></span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
Here, the control parameter functions <code>note</code>, <code>cutoff</code> and <code>s</code> are used, where
|
||||
each controls a different property in the value object. Each control parameter function accepts a primitive value,
|
||||
a list of values to be sequenced into a <code>Pattern</code>, or a <code>Pattern</code>. In the example,
|
||||
<code>note</code> gets a <code>Pattern</code> from a Mini Notation expression (double quoted), while
|
||||
<code>cutoff</code> and <code>s</code> are given a <code>Number</code> and a (single quoted)
|
||||
<code>String</code> respectively.
|
||||
</p>
|
||||
<p>
|
||||
Strudel comes with a large default set of control parameter functions that are based on the ones used by Tidal and
|
||||
SuperDirt, focusing on music and audio terminology. It is however possible to create custom control paramters for
|
||||
any purpose:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb12">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb12-1"><a href="#cb12-1" aria-hidden="true" tabindex="-1"></a><span class="kw">const</span> { x<span class="op">,</span> y } <span class="op">=</span> <span class="fu">createParams</span>(<span class="st">'x'</span><span class="op">,</span> <span class="st">'y'</span>)</span>
|
||||
<span id="cb12-2"><a href="#cb12-2" aria-hidden="true" tabindex="-1"></a><span class="fu">x</span>(sine<span class="op">.</span><span class="fu">range</span>(<span class="dv">0</span><span class="op">,</span> <span class="dv">200</span>))<span class="op">.</span><span class="fu">y</span>(cosine<span class="op">.</span><span class="fu">range</span>(<span class="dv">0</span><span class="op">,</span><span class="dv">200</span>))</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
This example creates the custom control parameters <code>x</code> and <code>y</code> which are then used to form a
|
||||
pattern that descibes the coordinates of a circle.
|
||||
</p>
|
||||
<h3 data-number="7.3.2" id="outputs"><span class="header-section-number">7.3.2</span> Outputs</h3>
|
||||
<p>
|
||||
Now that we know how the value of an event is manipulated using control parameters, we can look at how outputs can
|
||||
use that value to generate anything. The scheduler above was calling the <code>onTrigger</code> function which is
|
||||
used to implement the output. A very simple version of the web audio output could look like this:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb13">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb13-1"><a href="#cb13-1" aria-hidden="true" tabindex="-1"></a><span class="kw">function</span> <span class="fu">onTrigger</span>(hap<span class="op">,</span> deadline<span class="op">,</span> duration) {</span>
|
||||
<span id="cb13-2"><a href="#cb13-2" aria-hidden="true" tabindex="-1"></a> <span class="kw">const</span> { note } <span class="op">=</span> hap<span class="op">.</span><span class="at">value</span><span class="op">;</span></span>
|
||||
<span id="cb13-3"><a href="#cb13-3" aria-hidden="true" tabindex="-1"></a> <span class="kw">const</span> time <span class="op">=</span> <span class="fu">getAudioContext</span>()<span class="op">.</span><span class="at">currentTime</span> <span class="op">+</span> deadline<span class="op">;</span></span>
|
||||
<span id="cb13-4"><a href="#cb13-4" aria-hidden="true" tabindex="-1"></a> <span class="kw">const</span> o <span class="op">=</span> <span class="fu">getAudioContext</span>()<span class="op">.</span><span class="fu">createOscillator</span>()<span class="op">;</span></span>
|
||||
<span id="cb13-5"><a href="#cb13-5" aria-hidden="true" tabindex="-1"></a> o<span class="op">.</span><span class="at">frequency</span><span class="op">.</span><span class="at">value</span> <span class="op">=</span> <span class="fu">getFreq</span>(note)<span class="op">;</span></span>
|
||||
<span id="cb13-6"><a href="#cb13-6" aria-hidden="true" tabindex="-1"></a> o<span class="op">.</span><span class="fu">start</span>(time)<span class="op">;</span></span>
|
||||
<span id="cb13-7"><a href="#cb13-7" aria-hidden="true" tabindex="-1"></a> o<span class="op">.</span><span class="fu">stop</span>(time <span class="op">+</span> <span class="bu">event</span><span class="op">.</span><span class="at">duration</span>)<span class="op">;</span></span>
|
||||
<span id="cb13-8"><a href="#cb13-8" aria-hidden="true" tabindex="-1"></a> o<span class="op">.</span><span class="fu">connect</span>(<span class="fu">getAudioContext</span>()<span class="op">.</span><span class="at">destination</span>)<span class="op">;</span></span>
|
||||
<span id="cb13-9"><a href="#cb13-9" aria-hidden="true" tabindex="-1"></a>}</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
The above example will create an <code>OscillatorNode</code> for each event, where the frequency is controlled by
|
||||
the <code>note</code> param. In essence, this is how the WebAudio API output of Strudel works, only with many more
|
||||
parameters to control synths, samples and effects.
|
||||
</p>
|
||||
<h1 data-number="8" id="pattern-alignment-and-combination">
|
||||
<span class="header-section-number">8</span> Pattern alignment and combination
|
||||
</h1>
|
||||
<p>
|
||||
One core aspect of Strudel, inherited from Tidal, is the flexible way that patterns can be combined, irrespective
|
||||
of their structure. Its declarative approach means a live coder does not have to think about the details of
|
||||
<em>how</em> this is done, only <em>what</em> is to be done.
|
||||
</p>
|
||||
<p>
|
||||
As a simple example, consider two number patterns <code>"0 [1 2] 3"</code>, and <code>"10 20"</code>. The first
|
||||
has three contiguous steps of equal lengths, with the second step broken down into two substeps, giving four
|
||||
events in total. There are a very large number of ways in which the structure of these two patterns could be
|
||||
combined, but the default method in both Strudel and Tidal is to line up the cycles of the two patterns, and then
|
||||
take events from the first pattern and match them with those in the second pattern. Therefore, the following two
|
||||
lines are equivalent:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb14">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb14-1"><a href="#cb14-1" aria-hidden="true" tabindex="-1"></a><span class="st">"0 [1 2] 3"</span><span class="op">.</span><span class="fu">add</span>(<span class="st">"10 20"</span>)</span>
|
||||
<span id="cb14-2"><a href="#cb14-2" aria-hidden="true" tabindex="-1"></a><span class="st">"10 [11 22] 23"</span></span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
Where the events only partially overlap, they are treated as fragments of the event in the first pattern. This is
|
||||
a little difficult to conceptualise, but lets start by comparing the two patterns in the following example:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb15">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb15-1"><a href="#cb15-1" aria-hidden="true" tabindex="-1"></a><span class="st">"0 1 2"</span><span class="op">.</span><span class="fu">add</span>(<span class="st">"10 20"</span>)</span>
|
||||
<span id="cb15-2"><a href="#cb15-2" aria-hidden="true" tabindex="-1"></a><span class="st">"10 [11 21] 20"</span></span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
They are similar to the previous example in that the number <code>1</code> is split in two, with its two halves
|
||||
added to <code>10</code> and <code>20</code> respectively. However, the <code>11</code> ‘remembers’ that it is a
|
||||
fragment of that original <code>1</code> event, and so is treated as having a duration of a third of a cycle,
|
||||
despite only being active for a sixth of a cycle. Likewise, the <code>21</code> is also a fragment of that
|
||||
original <code>1</code> event, but a fragment of its second half. Because the start of its event is missing, it
|
||||
wouldn’t actually trigger a sound (unless it underwent further pattern transformations/combinations).
|
||||
</p>
|
||||
<p>
|
||||
In practice, the effect of this default, implicit method for combining two patterns is that the second pattern is
|
||||
added <em>in</em> to the first one, and indeed this can be made explicit:
|
||||
</p>
|
||||
<div class="sourceCode" id="cb16">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb16-1"><a href="#cb16-1" aria-hidden="true" tabindex="-1"></a><span class="st">"0 1 2"</span><span class="op">.</span><span class="at">add</span><span class="op">.</span><span class="fu">in</span>(<span class="st">"10 20"</span>)</span></code></pre>
|
||||
</div>
|
||||
<p>This makes way for other ways to align the pattern, and several are already defined, in particular:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<code>in</code> - as explained above, aligns cycles, and applies values from the pattern on the right
|
||||
<em>in</em> to the pattern on the left.
|
||||
</li>
|
||||
<li>
|
||||
<code>out</code> - as with <code>in</code>, but values are applied <em>out</em> of the pattern on the left
|
||||
(i.e. <em>in</em> to the one on the right).
|
||||
</li>
|
||||
<li>
|
||||
<code>mix</code> - structures from both patterns are combined, so that the new events are not fragments but are
|
||||
created at intersections of events from both sides.
|
||||
</li>
|
||||
<li>
|
||||
<code>squeeze</code> - cycles from the pattern on the right are squeezed into events on the left. So that
|
||||
e.g. <code>"0 1 2".add.squeeze("10 20")</code> is equivalent to <code>"[10 20] [11 21] [12 22]"</code>.
|
||||
</li>
|
||||
<li>
|
||||
<code>squeezeout</code> - as with <code>squeeze</code>, but cycles from the left are squeezed into events on the
|
||||
right. So, <code>"0 1 2".add.squeezeout("10 20")</code> is equivalent to <code>[10 11 12] [20 21 22]</code>.
|
||||
</li>
|
||||
<li>
|
||||
<code>trig</code> is similar to <code>squeezeout</code> in that cycles from the right are aligned with events on
|
||||
the left. However those cycles are not ‘squeezed’, rather they are truncated to fit the event. So
|
||||
<code>"0 1 2 3 4 5 6 7".add.trig("10 [20 30]")</code> would be equivalent to
|
||||
<code>10 11 12 13 20 21 30 31</code>. In effect, events on the right ‘trigger’ cycles on the left.
|
||||
</li>
|
||||
<li>
|
||||
<code>trigzero</code> is similar to <code>trig</code>, but the pattern is ‘triggered’ from its very first cycle,
|
||||
rather than from the current cycle. <code>trig</code> and <code>trigzero</code> therefore only give different
|
||||
results where the leftmost pattern differs from one cycle to the next.
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
We will save going deeper into the background, design and practicalities of these alignment functions for future
|
||||
publications. However in the next section, we take them as a case study for looking at the different design
|
||||
affordances offered by Haskell to Tidal, and JavaScript to Strudel.
|
||||
</p>
|
||||
<h1 data-number="9" id="comparing-strudel-and-haskell-in-use">
|
||||
<span class="header-section-number">9</span> Comparing Strudel and Haskell in use
|
||||
</h1>
|
||||
<p>
|
||||
Unlike Haskell, JavaScript lacks the ability to define custom infix operators, or change the meaning of existing
|
||||
ones. So the above Strudel example of <code>"0 1 2".add.out("10 20")</code> is equivalent to the Tidal expression
|
||||
<code>"0 1 2" +| "10 20"</code>, where the vertical bar in the operator <code>+|</code> stands for
|
||||
<code>out</code> (where <code>a |+ b</code> would be equivalent of <code>a.add.in(b)</code>).
|
||||
</p>
|
||||
<p>
|
||||
From this we can already see that Tidal tends towards brevity through mixing infix operators with functions, and
|
||||
Strudel tends towards spelling out operations which are joined together with the <code>.</code> operator. This
|
||||
then is the design trade-off of Tidal’s tersity, versus Strudel’s simplicity.
|
||||
</p>
|
||||
<p>To demonstrate this, consider the following Tidal pattern:</p>
|
||||
<pre
|
||||
class="tidal"
|
||||
><code>iter 4 $ every 3 (||+ n "10 20") $ (n "0 1 3") # s "triangle" # crush 4</code></pre>
|
||||
<p>This can be directly translated to the Strudel equivalent:</p>
|
||||
<div class="sourceCode" id="cb18">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb18-1"><a href="#cb18-1" aria-hidden="true" tabindex="-1"></a><span class="fu">iter</span>(<span class="dv">4</span><span class="op">,</span> <span class="fu">every</span>(<span class="dv">3</span><span class="op">,</span> add<span class="op">.</span><span class="fu">squeeze</span>(<span class="st">"10 20"</span>)<span class="op">,</span> <span class="fu">n</span>(<span class="st">"0 1 3"</span>)<span class="op">.</span><span class="fu">s</span>(<span class="st">"triangle"</span>)<span class="op">.</span><span class="fu">crush</span>(<span class="dv">4</span>)))</span></code></pre>
|
||||
</div>
|
||||
<p>Although for a more canonical Strudel expression, we would reorder it as:</p>
|
||||
<div class="sourceCode" id="cb19">
|
||||
<pre
|
||||
class="sourceCode js"
|
||||
><code class="sourceCode javascript"><span id="cb19-1"><a href="#cb19-1" aria-hidden="true" tabindex="-1"></a><span class="fu">n</span>(<span class="st">"0 1 3"</span>)<span class="op">.</span><span class="fu">every</span>(<span class="dv">3</span><span class="op">,</span> add<span class="op">.</span><span class="fu">squeeze</span>(<span class="st">"10 20"</span>))<span class="op">.</span><span class="fu">iter</span>(<span class="dv">4</span>)<span class="op">.</span><span class="fu">s</span>(<span class="st">"triangle"</span>)<span class="op">.</span><span class="fu">crush</span>(<span class="dv">4</span>)</span></code></pre>
|
||||
</div>
|
||||
<p>
|
||||
The Strudel example uses the <code>.</code> method call operator for all operations and combinations, whereas the
|
||||
Tidal example has <code>#</code> for the default method for combining patterns and uses infix operators for other
|
||||
methods. The lack of parenthesis in the Tidal example is partly due to the way that arguments are applied to
|
||||
Haskell’s functions, and partly due to the use of the <code>$</code> operator as an alternative way to establish
|
||||
precedence and control the order of evaluation.
|
||||
</p>
|
||||
<p>
|
||||
Considering the above, we argue that the Haskell syntax is a little cleaner, but that the Strudel syntax is easier
|
||||
to learn. Our informal observation is that while Haskell’s dollar <code>$</code> operator is very useful in making
|
||||
code easier to work with, it is one of the most difficult aspects of Tidal use for beginners to learn. On the
|
||||
other hand, the deeper levels of parenthesis in Strudel code can be difficult to keep track of, especially while
|
||||
coding under pressure of live musical performance. However this difficulty can be largely be mitigated by
|
||||
reordering expressions, and further mitigated by supporting editor features.
|
||||
</p>
|
||||
<p>
|
||||
With Strudel, we have little choice but to embrace the affordances and constraints offered by JavaScript, and
|
||||
while designing a domain-specific language entirely based on method calls is a challenge, through creative
|
||||
adoption of functional programming techniques like partial application, we are so far very happy with the results.
|
||||
Tidal’s functional reactive approach to pattern-making has in general translated well to JavaScript, and
|
||||
opportunities and constraints have overall traded off to create a very approachable and useable live coding
|
||||
environment.
|
||||
</p>
|
||||
<h2 data-number="9.1" id="the-trade-off-of-flexible-typing">
|
||||
<span class="header-section-number">9.1</span> The trade-off of flexible typing
|
||||
</h2>
|
||||
<p>
|
||||
We have identified one problem with porting Tidal to JavaScript where we have missed Haskell’s strict typing and
|
||||
type inference. In both Tidal and Strudel, time is rational, where any point in time is represented as the ratio
|
||||
of two integers. This allows representation of musical ratios such that are impossible to represent accurately
|
||||
using the more common floating point numbers. However while libraries are available that support rational numbers
|
||||
in JavaScript, the lack of strict typing means that it is easy to implement pattern methods where computationally
|
||||
expensive conversion from floating point to rational numbers are performed late, and therefore often enough to
|
||||
overload the CPUs, due to the large number of iterative calculations required to estimate a ratio for a given
|
||||
floating point number. To mitigate this problem, we might consider moving to TypeScript in the future.
|
||||
</p>
|
||||
<h1 data-number="10" id="future-outlook"><span class="header-section-number">10</span> Future Outlook</h1>
|
||||
<p>
|
||||
The project is still young, with many features on the horizon. As general guiding principles, Strudel aims to be
|
||||
</p>
|
||||
<ol type="1">
|
||||
<li>accessible</li>
|
||||
<li>consistent with Tidal’s approach to pattern</li>
|
||||
<li>modular and extensible</li>
|
||||
</ol>
|
||||
<p>
|
||||
While Haskell’s type system makes it a great language for the ongoing development of Tidal’s inner representation
|
||||
of pattern, JavaScript’s vibrant ecosystem, flexibility and accessibility makes it a great host for more ad-hoc
|
||||
experiments, including interface design. For the future, it is planned to integrate additional alternative sound
|
||||
engines such as Glicol <span class="citation" data-cites="lanChaosprintGlicol2022">(Lan [2020] 2022)</span> and
|
||||
Faust
|
||||
<span class="citation" data-cites="FaustProgrammingLanguage2022"
|
||||
>(<em>Faust - Programming Language for Audio Applications and Plugins</em> [2016] 2022)</span
|
||||
>. Strudel is already approaching feature parity with Tidal, but there are more Tidal functions to be ported, and
|
||||
work to be done to improve compatibility with Tidal’s mininotation. Tidal version 2.0 is under development, which
|
||||
brings a new representation for sequences to its patterns, which will then be brought to Strudel. Besides sound,
|
||||
other ways to render events are being explored, such as graphical, and choreographic output. We are also looking
|
||||
into alternative ways of editing patterns, including multi-user editing for network music, parsing a novel syntax
|
||||
to escape the constraints of javascript, and developing hardware/e-textile interfaces. In summary, there is a lot
|
||||
of fun ahead.
|
||||
</p>
|
||||
<h1 data-number="11" id="links"><span class="header-section-number">11</span> Links</h1>
|
||||
<p>
|
||||
The Strudel REPL is available at <a href="https://strudel.cc" class="uri">https://strudel.cc</a>, including an
|
||||
interactive tutorial. The repository is at
|
||||
<a href="https://github.com/tidalcycles/strudel" class="uri">https://github.com/tidalcycles/strudel</a>, all the
|
||||
code is open source under the AGPL-3.0 License.
|
||||
</p>
|
||||
<h1 data-number="12" id="acknowledgments"><span class="header-section-number">12</span> Acknowledgments</h1>
|
||||
<p>
|
||||
Thanks to the Strudel and wider Tidal, live coding, WebAudio and free/open source software communities for
|
||||
inspiration and support. Alex McLean’s work on this project is supported by a UKRI Future Leaders Fellowship
|
||||
[grant number MR/V025260/1].
|
||||
</p>
|
||||
<h1 class="unnumbered" id="references">References</h1>
|
||||
<div id="refs" class="references csl-bib-body hanging-indent" role="doc-bibliography">
|
||||
<div id="ref-FaustProgrammingLanguage2022" class="csl-entry" role="doc-biblioentry">
|
||||
<em>Faust - Programming Language for Audio Applications and Plugins</em>. (2016) 2022. C++. GRAME.
|
||||
<a href="https://github.com/grame-cncm/faust">https://github.com/grame-cncm/faust</a>.
|
||||
</div>
|
||||
<div id="ref-jackHydra2022" class="csl-entry" role="doc-biblioentry">
|
||||
Jack, Olivia. (2022) 2022. <em>Hydra</em>.
|
||||
<a href="https://github.com/ojack/hydra">https://github.com/ojack/hydra</a>.
|
||||
</div>
|
||||
<div id="ref-lanChaosprintGlicol2022" class="csl-entry" role="doc-biblioentry">
|
||||
Lan, Qichao. (2020) 2022. <em>Chaosprint/Glicol</em>. Rust.
|
||||
<a href="https://github.com/chaosprint/glicol">https://github.com/chaosprint/glicol</a>.
|
||||
</div>
|
||||
<div id="ref-mcleanAlgorithmicPattern2020a" class="csl-entry" role="doc-biblioentry">
|
||||
Mclean, Alex. 2020. <span>“Algorithmic Pattern.”</span> In
|
||||
<em>Proceedings of the International Conference on New Interfaces for Musical Expression</em>, 265--270.
|
||||
Birmingham, UK. <a href="https://zenodo.org/record/4813352">https://zenodo.org/record/4813352</a>.
|
||||
</div>
|
||||
<div id="ref-mcleanFeedforward2020" class="csl-entry" role="doc-biblioentry">
|
||||
McLean, Alex. 2020. <span>“Feedforward.”</span> In
|
||||
<em>Proceedings of New Interfaces for Musical Expression</em>. Birmingham.
|
||||
<a href="https://zenodo.org/record/6353969">https://zenodo.org/record/6353969</a>.
|
||||
</div>
|
||||
<div id="ref-mcleanTidalVortexZero2022" class="csl-entry" role="doc-biblioentry">
|
||||
McLean, Alex, Raphaël Forment, Sylvain Le Beux, and Damián Silvani. 2022. <span>“TidalVortex Zero.”</span> In
|
||||
<em>Proceedings of the 7th International Conference on Live Coding</em>. Limerick, Ireland: Zenodo.
|
||||
<a href="https://doi.org/10.5281/zenodo.6456380">https://doi.org/10.5281/zenodo.6456380</a>.
|
||||
</div>
|
||||
<div id="ref-ogbornDktr0WebDirt2022" class="csl-entry" role="doc-biblioentry">
|
||||
Ogborn, David. (2016) 2022. <em>Dktr0/WebDirt</em>. JavaScript.
|
||||
<a href="https://github.com/dktr0/WebDirt">https://github.com/dktr0/WebDirt</a>.
|
||||
</div>
|
||||
<div id="ref-ogbornEstuaryBrowserbasedCollaborative2017" class="csl-entry" role="doc-biblioentry">
|
||||
Ogborn, David, Jamie Beverley, Luis Navarro del Angel, Eldad Tsabary, and Alex McLean. 2017.
|
||||
<span>“Estuary: Browser-Based Collaborative Projectional Live Coding of Musical Patterns.”</span> In
|
||||
<em>Proceedings of the International Conference on Live Coding</em>, 11. Morelia.
|
||||
</div>
|
||||
<div id="ref-robertsGibberLiveCoding2012" class="csl-entry" role="doc-biblioentry">
|
||||
Roberts, Charles, and Joann Kuchera-morin. 2012. <span>“Gibber: Live Coding Audio in the Browser.”</span> In
|
||||
<em>In Proceedings of the 2012 International Computer Music Conference</em>.
|
||||
</div>
|
||||
<div id="ref-StrudelWAC2022" class="csl-entry" role="doc-biblioentry">
|
||||
Roos, Felix, and Alex McLean. 2022. <span>“Strudel: Algorithmic Patterns for the Web.”</span> In. Zenodo.
|
||||
<a href="https://doi.org/10.5281/zenodo.6768844">https://doi.org/10.5281/zenodo.6768844</a>.
|
||||
</div>
|
||||
<div id="ref-solomonPurescriptocarina2022" class="csl-entry" role="doc-biblioentry">
|
||||
Solomon, Mike. (2021) 2022. <em>Purescript-Ocarina</em>. PureScript.
|
||||
<a href="https://github.com/mikesol/purescript-ocarina">https://github.com/mikesol/purescript-ocarina</a>.
|
||||
</div>
|
||||
<div id="ref-SuperDirt2022" class="csl-entry" role="doc-biblioentry">
|
||||
<em>SuperDirt</em>. (2015) 2022. SuperCollider. musikinformatik.
|
||||
<a href="https://github.com/musikinformatik/SuperDirt">https://github.com/musikinformatik/SuperDirt</a>.
|
||||
</div>
|
||||
<div id="ref-toussaintEuclideanAlgorithmGenerates2005" class="csl-entry" role="doc-biblioentry">
|
||||
Toussaint, Godfried. 2005. <span>“The Euclidean Algorithm Generates Traditional Musical Rhythms.”</span> In
|
||||
<em>In Proceedings of BRIDGES: Mathematical Connections in Art, Music and Science</em>, 47–56.
|
||||
<a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.62.231"
|
||||
>http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.62.231</a
|
||||
>.
|
||||
</div>
|
||||
<div id="ref-CsoundWebAssembly" class="csl-entry" role="doc-biblioentry">
|
||||
Yi, Steven, Victor Lazzarini, and Edward Costello. 2018.
|
||||
<span>“WebAssembly AudioWorklet Csound.”</span> In. Berlin, Germany.
|
||||
<a href="https://mural.maynoothuniversity.ie/16018/">https://mural.maynoothuniversity.ie/16018/</a>.
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,460 +0,0 @@
|
||||
---
|
||||
title: 'Strudel: live coding patterns on the Web'
|
||||
author:
|
||||
- name: Felix Roos
|
||||
affiliation: Unaffiliated
|
||||
email: flix91@gmail.com
|
||||
- name: Alex McLean
|
||||
affiliation: Then Try This
|
||||
email: alex@slab.org
|
||||
abstract: |
|
||||
This paper introduces Strudel, which brings the TidalCycles approach to live coding algorithmic patterns to native JavaScript and the web. We begin by giving a little background of the first year of development, before sharing some detail about its implementation and examples of use. We go on to outline the wide range of synthesis and other outputs available in Strudel, including WebAudio, MIDI, OSC (for SuperDirt), WebSerial and CSound, and introduce Strudel's REPL live editor, including its built-in visualisations. We then compare Strudel with Tidal, the trade-offs involved between JavaScript and Haskell, and the unique capabilities offered by Strudel for aligning patterns, before concluding with some thoughts about the future.
|
||||
bibliography: citations.json
|
||||
fontsize: 11pt
|
||||
geometry: margin=2cm
|
||||
fontfamily: libertine
|
||||
fontfamily: inconsolata
|
||||
mainfont: Linux Libertine O
|
||||
monofont: Inconsolata
|
||||
date: '2022-12-14'
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
In the following paper, we introduce *Strudel*, an alternative
|
||||
implementation of the TidalCycles (or 'Tidal' for short) live coding
|
||||
system, using the JavaScript programming language. Strudel is an
|
||||
attempt to make live coding more accessible, by creating a system that
|
||||
runs entirely in the browser, while opening Tidal's approach to
|
||||
algorithmic patterns [@mcleanAlgorithmicPattern2020a] up to modern
|
||||
audio/visual web technologies. The Strudel REPL is a live code editor
|
||||
dedicated to manipulating patterns while they play, with builtin
|
||||
visual feedback. While Strudel is written in JavaScript, the API is
|
||||
optimized for simplicity and readability by applying code
|
||||
transformations on the syntax tree level, allowing language operations
|
||||
that would otherwise be impossible. The application supports multiple
|
||||
ways to output sound, including Tone.js, Web Audio Nodes, OSC (Open
|
||||
Sound Control) messages, Web Serial, Web MIDI and Csound. The project
|
||||
is split into multiple packages, allowing granular reuse in other
|
||||
applications. Apart from TidalCycles, Strudel draws inspiration from
|
||||
many prior existing projects like TidalVortex
|
||||
[@mcleanTidalVortexZero2022], Gibber [@robertsGibberLiveCoding2012],
|
||||
Estuary [@ogbornEstuaryBrowserbasedCollaborative2017], Hydra
|
||||
[@jackHydra2022], Ocarina [@solomonPurescriptocarina2022] and
|
||||
Feedforward [@mcleanFeedforward2020]. This paper expands the Strudel
|
||||
Demo paper for the Web Audio Conference 2022 [@StrudelWAC2022].
|
||||
|
||||
The first tentative commit to the Strudel project was on 22nd January
|
||||
2022 by Alex McLean, with the core representation implemented over the
|
||||
following few days. Although this was his first attempt at a
|
||||
JavaScript-based application, by 27th January, Alex had managed to
|
||||
upload the initial version to the 'npm' javascript package database,
|
||||
sharing with the wider community for comment. By 4th February, Felix
|
||||
Roos had discovered Strudel and contributed a 'REPL' user interface to
|
||||
it, and then contributed a scheduler the next day, so that Strudel
|
||||
could already make sound. At this point, Alex and Felix shared
|
||||
ownership to the repository, and the project has since proved to be a
|
||||
productive confluence of Felix's own work into music representation
|
||||
and visualisation, with Alex's experience with making Tidal. Felix has
|
||||
since become the primary contributor to Strudel, with Alex continuing
|
||||
to jump between developing both Strudel and Tidal. Aspects of
|
||||
Strudel's development have therefore fed back into TidalCycles, and
|
||||
both systems have maintained a shared conceptual underpinning. We plan
|
||||
to continue working towards feature parity between these systems,
|
||||
although within the syntactical trade-offs and library ecosystems of
|
||||
JavaScript and Haskell, some divergence is inevitable and healthy.
|
||||
|
||||
Over the first year of its life, Strudel is now a fully-fledged live
|
||||
coding environment, porting Tidal's core represention of patterns,
|
||||
pattern transformations, and mini-notation for polymetric sequences,
|
||||
combined with a wealth of features for synthesising and visualising
|
||||
those patterns.
|
||||
|
||||
# From Tidal to Strudel and back
|
||||
|
||||
As mentioned above, the original Tidal is implemented as a domain specific language (DSL) embedded in the Haskell pure functional programming language, and takes advantage of Haskell's terse syntax and advanced, 'strong' type system. JavaScript on the other hand, is a multi-paradigm programming language, with a dynamic type system. Because Tidal leans heavily on many of Haskell's more unique features, it was not always clear that it could meaningfully be ported to a multi-paradigm scripting language. However, this possibility was already demonstrated with an earlier port to Python [TidalVortex; @mcleanTidalVortexZero2022], and we have now successfully implemented Tidal's pure functional representation of patterns in Strudel, including partial application, currying, and the functor, applicative and monadic structures that underlie Tidal's expressive pattern transformations. The result is a terse and highly composable system, where everything is either a pattern, or a function for combining and manipulating patterns, offering a rich creative ground for exploration.
|
||||
|
||||
This development process has been far from a one-way port, however. The process of porting Tidal's concepts has also opened up new possibilities, some just from revisiting every design decision, and some from the particular affordances and constraints offered by JavaScript. This has lead to new features (and indeed bugfixes) that have found their way back to Tidal where appropriate, and ongoing work that we will return to in the conclusion of this paper.
|
||||
|
||||
# Representing Patterns
|
||||
|
||||
Patterns are the essence of Tidal. Its patterns are abstract entities that represent flows of time as functions, adapting a technique called pure functional reactive programming. Taking a time span as its input, a Pattern can output a set of events that happen within that time span. It depends on the structure of the Pattern how the events are located in time.
|
||||
From now on, this process of generating events from a time span will be called **querying**.
|
||||
Example:
|
||||
|
||||
```js
|
||||
const pattern = sequence(c3, [e3, g3])
|
||||
const events = pattern.queryArc(0, 1)
|
||||
console.log(events.map(e => e.show()))
|
||||
```
|
||||
|
||||
In this example, we create a pattern using the `sequence` function and **query** it for the time span from `0` to `1`.
|
||||
Those numbers represent units of time called **cycles**. The length of one cycle depends on the tempo, which defaults to one cycle per second.
|
||||
The resulting events are:
|
||||
|
||||
```js
|
||||
["[ 0/1 -> 1/2 | c3 ]",
|
||||
"[ 1/2 -> 3/4 | e3 ]",
|
||||
"[ 3/4 -> 1/1 | g3 ]"
|
||||
]
|
||||
```
|
||||
|
||||
Each event has a value, a begin time and an end time, where time is represented as a fraction. In the above case, the events are placed in sequential order, where c3 takes the first half, and e3 and g3 together take the second half. This temporal placement is the result of the `sequence` function, which divides its arguments equally over one cycle. If an argument is an array, the same rule applies to that part of the cycle. In the example, e3 and g3 are divided equally over the second half of the whole cycle.
|
||||
|
||||
Note that the query function is not just a way to access a pattern, but true to the principles of functional programming, is the pattern itself. This means that in theory there is no way to change a pattern, it is opaque as a pure function. In practice though, Strudel and Tidal are all about transforming patterns, so how is this done? The answer is, by replacing the pattern with a new one, that calls the old one. This new one is only able to manipulate the query before passing it to the old pattern, and manipulate the results from it before returning them to caller. But, this is enough to support all the temporal and structural manipulations provided by Strudel (and Tidal's) extensive library of functions.
|
||||
|
||||
The above examples do not represent how Strudel is used in practice. In the live coding editor, the user only has to type in the pattern itself, the querying will be handled by the scheduler. The scheduler will repeatedly query the pattern for events, which are then scheduled as sound synthesis or other event triggers.
|
||||
Also, the above event data structure has been simplified for readability.
|
||||
|
||||
{ width=60% }
|
||||
|
||||
# Making Patterns
|
||||
|
||||
In practice, the end-user live coder will not deal with constructing patterns directly, but will rather build patterns using Strudel's extensive combinator library to create, combine and transform patterns.
|
||||
|
||||
The live coder will rarely use the `sequence` function as seen above, as sequencing is implicit in many functions. For example in the following, the `note` function constructs a pattern of notes, sequencing its arguments in the same manner as the previous example.
|
||||
|
||||
```js
|
||||
note(c3, [e3, g3])
|
||||
```
|
||||
|
||||
Perhaps more often, they will use the mini-notation for even terser notation of rhythmic sequences: ^[This last example is also valid Tidal code, albeit the parenthesis is not required in its Haskell syntax in this case. Tidal does not support passing sequences as lists directly to the `note` function, however.].
|
||||
|
||||
```js
|
||||
note("c3 [e3 g3]")
|
||||
```
|
||||
|
||||
Such sequences are often treated only as a starting point for manipulation, where they then undergo pattern transformations such as repetition, symmetry, interference/combination or randomisation, potentially at multiple timescales. Because Strudel patterns are represented as pure functions of time rather than as data structures, very long and complex generative results can be represented and manipulated without having to store the resulting sequences in memory.
|
||||
|
||||
# Pattern Example
|
||||
|
||||
The following example showcases how patterns can be utilized to create musical complexity from simple parts, using repetition and interference:
|
||||
|
||||
```js
|
||||
"<0 2 [4 6](3,4,1) 3>"
|
||||
.off(1/4, add(2))
|
||||
.off(1/2, add(6))
|
||||
.scale('D minor')
|
||||
.legato(.25)
|
||||
.note().s("sawtooth square")
|
||||
.delay(.8).delaytime(.125)
|
||||
```
|
||||
|
||||
The pattern starts with a rhythm of numbers in mini-notation, which are later interpreted inside the scale of D minor.
|
||||
The first line could also be expressed without mini-notation:
|
||||
|
||||
```js
|
||||
cat(0, 2, [4, 6].euclid(3, 4, 1), 3)
|
||||
```
|
||||
|
||||
These numbers then undergo various pattern transformations. Here is a short description of all the functions used:
|
||||
|
||||
- `cat`: play elements sequentially, where each lasts one cycle
|
||||
- `brackets`: elements inside brackets are divided equally over the time of their parent
|
||||
- `.euclid(p, s, o)`: place p pulses evenly over s steps, with offset o [@toussaintEuclideanAlgorithmGenerates2005]
|
||||
- `.off(n, f)`: layers a pattern on top of itself, with the new layer offset by n cycles, and with function f applied
|
||||
- `.legato(n)`: multiply the duration of all events in a pattern by a factor of n
|
||||
- `.echo(t, n, v)`: copy each event t times, with n cycles in between each copy, decreasing velocity by v
|
||||
- `.note()`: interpretes values as notes
|
||||
- `.s(name)`: play back each event with the given sound
|
||||
- `.delay(wet)`: add delay
|
||||
- `.delaytime(t)`: set delay time
|
||||
|
||||
Much of the above will be familiar to Tidal users.
|
||||
|
||||
<!-- This example shows some of Strudel's unique support for chords and transposition familiar to students of Western music theory. This differs a little from Tidal's approach and thanks to the integration of the javascript library XXX (*TODO* ? or is this all your work Felix?), Strudel's support for tonal transformations such as voice leading is perhaps respects more advanced than Tidal. -->
|
||||
|
||||
# Ways to make Sound (and other events)
|
||||
|
||||
To generate sound, Strudel supports bindings for different outputs:
|
||||
|
||||
- Tone.js (deprecated)
|
||||
- Web Audio API
|
||||
- WebDirt, a js recreation of Tidal's *Dirt* sample engine (deprecated)
|
||||
- OSC via osc-js, compatible with superdirt
|
||||
- Csound via the Csound WebAssembly build
|
||||
- MIDI via WebMIDI
|
||||
- Serial via WebSerial
|
||||
|
||||
At first, we used Tone.js as sound output, but it proved to be limited for the use case of Strudel, where each individual event could potentially have a completely different audio graph.
|
||||
While the Web Audio API takes a *fire-and-forget* approach, creating a lot of Tone.js instruments and effects causes performance issues quickly. For that reason, we chose to search for alternatives.
|
||||
|
||||
Strudel's new default output uses the Web Audio API to create a new audio graph for each event. It currently supports basic oscillators, sample playback, various effects and an experimental support for soundfonts.
|
||||
|
||||
WebDirt [@ogbornDktr0WebDirt2022] was created as part of the Estuary Live Coding System [@ogbornEstuaryBrowserbasedCollaborative2017], and proved to be a solid choice for handling samples in Strudel as well. We are however focused on working more directly with the Web Audio API to be able to integrate new features more tightly.
|
||||
|
||||
Using the OSC protocol via Strudel's provided Node.js-based OSC proxy server, it is possible to send network messages to trigger events. This is mainly used to render sound using SuperDirt [@SuperDirt2022], which is the well-developed Supercollider-based synthesis framework that Tidal live coders generally use as standard.
|
||||
|
||||
Recently, the experimental integration of Csound proved to bring a new dimension of sound design capabilities to Strudel. Thanks to the WebAssembly distribution of this classic system [@CsoundWebAssembly], Csound 'orchestra' synthesisers can be embedded in and then patterned with Strudel code.
|
||||
|
||||
MIDI output can also be used to send MIDI messages to either external instruments or to other programs on the same device. Unlike OSC, Strudel is able to send MIDI directly without requiring additional proxy software, but only from web browsers that support it (at the time of writing, this means Chromium-based browsers).
|
||||
|
||||
Finally, Strudel supports Serial output, for example to trigger events
|
||||
via microcontrollers. This has already been explored for robot
|
||||
choreography by Kate Sicchio and Alex McLean, via a performance
|
||||
presented at the International Conference on Live Interfaces 2022.
|
||||
|
||||
# The Strudel REPL
|
||||
|
||||
While Strudel can be used as a library in any JavaScript codebase, its main, reference user interface is the Strudel REPL^[REPL stands for read, evaluate, print/play, loop. It is friendly jargon for an interactive programming interface from computing heritage, usually for a commandline interface but also applied to live coding editors.], which is a browser-based live coding environment. This live code editor is dedicated to manipulating Strudel patterns while they play. The REPL features built-in visual feedback, highlighting which elements in the patterned (mini-notation) sequences are influencing the event that is currently being played. This feedback is designed to support both learning and live use of Strudel.
|
||||
|
||||
Besides a UI for playback control and meta information, the main part of the REPL interface is the code editor powered by CodeMirror. In it, the user can edit and evaluate pattern code live, using one of the available synthesis outputs to create music and/or sound art. The control flow of the REPL follows 3 basic steps:
|
||||
|
||||
1. The user writes and updates code. Each update transpiles and evaluates it to create a `Pattern` instance
|
||||
2. While the REPL is running, the `Scheduler` queries the active `Pattern` by a regular interval, generating `Events` (also known as `Haps` in Strudel) for the next time span.
|
||||
3. For each scheduling tick, all generated `Events` are triggered by calling their `onTrigger` method, which is set by the output.
|
||||
|
||||
{ width=43% }
|
||||
|
||||
## User Code
|
||||
|
||||
To create a `Pattern` from the user code, two steps are needed:
|
||||
|
||||
1. Transpile the JS input code to make it functional
|
||||
2. Evaluate the transpiled code
|
||||
|
||||
### Transpilation & Evaluation
|
||||
|
||||
In the JavaScript world, using transpilation is a common practise to be able to use language features that are not supported by the base language. Tools like `babel` will transpile code that contains unsupported language features into a version of the code without those features.
|
||||
|
||||
In the same tradition, Strudel can add a transpilation step to simplify the user code in the context of live coding. For example, the Strudel REPL lets the user create mini-notation patterns using just double quoted strings, while single quoted strings remain what they are:
|
||||
|
||||
```js
|
||||
"c3 [e3 g3]*2"
|
||||
```
|
||||
|
||||
is transpiled to:
|
||||
|
||||
```js
|
||||
mini("c3 [e3 g3]*2").withMiniLocation([1,0,0],[1,14,14])
|
||||
```
|
||||
|
||||
Here, the string is wrapped in `mini`, which will create a pattern from a mini-notation string. Additionally, the `withMiniLocation` method passes the original source code location of the string to the pattern, which enables highlighting active events.
|
||||
|
||||
Other convenient features like pseudo variables, operator overloading and top level await are possible with transpilation.
|
||||
|
||||
After the transpilation, the code is ready to be evaluated into a `Pattern`.
|
||||
|
||||
Behind the scenes, the user code string is parsed with `acorn`, turning it into an Abstract Syntax Tree (AST). The AST allows changing the structure of the code before generating the transpiled version using `escodegen`.
|
||||
|
||||
### Mini-notation
|
||||
|
||||
While the transpilation allows JavaScript to express Patterns in a less verbose way, it is still preferable to use the mini-notation as a more compact way to express rhythm. Strudel aims to provide the same mini-notation features and syntax as used in Tidal.
|
||||
|
||||
The mini-notation parser is implemented using `peggy`, which allows generating performant parsers for Domain Specific Languages (DSLs) using a concise grammar notation. The generated parser turns the mini-notation string into an AST which is used to call the respective Strudel functions with the given structure. For example, `"c3 [e3 g3]*2"` will result in the following calls:
|
||||
|
||||
```js
|
||||
seq(
|
||||
reify('c3').withLocation([1,1,1], [1,4,4]),
|
||||
seq(
|
||||
reify('e3').withLocation([1,5,5], [1,8,8]),
|
||||
reify('g3').withLocation([1,8,8], [1,10,10]),
|
||||
).fast(2)
|
||||
)
|
||||
```
|
||||
|
||||
### Highlighting Locations
|
||||
|
||||
As seen in the examples above, both the JS and the mini-notation parser add source code locations using `withMiniLocation` and `withLocation` methods. While the JS parser adds locations relative to the user code as a whole, the mini-notation adds locations relative to the position of the mini-notation string. The absolute location of elements within mini-notation can be calculated by simply adding both locations together. This absolute location can be used to highlight active events in real time.
|
||||
|
||||
## Scheduling Events
|
||||
|
||||
After an instance of `Pattern` is obtained from the user code,
|
||||
it is used by the scheduler to get queried for events. Once started, the scheduler runs at a fixed interval to query the active pattern for events within the current interval's time span. A simplified implementation looks like this:
|
||||
|
||||
```js
|
||||
let pattern = seq('c3', ['e3', 'g3']); // pattern from user
|
||||
let interval = 0.5; // query interval in seconds
|
||||
let time = 0; // beginning of current time span
|
||||
let minLatency = .1; // min time before a hap should trigger
|
||||
setInterval(() => {
|
||||
const haps = pattern.queryArc(time, time + interval);
|
||||
time += interval; // increment time
|
||||
haps.forEach((hap) => {
|
||||
const deadline = hap.whole.begin - time + minLatency;
|
||||
onTrigger(hap, deadline, duration);
|
||||
});
|
||||
}, interval * 1000); // query each "interval" seconds
|
||||
```
|
||||
|
||||
Note that the above code is simplified for illustrative purposes. The actual implementation has to work around imprecise callbacks of `setInterval`. More about the implementation details can be read in [this blog post](https://loophole-letters.vercel.app/web-audio-scheduling).
|
||||
|
||||
The fact that `Pattern.queryArc` is a pure function that maps a time span to a set of events allows us to choose any interval we like without changing the resulting output. It also means that when the pattern is changed from outside, the next scheduling callback will work with the new pattern, keeping its clock running.
|
||||
|
||||
The latency between the time the pattern is evaluated and the change is heard is between `minLatency` and `interval + minLatency`, in our example between 100ms and 600ms. In Strudel, the current query interval is 50ms with a minLatency of 100ms, meaning the latency is between 50ms and 150ms.
|
||||
|
||||
## Output
|
||||
|
||||
The last step is to trigger each event in the chosen output.
|
||||
This is where the given time and value of each event is used to generate audio or any other form of time based output. The default output of the Strudel REPL is the WebAudio output. To understand what an output does, we first have to understand what control parameters are.
|
||||
|
||||
### Control Parameters
|
||||
|
||||
To be able to manipulate multiple aspects of sound in parallel, so called control parameters are used to shape the value of each event. Example:
|
||||
|
||||
```js
|
||||
note("c3 e3").cutoff(1000).s('sawtooth')
|
||||
.queryArc(0, 1).map(hap => hap.value)
|
||||
/* [
|
||||
{ note: 'c3', cutoff: 1000, s: 'sawtooth' }
|
||||
{ note: 'e3', cutoff: 1000, s: 'sawtooth' }
|
||||
] */
|
||||
```
|
||||
|
||||
Here, the control parameter functions `note`, `cutoff` and `s` are used, where each controls a different property in the value object. Each control parameter function accepts a primitive value, a list of values to be sequenced into a `Pattern`, or a `Pattern`. In the example, `note` gets a `Pattern` from a mini-notation expression (double quoted), while `cutoff` and `s` are given a `Number` and a (single quoted) `String` respectively.
|
||||
|
||||
Strudel comes with a large default set of control parameter functions that are based on the ones used by Tidal and SuperDirt, focusing on music and audio terminology. It is however possible to create custom control parameters for any purpose:
|
||||
|
||||
```js
|
||||
const { x, y } = createParams('x', 'y')
|
||||
x(sine.range(0, 200)).y(cosine.range(0,200))
|
||||
```
|
||||
|
||||
This example creates the custom control parameters `x` and `y` which are then used to form a pattern that descibes the coordinates of a circle.
|
||||
|
||||
### Outputs
|
||||
|
||||
Now that we know how the value of an event is manipulated using control parameters, we can look at how outputs can use that value to generate anything. The scheduler above was calling the `onTrigger` function which is used to implement the output. A very simple version of the web audio output could look like this:
|
||||
|
||||
```js
|
||||
function onTrigger(hap, deadline, duration) {
|
||||
const { note } = hap.value;
|
||||
const time = getAudioContext().currentTime + deadline;
|
||||
const o = getAudioContext().createOscillator();
|
||||
o.frequency.value = getFreq(note);
|
||||
o.start(time);
|
||||
o.stop(time + event.duration);
|
||||
o.connect(getAudioContext().destination);
|
||||
}
|
||||
```
|
||||
|
||||
The above example will create an `OscillatorNode` for each event, where the frequency is controlled by the `note` param. In essence, this is how the WebAudio API output of Strudel works, only with many more parameters to control synths, samples and effects.
|
||||
|
||||
# Pattern alignment and combination
|
||||
|
||||
One core aspect of Strudel, inherited from Tidal, is the flexible way that patterns can be combined, irrespective of their structure. Its declarative approach means a live coder does not have to think about the details of *how* this is done, only *what* is to be done.
|
||||
|
||||
As a simple example, consider two number patterns `"0 [1 2] 3"`, and `"10 20"`. The first has three contiguous steps of equal lengths, with the second step broken down into two substeps, giving four events in total. There are a very large number of ways in which the structure of these two patterns could be combined, but the default method in both Strudel and Tidal is to line up the cycles of the two patterns, and then take events from the first pattern and match them with those in the second pattern. Therefore, the following two lines are equivalent:
|
||||
|
||||
```js
|
||||
"0 [1 2] 3".add("10 20")
|
||||
"10 [11 22] 23"
|
||||
```
|
||||
|
||||
Where the events only partially overlap, they are treated as fragments
|
||||
of the event in the first pattern. This is a little difficult to
|
||||
conceptualise, but lets start by comparing the two patterns in the
|
||||
following example:
|
||||
|
||||
```js
|
||||
"0 1 2".add("10 20")
|
||||
"10 [11 21] 20"
|
||||
```
|
||||
|
||||
They are similar to the previous example in that the number `1` is split in two, with its two halves added to `10` and `20` respectively. However, the `11` 'remembers' that it is a fragment of that original `1` event, and so is treated as having a duration of a third of a cycle, despite only being active for a sixth of a cycle. Likewise, the `21` is also a fragment of that original `1` event, but a fragment of its second half. Because the start of its event is missing, it wouldn't actually trigger a sound (unless it underwent further pattern transformations/combinations).
|
||||
|
||||
In practice, the effect of this default, implicit method for combining two patterns is that the second pattern is added *in* to the first one, and indeed this can be made explicit:
|
||||
|
||||
```js
|
||||
"0 1 2".add.in("10 20")
|
||||
```
|
||||
|
||||
This makes way for other ways to align the pattern, and several are already defined, in particular:
|
||||
|
||||
* `in` - as explained above, aligns cycles, and applies values from the pattern on the right *in* to the pattern on the left.
|
||||
* `out` - as with `in`, but values are applied *out* of the pattern on the left (i.e. *in* to the one on the right).
|
||||
* `mix` - structures from both patterns are combined, so that the new events are not fragments but are created at intersections of events from both sides.
|
||||
* `squeeze` - cycles from the pattern on the right are squeezed into events on the left. So that e.g. `"0 1 2".add.squeeze("10 20")` is equivalent to `"[10 20] [11 21] [12 22]"`.
|
||||
* `squeezeout` - as with `squeeze`, but cycles from the left are squeezed into events on the right. So, `"0 1 2".add.squeezeout("10 20")` is equivalent to `[10 11 12] [20 21 22]`.
|
||||
* `trig` is similar to `squeezeout` in that cycles from the right are aligned with events on the left. However those cycles are not 'squeezed', rather they are truncated to fit the event. So `"0 1 2 3 4 5 6 7".add.trig("10 [20 30]")` would be equivalent to `10 11 12 13 20 21 30 31`. In effect, events on the right 'trigger' cycles on the left.
|
||||
* `trigzero` is similar to `trig`, but the pattern is 'triggered' from its very first cycle, rather than from the current cycle. `trig` and `trigzero` therefore only give different results where the leftmost pattern differs from one cycle to the next.
|
||||
|
||||
We will save going deeper into the background, design and practicalities of these alignment functions for future publications. However in the next section, we take them as a case study for looking at the different design affordances offered by Haskell to Tidal, and JavaScript to Strudel.
|
||||
|
||||
# Comparing Strudel and Haskell in use
|
||||
|
||||
Unlike Haskell, JavaScript lacks the ability to define custom infix
|
||||
operators, or change the meaning of existing ones. So the above
|
||||
Strudel example of `"0 1 2".add.out("10 20")` is equivalent to the
|
||||
Tidal expression `"0 1 2" +| "10 20"`, where the vertical bar in the
|
||||
operator `+|` stands for `out` (where `a |+ b` would be equivalent of
|
||||
`a.add.in(b)`).
|
||||
|
||||
From this we can already see that Tidal tends towards brevity through
|
||||
mixing infix operators with functions, and Strudel tends towards
|
||||
spelling out operations which are joined together with the `.`
|
||||
operator. This then is the design trade-off of Tidal's tersity,
|
||||
versus Strudel's simplicity.
|
||||
|
||||
To demonstrate this, consider the following Tidal pattern:
|
||||
|
||||
```haskell
|
||||
iter 4 $ every 3 (||+ n "10 20") $ (n "0 1 3") # s "triangle" # crush 4
|
||||
```
|
||||
|
||||
This can be directly translated to the Strudel equivalent:
|
||||
|
||||
```js
|
||||
iter(4, every(3, add.squeeze("10 20"), n("0 1 3").s("triangle").crush(4)))
|
||||
```
|
||||
|
||||
Although for a more canonical Strudel expression, we would reorder it
|
||||
as:
|
||||
|
||||
```js
|
||||
n("0 1 3").every(3, add.squeeze("10 20")).iter(4).s("triangle").crush(4)
|
||||
```
|
||||
|
||||
The Strudel example uses the `.` method call operator for all
|
||||
operations and combinations, whereas the Tidal example has `#` for the
|
||||
default method for combining patterns and uses infix operators for
|
||||
other methods. The relative lack of parenthesis in the Tidal example is partly
|
||||
due to the way that arguments are applied to Haskell's functions, and
|
||||
partly due to the use of the `$` operator as an alternative way to
|
||||
establish precedence and control the order of evaluation.
|
||||
|
||||
Considering the above, we hypothesise that the Haskell syntax is a little
|
||||
cleaner, but that the Strudel syntax is easier to learn. Our informal
|
||||
observation is that while Haskell's dollar `$` operator is very useful
|
||||
in making code easier to work with, it is one of the most difficult
|
||||
aspects of Tidal use for beginners to learn. On the other hand, the
|
||||
deeper levels of parenthesis in Strudel code can be difficult to keep
|
||||
track of, especially while coding under pressure of live musical
|
||||
performance. However this difficulty can largely be mitigated by
|
||||
reordering expressions, and further mitigated by supporting editor
|
||||
features.
|
||||
|
||||
With Strudel, we have little choice but to embrace the affordances and
|
||||
constraints offered by JavaScript, and while designing a
|
||||
domain-specific language based on method calls is a
|
||||
challenge, through creative adoption of functional programming
|
||||
techniques like partial application, we are so far very happy with the
|
||||
results. Tidal's functional reactive approach to pattern-making has in
|
||||
general translated well to JavaScript, and opportunities and
|
||||
constraints have overall traded off to create a very approachable and
|
||||
useable live coding environment.
|
||||
|
||||
## The trade-off of flexible typing
|
||||
|
||||
We have identified one problem with porting Tidal to JavaScript where we have missed Haskell's strict typing and type inference. In both Tidal and Strudel, time is rational, where any point in time is represented as the ratio of two integers. This allows representation of musical ratios such that are impossible to represent accurately using the more common floating point numbers. However while libraries are available that support rational numbers in JavaScript, the lack of strict typing means that it is easy to implement pattern methods where computationally expensive conversion from floating point to rational numbers are performed late, and therefore often enough to overload the CPUs, due to the large number of iterative calculations required to estimate a ratio for a given floating point number. To mitigate this problem, we might consider moving to TypeScript in the future.
|
||||
|
||||
# Future Outlook
|
||||
|
||||
The project is still young, with many features on the horizon. As general guiding principles, Strudel aims to be
|
||||
|
||||
1. accessible
|
||||
2. consistent with Tidal's approach to pattern
|
||||
3. modular and extensible
|
||||
|
||||
While Haskell's type system makes it a great language for the ongoing development of Tidal's inner representation of pattern, JavaScript's vibrant ecosystem, flexibility and accessibility makes it a great host for more ad-hoc experiments, including interface design. For the future, it is planned to integrate additional alternative sound engines such as Glicol [@lanChaosprintGlicol2022] and Faust [@FaustProgrammingLanguage2022]. Strudel is already approaching feature parity with Tidal, but there are more Tidal functions to be ported, and work to be done to improve compatibility with Tidal's mini-notation. Tidal version 2.0 is under development, which brings a new representation for sequences to its patterns, which will then be brought to Strudel. Besides sound, other ways to render events are being explored, such as graphical, and choreographic output. We are also looking into alternative ways of editing patterns, including multi-user editing for network music, parsing a novel syntax to escape the constraints of JavaScript, and developing hardware/e-textile interfaces. In summary, there is a lot of fun ahead.
|
||||
|
||||
# Links
|
||||
|
||||
The Strudel REPL is available at <https://strudel.cc>, including an interactive tutorial.
|
||||
The repository is at <https://codeberg.org/uzu/strudel>, all the code is open source under the AGPL-3.0 License.
|
||||
|
||||
# Acknowledgments
|
||||
|
||||
Thanks to the Strudel and wider Tidal, live coding, WebAudio and free/open source software communities for inspiration and support. Alex McLean's work on this project is supported by a UKRI Future Leaders Fellowship [grant number MR/V025260/1].
|
||||
|
||||
# References
|
||||
|
Before Width: | Height: | Size: 220 KiB |
|
Before Width: | Height: | Size: 127 KiB |
|
Before Width: | Height: | Size: 83 KiB |
@@ -1,92 +0,0 @@
|
||||
% Copyright 2014 Michael Sharpe
|
||||
% Based initially on Karl Berry's inconsolata.sty.
|
||||
% You may freely use, modify and/or distribute this file.
|
||||
|
||||
\def\fileversion{1.05}
|
||||
\def\filedate{2014/06/22}
|
||||
\NeedsTeXFormat{LaTeX2e}
|
||||
\ProvidesPackage{inconsolata}[\filedate\space v\fileversion]
|
||||
\message{`inconsolata-zi4' v\fileversion, \filedate\space Text macros for Inconsolata (msharpe)}
|
||||
|
||||
\RequirePackage{textcomp}
|
||||
\RequirePackage{keyval}
|
||||
|
||||
\newcount\zifour@ocount
|
||||
\newif\ifzifour@altzero
|
||||
\newif\ifzifour@noupq
|
||||
\define@key{zifour}{scaled}[1.0]{\def\zifour@scaled{s*[#1]}}
|
||||
|
||||
\DeclareOption*{%
|
||||
\begingroup
|
||||
\edef\x{\endgroup
|
||||
\noexpand\setkeys{zifour}{\CurrentOption}}%
|
||||
\x}
|
||||
|
||||
% by default, change \tt to mean zi4.
|
||||
\newcommand*{\zifour@default}{%
|
||||
\renewcommand*{\ttdefault}{zi4}%
|
||||
}
|
||||
|
||||
% option [nott] to avoid changing tt.
|
||||
\DeclareOption{nott}{%
|
||||
\renewcommand*{\zifour@default}{}%
|
||||
}
|
||||
% option [noupquote] to prevent loading upquote.
|
||||
\DeclareOption{noupquote}{%
|
||||
\zifour@noupqtrue}%
|
||||
|
||||
% option var0---use unslashed zero (slashed is default)
|
||||
\DeclareOption{var0}{%
|
||||
\zifour@altzerotrue\advance\zifour@ocount \tw@ %
|
||||
}
|
||||
\DeclareOption{varl}{%
|
||||
\advance\zifour@ocount \@ne %
|
||||
}
|
||||
\DeclareOption{varqu}{%
|
||||
\advance\zifour@ocount 4\relax %
|
||||
}
|
||||
|
||||
\ProcessOptions*
|
||||
\zifour@default
|
||||
\edef\zifour@opt{\the\zifour@ocount}
|
||||
\ifzifour@altzero
|
||||
\advance\zifour@ocount -\tw@
|
||||
\else
|
||||
\advance\zifour@ocount \tw@
|
||||
\fi
|
||||
\edef\zifour@altopt{\the\zifour@ocount}
|
||||
% define an \altzero macro which flips to slashed, unslashed
|
||||
\def\altzero{{\fontfamily{zi4}%
|
||||
\fontshape{scit}%
|
||||
\selectfont 0}}
|
||||
|
||||
\def\zifour@T@ne@nc{T1}
|
||||
\def\zifour@OT@ne@nc{OT1}
|
||||
\def\zifour@LY@ne@nc{LY1}
|
||||
\def\zifour@QX@nc{QX}
|
||||
\def\zifour@TQS{%
|
||||
\UndeclareTextCommand{\textquotesingle}{\encodingdefault}
|
||||
\DeclareTextSymbol{\textquotesingle}{TS1}{39}}
|
||||
|
||||
\ifzifour@noupq% do nothing
|
||||
% Try to correct for wrong slots for QX
|
||||
\ifx\encodingdefault\zifour@QX@nc
|
||||
\zifour@TQS
|
||||
\else
|
||||
\ifx\encodingdefault\zifour@LY@ne@nc
|
||||
\zifour@TQS
|
||||
\fi
|
||||
\fi
|
||||
\else
|
||||
\AtBeginDocument{%
|
||||
\ifx\encodingdefault\zifour@T@ne@nc % do nothing
|
||||
\else
|
||||
\ifx\encodingdefault\zifour@OT@ne@nc % do nothing
|
||||
\else
|
||||
\zifour@TQS
|
||||
\fi
|
||||
\fi
|
||||
\usepackage{upquote}}
|
||||
\fi
|
||||
|
||||
\endinput
|
||||
@@ -1,63 +0,0 @@
|
||||
$if(false)$ This is a pandoc template and should not be edited. $endif$
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" $if(lang)$ lang="$lang$" xml:lang="$lang$" $endif$>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<meta http-equiv="Content-Style-Type" content="text/css" />
|
||||
<meta name="generator" content="pandoc" />
|
||||
$for(author-meta)$
|
||||
<meta name="author" content="$author-meta$" />
|
||||
$endfor$ $if(date-meta)$
|
||||
<meta name="date" content="$date-meta$" />
|
||||
$endif$
|
||||
<title>$if(title-prefix)$$title-prefix$ - $endif$$pagetitle$</title>
|
||||
<style type="text/css">
|
||||
code {
|
||||
white-space: pre;
|
||||
}
|
||||
</style>
|
||||
$if(quotes)$
|
||||
<style type="text/css">
|
||||
q {
|
||||
quotes: '“' '”' '‘' '’';
|
||||
}
|
||||
</style>
|
||||
$endif$ $if(highlighting-css)$
|
||||
<style type="text/css">
|
||||
$highlighting-css$
|
||||
</style>
|
||||
$endif$
|
||||
<link rel="stylesheet" href="css/iclc.css" $if(html5)$$else$type="text/css" $endif$ />
|
||||
$for(css)$
|
||||
<link rel="stylesheet" href="$css$" $if(html5)$$else$type="text/css" $endif$ />
|
||||
$endfor$ $if(math)$ $math$ $endif$ $for(header-includes)$ $header-includes$ $endfor$
|
||||
</head>
|
||||
<body>
|
||||
$for(include-before)$ $include-before$ $endfor$ $if(title)$
|
||||
<div id="$idprefix$header">
|
||||
<h1 class="title">$title$</h1>
|
||||
$if(subtitle)$
|
||||
<h1 class="subtitle">$subtitle$</h1>
|
||||
$endif$
|
||||
<ul id="authorlist">
|
||||
$for(author)$
|
||||
<li>$author$</li>
|
||||
$endfor$
|
||||
</ul>
|
||||
$if(date)$
|
||||
<h3 class="date">$date$</h3>
|
||||
$endif$
|
||||
</div>
|
||||
$endif$ $if(toc)$
|
||||
<div id="$idprefix$TOC">$toc$</div>
|
||||
$endif$
|
||||
|
||||
<h2 class="abstract">Abstract</h2>
|
||||
<div id="abstract">
|
||||
$if(abstract)$ $abstract$ $else$ Please provide an abstract in the metadata block at the top of your markdown
|
||||
document. Refer to template.txt for details. $endif$
|
||||
</div>
|
||||
|
||||
$body$ $for(include-after)$ $include-after$ $endfor$
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,224 +0,0 @@
|
||||
$if(false)$
|
||||
|
||||
This is a pandoc template and should not be edited.
|
||||
|
||||
$endif$
|
||||
\documentclass[$if(fontsize)$$fontsize$,$endif$$if(lang)$$lang$,$endif$$if(papersize)$$papersize$,$endif$$for(classoption)$$classoption$$sep$,$endfor$]{$documentclass$}
|
||||
|
||||
\usepackage{pandoc/iclc}
|
||||
$if(linestretch)$
|
||||
\usepackage{setspace}
|
||||
\setstretch{$linestretch$}
|
||||
$endif$
|
||||
|
||||
\usepackage{amssymb,amsmath}
|
||||
\usepackage{ifxetex,ifluatex}
|
||||
\usepackage{fixltx2e} % provides \textsubscript
|
||||
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
|
||||
$if(fontfamily)$
|
||||
\usepackage{$fontfamily$}
|
||||
\usepackage{inconsolata}
|
||||
$else$
|
||||
\usepackage{lmodern}
|
||||
$endif$
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage[utf8]{inputenc}
|
||||
$if(euro)$
|
||||
\usepackage{eurosym}
|
||||
$endif$
|
||||
\else % if luatex or xelatex
|
||||
\ifxetex
|
||||
\usepackage{mathspec}
|
||||
\usepackage{xltxtra,xunicode}
|
||||
\else
|
||||
\usepackage{fontspec}
|
||||
\fi
|
||||
\defaultfontfeatures{Mapping=tex-text,Scale=MatchLowercase}
|
||||
\newcommand{\euro}{€}
|
||||
$if(mainfont)$
|
||||
\setmainfont{$mainfont$}
|
||||
$endif$
|
||||
$if(sansfont)$
|
||||
\setsansfont{$sansfont$}
|
||||
$endif$
|
||||
$if(monofont)$
|
||||
\setmonofont[Mapping=tex-ansi]{$monofont$}
|
||||
$endif$
|
||||
$if(mathfont)$
|
||||
\setmathfont(Digits,Latin,Greek){$mathfont$}
|
||||
$endif$
|
||||
\fi
|
||||
% use upquote if available, for straight quotes in verbatim environments
|
||||
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
|
||||
% use microtype if available
|
||||
\IfFileExists{microtype.sty}{%
|
||||
\usepackage{microtype}
|
||||
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
|
||||
}{}
|
||||
$if(geometry)$
|
||||
\usepackage[$for(geometry)$$geometry$$sep$,$endfor$]{geometry}
|
||||
$endif$
|
||||
$if(lang)$
|
||||
\ifxetex
|
||||
\usepackage{polyglossia}
|
||||
\setmainlanguage{$mainlang$}
|
||||
\else
|
||||
\usepackage[shorthands=off,$lang$]{babel}
|
||||
\fi
|
||||
$endif$
|
||||
$if(natbib)$
|
||||
\usepackage{natbib}
|
||||
\bibliographystyle{$if(biblio-style)$$biblio-style$$else$plainnat$endif$}
|
||||
$endif$
|
||||
$if(biblatex)$
|
||||
\usepackage{biblatex}
|
||||
$if(biblio-files)$
|
||||
\bibliography{$biblio-files$}
|
||||
$endif$
|
||||
$endif$
|
||||
$if(listings)$
|
||||
\usepackage{listings}
|
||||
$endif$
|
||||
$if(lhs)$
|
||||
\lstnewenvironment{code}{\lstset{language=Haskell,basicstyle=\small\ttfamily}}{}
|
||||
$endif$
|
||||
$if(highlighting-macros)$
|
||||
$highlighting-macros$
|
||||
$endif$
|
||||
$if(verbatim-in-note)$
|
||||
\usepackage{fancyvrb}
|
||||
\VerbatimFootnotes
|
||||
$endif$
|
||||
$if(tables)$
|
||||
\usepackage{longtable,booktabs}
|
||||
$endif$
|
||||
$if(csl-refs)$
|
||||
\newlength{\cslhangindent}
|
||||
\setlength{\cslhangindent}{1.5em}
|
||||
\newenvironment{CSLReferences}%
|
||||
{$if(csl-hanging-indent)$\setlength{\parindent}{0pt}%
|
||||
\everypar{\setlength{\hangindent}{\cslhangindent}}\ignorespaces$endif$}%
|
||||
{\par}
|
||||
$endif$
|
||||
$if(graphics)$
|
||||
\usepackage{graphicx}
|
||||
\makeatletter
|
||||
\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi}
|
||||
\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi}
|
||||
\makeatother
|
||||
% Scale images if necessary, so that they will not overflow the page
|
||||
% margins by default, and it is still possible to overwrite the defaults
|
||||
% using explicit options in \includegraphics[width, height, ...]{}
|
||||
\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}
|
||||
$endif$
|
||||
\ifxetex
|
||||
\usepackage[setpagesize=false, % page size defined by xetex
|
||||
unicode=false, % unicode breaks when used with xetex
|
||||
xetex]{hyperref}
|
||||
\else
|
||||
\usepackage[unicode=true]{hyperref}
|
||||
\fi
|
||||
\hypersetup{breaklinks=true,
|
||||
bookmarks=true,
|
||||
pdfauthor={$author-meta$},
|
||||
pdftitle={$title-meta$},
|
||||
colorlinks=true,
|
||||
citecolor=$if(citecolor)$$citecolor$$else$blue$endif$,
|
||||
urlcolor=$if(urlcolor)$$urlcolor$$else$blue$endif$,
|
||||
linkcolor=$if(linkcolor)$$linkcolor$$else$magenta$endif$,
|
||||
pdfborder={0 0 0}}
|
||||
\urlstyle{same} % don't use monospace font for urls
|
||||
$if(links-as-notes)$
|
||||
% Make links footnotes instead of hotlinks:
|
||||
\renewcommand{\href}[2]{#2\footnote{\url{#1}}}
|
||||
$endif$
|
||||
$if(strikeout)$
|
||||
\usepackage[normalem]{ulem}
|
||||
% avoid problems with \sout in headers with hyperref:
|
||||
\pdfstringdefDisableCommands{\renewcommand{\sout}{}}
|
||||
$endif$
|
||||
\setlength{\parindent}{0pt}
|
||||
\setlength{\parskip}{6pt plus 2pt minus 1pt}
|
||||
\setlength{\emergencystretch}{3em} % prevent overfull lines
|
||||
\providecommand{\tightlist}{%/
|
||||
\setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
|
||||
$if(numbersections)$
|
||||
\setcounter{secnumdepth}{5}
|
||||
$else$
|
||||
\setcounter{secnumdepth}{0}
|
||||
$endif$
|
||||
$if(verbatim-in-note)$
|
||||
\VerbatimFootnotes % allows verbatim text in footnotes
|
||||
$endif$
|
||||
|
||||
$if(title)$
|
||||
\title{$title$$if(subtitle)$\\\vspace{0.5em}{\large $subtitle$}$endif$}
|
||||
$endif$
|
||||
$if(author)$
|
||||
\author{
|
||||
$for(author)$
|
||||
$author.name$ \\
|
||||
$author.affiliation$\\
|
||||
\href{mailto:$author.email$}{$author.email$}
|
||||
$sep$ \and
|
||||
$endfor$
|
||||
}
|
||||
$endif$
|
||||
\date{$date$}
|
||||
$for(header-includes)$
|
||||
$header-includes$
|
||||
$endfor$
|
||||
|
||||
\begin{document}
|
||||
$if(title)$
|
||||
\maketitle
|
||||
$endif$
|
||||
\begin{abstract}
|
||||
$if(abstract)$
|
||||
$abstract$
|
||||
$else$
|
||||
Please provide an abstract in the metadata block at the top of the
|
||||
markdown document. Refer to template.txt for details. $endif$
|
||||
\end{abstract}
|
||||
|
||||
$for(include-before)$
|
||||
$include-before$
|
||||
|
||||
$endfor$
|
||||
$if(toc)$
|
||||
{
|
||||
\hypersetup{linkcolor=black}
|
||||
\setcounter{tocdepth}{$toc-depth$}
|
||||
\tableofcontents
|
||||
}
|
||||
$endif$
|
||||
$if(lot)$
|
||||
\listoftables
|
||||
$endif$
|
||||
$if(lof)$
|
||||
\listoffigures
|
||||
$endif$
|
||||
$body$
|
||||
|
||||
$if(natbib)$
|
||||
$if(biblio-files)$
|
||||
$if(biblio-title)$
|
||||
$if(book-class)$
|
||||
\renewcommand\bibname{$biblio-title$}
|
||||
$else$
|
||||
\renewcommand\refname{$biblio-title$}
|
||||
$endif$
|
||||
$endif$
|
||||
\bibliography{$biblio-files$}
|
||||
|
||||
$endif$
|
||||
$endif$
|
||||
$if(biblatex)$
|
||||
\printbibliography$if(biblio-title)$[title=$biblio-title$]$endif$
|
||||
|
||||
$endif$
|
||||
$for(include-after)$
|
||||
$include-after$
|
||||
|
||||
$endfor$
|
||||
\end{document}
|
||||
@@ -1,54 +0,0 @@
|
||||
|
||||
\def\Hline{\noalign{\hrule height 0.4mm}}
|
||||
%\newcommand{\bm}[1]{\mbox{\boldmath{$#1$}}}
|
||||
\newcommand{\figbox}[1]{\fbox{\parbox{\columnwidth}{\centering{ #1 }}}}
|
||||
\newcommand{\range}[2]{{#1,\cdots,#2\;}}
|
||||
\newcommand{\secref}[1]{\mbox{Section~\ref{#1}}}
|
||||
\newcommand{\tabref}[1]{\mbox{Table~\ref{#1}}}
|
||||
\newcommand{\figref}[1]{\mbox{Figure~\ref{#1}}}
|
||||
\newcommand{\eqnref}[1]{\mbox{Eq.~(\ref{#1})}}
|
||||
|
||||
\renewcommand{\sfdefault}{phv}
|
||||
\renewcommand{\rmdefault}{ptm}
|
||||
\renewcommand{\ttdefault}{pcr}
|
||||
|
||||
\setlength{\paperheight}{297mm}
|
||||
\setlength{\paperwidth}{210mm}
|
||||
\setlength{\textheight}{252mm}
|
||||
\setlength{\textwidth}{172mm}
|
||||
\setlength{\columnsep}{8mm}
|
||||
\setlength{\headheight}{0mm}
|
||||
\setlength{\voffset}{-12mm}
|
||||
\setlength{\hoffset}{0mm}
|
||||
\setlength{\marginparwidth}{0mm}
|
||||
\setlength{\parindent}{2mm} %1pc
|
||||
\setlength{\topmargin}{-5mm}
|
||||
\setlength{\oddsidemargin}{-6mm}
|
||||
\setlength{\evensidemargin}{-6mm}
|
||||
|
||||
\setlength\normallineskip{1\p@}
|
||||
\setlength\parskip{0\p@ \@plus \p@}
|
||||
%\def\baselinestretch{0.98}
|
||||
|
||||
\def\normalsize{\@setsize\normalsize{12pt}\xpt\@xpt}
|
||||
\def\small{\@setsize\small{10pt}\ixpt\@ixpt}
|
||||
\def\footnotesize{\@setsize\footnotesize{8pt}\viiipt\@viiipt}
|
||||
\def\scriptsize{\@setsize\scriptsize{8pt}\viipt\@viipt}
|
||||
\def\tiny{\@setsize\tiny{7pt}\vipt\@vipt}
|
||||
\def\large{\@setsize\large{14pt}\xiipt\@xiipt}
|
||||
\def\Large{\@setsize\Large{16pt}\xivpt\@xivpt}
|
||||
\def\LARGE{\@setsize\LARGE{20pt}\xviipt\@xviipt}
|
||||
\def\huge{\@setsize\huge{23pt}\xxpt\@xxpt}
|
||||
\def\Huge{\@setsize\Huge{28pt}\xxvpt\@xxvpt}
|
||||
|
||||
\pagestyle{empty}
|
||||
|
||||
\def\abstract{
|
||||
\begin{center}{
|
||||
\bf ABSTRACT
|
||||
}
|
||||
\end{center}
|
||||
}
|
||||
\def\endabstract{\par}
|
||||
|
||||
\flushbottom
|
||||
@@ -1,349 +0,0 @@
|
||||
---
|
||||
date: 2022-03-22
|
||||
references:
|
||||
- abstract: In this artist statement, I will discuss the tension between
|
||||
source code as an interactive system for performers and source code
|
||||
as information and entertainment for audiences in live-coding
|
||||
performances. I then describe augmentations I developed for the
|
||||
presentation of source code in the live-coding environment Gibber,
|
||||
including animations and annotations that visually reveal aspects of
|
||||
system state during performances. I briefly describe audience
|
||||
responses to these techniques and, more importantly, how they are
|
||||
critical to my own artistic practice.
|
||||
accessed:
|
||||
date-parts:
|
||||
- - 2022
|
||||
- 3
|
||||
- 24
|
||||
author:
|
||||
- family: Roberts
|
||||
given: Charles
|
||||
container-title: International Journal of Performance Arts and Digital
|
||||
Media
|
||||
DOI: 10.1080/14794713.2016.1227602
|
||||
id: "https://www.tandfonline.com/doi/abs/10.1080/14794713.2016.1227602?journalCode_x61_rpdm20"
|
||||
ISSN: 1479-4713
|
||||
issue: 2
|
||||
issued:
|
||||
date-parts:
|
||||
- - 2016
|
||||
- 7
|
||||
keyword: Live coding, psychology of programming, notation, audiences,
|
||||
algorithms
|
||||
page: 201-206
|
||||
title: Code as information and code as spectacle
|
||||
type: article-journal
|
||||
URL: "https://doi.org/10.1080/14794713.2016.1227602"
|
||||
volume: 12
|
||||
- abstract: The TidalCycles (or Tidal for short) live coding environment
|
||||
has been developed since around 2009, via several rewrites of its
|
||||
core representation. Rather than having fixed goals, this
|
||||
development has been guided by use, motivated by the open aim to
|
||||
make music. This development process can be seen as a long-form
|
||||
improvisation, with insights into the nature of Tidal gained through
|
||||
the process of writing it, feeding back to guide the next steps of
|
||||
development. This brings the worrying thought that key insights will
|
||||
have been missed along this development journey, that would
|
||||
otherwise have lead to very different software. Indeed participants
|
||||
at beginners' workshops that I have lead or co-lead have often asked
|
||||
questions without good answers, because they made deficiencies or
|
||||
missing features in the software clear. It is well known that a
|
||||
beginner's mind is able to see much that an expert has become blind
|
||||
to. Running workshops are an excellent way to find new development
|
||||
ideas, but the present paper explores a different technique -- the
|
||||
rewrite.
|
||||
accessed:
|
||||
date-parts:
|
||||
- - 2022
|
||||
- 3
|
||||
- 24
|
||||
id: "https://zenodo.org/record/5788732"
|
||||
issued:
|
||||
date-parts:
|
||||
- - 2021
|
||||
- 12
|
||||
keyword: live coding, algorithmic pattern, tidalcycles, haskell,
|
||||
python
|
||||
publisher-place: Valdivia, Chile
|
||||
title: Alternate Timelines for TidalCycles
|
||||
URL: "https://zenodo.org/record/5788732"
|
||||
- abstract: A JavaScript dialect of its mini-notation for pattern is
|
||||
created, enabling easy integration with creative coding tools and an
|
||||
accompanying technique for visually annotating the playback of
|
||||
TidalCycles patterns over time. TidalCycles has rapidly become the
|
||||
most popular system for many styles of live coding performance, in
|
||||
particular Algoraves. We created a JavaScript dialect of its
|
||||
mini-notation for pattern, enabling easy integration with creative
|
||||
coding tools. Our research pairs a formalism describing the
|
||||
mini-notation with a small JavaScript library for generating events
|
||||
over time; this library is suitable for generating events inside of
|
||||
an AudioWorkletProcessor thread and for assisting with scheduling in
|
||||
JavaScript environments more generally. We describe integrating the
|
||||
library into the two live coding systems, Gibber and Hydra, and
|
||||
discuss an accompanying technique for visually annotating the
|
||||
playback of TidalCycles patterns over time.
|
||||
accessed:
|
||||
date-parts:
|
||||
- - 2022
|
||||
- 4
|
||||
- 12
|
||||
author:
|
||||
- family: Roberts
|
||||
given: Charles
|
||||
container-title: www.semanticscholar.org
|
||||
id: "https://www.semanticscholar.org/paper/Bringing-the-TidalCycles-Mini-Notation-to-the-Roberts/74965efadd572ae3f40d14c633a5c8581c1b9f42"
|
||||
issued:
|
||||
date-parts:
|
||||
- - 2019
|
||||
title: Bringing the TidalCycles Mini-Notation to the Browser
|
||||
URL: "https://www.semanticscholar.org/paper/Bringing-the-TidalCycles-Mini-Notation-to-the-Roberts/74965efadd572ae3f40d14c633a5c8581c1b9f42"
|
||||
title: Strudel
|
||||
url2cite: all-links
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
This paper introduces Strudel, an alternative implementation of the
|
||||
TidalCycles live coding system, using the JavaScript programming
|
||||
language.
|
||||
|
||||
# Background
|
||||
|
||||
General motivations / related work. Reference vortex paper and summarise
|
||||
its background.
|
||||
|
||||
The reimplementation of TidalCycles in Python (cite TidalVortex) showed
|
||||
that it is possible to translate pure functional reactive programming
|
||||
ideas to a multi paradigm language. It proved to be a stepping stone to
|
||||
move to other multi-paradigm languages, like JavaScript. A significant
|
||||
part of of the Python codebase could be ported to JavaScript by
|
||||
syntactical adjustments.
|
||||
|
||||
# Introducing TidalStrudel
|
||||
|
||||
(do we want to call it TidalStrudel once, and Strudel for short from
|
||||
then on as with vortex? Or just stick with Strudel? Should we start
|
||||
calling TidalCycles just Cycles?? froos: I think TidalStrudel sounds a
|
||||
bit weird, but we can stick to the TidalX naming scheme if that's
|
||||
important. For me, StrudelCycles sounds better, because it has 3/4
|
||||
phonems in common with TidalCycles)
|
||||
|
||||
- Motivating musical example
|
||||
|
||||
# Tidal patterns
|
||||
|
||||
(should we explain shortly what tidal patterns do in general here?)
|
||||
|
||||
The essence of TidalCycles are Patterns. Patterns are abstract entities
|
||||
that represent flows of time. Taking a time span as its input, a Pattern
|
||||
can output a set of events that happen within that time span. It depends
|
||||
on the structure of the Pattern where the events are placed. From now
|
||||
on, this process of generating events from a time span will be called
|
||||
**querying**. Example:
|
||||
|
||||
<MiniRepl tune={`const pattern = sequence(c3, [e3, g3]);
|
||||
const events = pattern.query(0, 1);
|
||||
console.log(events.map(e => e.show()))`} />
|
||||
|
||||
In this example, we create a pattern using the `sequence` function and
|
||||
**query** it for the timespan from `0` to `1`. Those numbers represent
|
||||
units of time called **cycles**. The length of one cycle defaults to one
|
||||
second, but could be any number of seconds. The console output looks
|
||||
like this:
|
||||
|
||||
<MiniRepl tune={`(0 -> 1/2 c3)
|
||||
(1/2 -> 3/4 e3)
|
||||
(3/2 -> 1 g3)`} />
|
||||
|
||||
In this output, each line represents one event. The two fractions
|
||||
represent the begin and end time of the event, followed by its value. In
|
||||
this case, the events are placed in sequential order, where c3 takes the
|
||||
first half, and e3 and g3 together take the second half. This temporal
|
||||
placement is the result of the `sequence` function, which divides its
|
||||
arguments equally over one cycle. If an argument is an array, the same
|
||||
rule applies to that part of the sequence. In our example e3 and g3 are
|
||||
divided equally over the second half of the whole sequence.
|
||||
|
||||
# Mini Notation
|
||||
|
||||
In this example, the Pattern is created using the `mini` function, which
|
||||
parses Tidal's Mini Notation. The Mini Notation is a Domain Specific
|
||||
Language (DSL) that allows expressing rhythms in a short mannger.
|
||||
|
||||
- Some comparisons of -Strudel with -Vortex and -Cycles code?
|
||||
|
||||
(the following examples are from vortex paper, with added js versions)
|
||||
|
||||
## 1
|
||||
|
||||
<MiniRepl tune={`sound "bd ~ [sd cp]"`} />
|
||||
<MiniRepl tune={`sound("bd", silence, ["sd", "cp"])`} />
|
||||
<MiniRepl tune={`sound("bd ~ [sd cp]")`} />
|
||||
|
||||
without mini notation:
|
||||
|
||||
<MiniRepl tune={`sound $ cat
|
||||
[pure "bd", silence,
|
||||
cat(pure "sd", pure "cp")]`} />
|
||||
<MiniRepl tune={`sound('bd', silence, cat('sd', 'cp'))`} />
|
||||
|
||||
## 2
|
||||
|
||||
<MiniRepl tune={`sound "bd ~ <sd cp>"`} />
|
||||
<MiniRepl tune={`sound("bd", silence, slowcat("sd", "cp"))`} />
|
||||
<MiniRepl tune={`sound("bd ~ <sd cp>")
|
||||
// sound('bd', silence, slowcat('sd', 'cp'))`} />
|
||||
|
||||
## 3
|
||||
|
||||
<MiniRepl tune={`sound "bd {cp sd, lt mt ht}"`} />
|
||||
<MiniRepl tune={`sound("bd", pm(["cp", "sd"], ["lt", "mt", "ht"]))`} />
|
||||
<MiniRepl tune={`?`} />
|
||||
|
||||
## 4
|
||||
|
||||
<MiniRepl tune={`sound "bd {cp sd, [lt mt,bd bd bd] ht}"`} />
|
||||
<MiniRepl tune={` sound("bd", pm(["cp", "sd"],
|
||||
[pr(["lt", "mt"],
|
||||
["bd", "bd", "bd"]
|
||||
),
|
||||
"ht" ]))`} />
|
||||
<MiniRepl tune={`??`} />
|
||||
|
||||
## 5
|
||||
|
||||
<MiniRepl tune={`sound "bd sd cp" # speed "1 2"`} />
|
||||
<MiniRepl tune={`sound("bd", "sd", "cp") >> speed (1, 2)`} />
|
||||
<MiniRepl tune={`sound("bd sd cp").speed("1 2")`} />
|
||||
|
||||
(operator overloading like in vortex?)
|
||||
|
||||
## 6
|
||||
|
||||
<MiniRepl tune={`rev $ sound "bd sd"`} />
|
||||
<MiniRepl tune={`rev(sound("bd", "sd"))
|
||||
sound("bd", "sd").rev()`} />
|
||||
<MiniRepl tune={`rev(sound("bd sd"))
|
||||
sound("bd sd").rev()`} />
|
||||
|
||||
## 7
|
||||
|
||||
<MiniRepl tune={`jux rev $ every 3 (fast 2) $ sound "bd sd"`} />
|
||||
<MiniRepl tune={`jux(rev, every(3, fast(2), sound("bd", "sd")))
|
||||
sound("bd","sd").every(3, fast(2)).jux(rev)`} />
|
||||
<MiniRepl tune={`jux(rev, every(3, fast(2), sound("bd sd")))
|
||||
sound("bd sd").every(3, fast(2)).jux(rev)`} />
|
||||
|
||||
(partial application)
|
||||
|
||||
## 8
|
||||
|
||||
<MiniRepl tune={`n ("1 2 3" + "4 5") # sound "drum"`} />
|
||||
<MiniRepl tune={`n (sequence(1,2,3) + sequence(4,5)) >> sound "drum"`} />
|
||||
<MiniRepl tune={`n("1 2 3".add("4 5")).sound("drum")
|
||||
n("5 [6 7] 8").sound("drum")`} />
|
||||
|
||||
(operator overloading?)
|
||||
|
||||
## 9
|
||||
|
||||
<MiniRepl tune={`speed("1 2 3" + sine)`} />
|
||||
<MiniRepl tune={`speed(sequence(1,2,3) + sine)`} />
|
||||
<MiniRepl tune={`speed("1 2 3".add(sine))
|
||||
"c3*4".add(sine.mul(12).slow(8)).pianoroll()`} />
|
||||
|
||||
## 10
|
||||
|
||||
- Mininotation
|
||||
|
||||
# Strudel/web specifics
|
||||
|
||||
Some discussion about whether strudel is really a port of TidalCycles,
|
||||
or whether javascript affordances mean it's going its own way..
|
||||
|
||||
- Recursive Scheduling: "calling itself in the future"
|
||||
- Optimizing Syntax for minimal keystrokes / readability: "AST
|
||||
Hacking" via shift-ast pseudo variables
|
||||
- Handling mininotation - double quoted and template strings to
|
||||
mini calls
|
||||
- Operator overloading
|
||||
- Fixing inconsistencies (e.g. with stut/echo) adding source locations
|
||||
- Dynamic HUD: Highlighting + drawing
|
||||
- Translation of Tidal concepts to Javascript - different constraints,
|
||||
affordances, aesthetics
|
||||
- Dynamic Harmonic Programming?
|
||||
- emulating musician thought patterns
|
||||
- microtonal features? webserial
|
||||
|
||||
## User Code Transpilation
|
||||
|
||||
(compare user input vs shifted output)
|
||||
|
||||
### double quotes -\> mini calls
|
||||
|
||||
<MiniRepl tune={`"c3 e3" // or `c3 e3``} />
|
||||
<MiniRepl tune={`mini("c3 e3")`} />
|
||||
|
||||
### operator overloading
|
||||
|
||||
<MiniRepl tune={`cat(c3, e3) * 4`} />
|
||||
<MiniRepl tune={`reify(cat("c3","e3")).fast(4)`} />
|
||||
|
||||
(reify is redundant here, the shapeshifter could have an additional
|
||||
check...)
|
||||
|
||||
(TBD: ability to multiply mini notation strings)
|
||||
|
||||
### pseudo variables
|
||||
|
||||
<MiniRepl tune={`cat(c3, r, e3)`} />
|
||||
<MiniRepl tune={`cat("c3",silence,"e3")`} />
|
||||
|
||||
### locations
|
||||
|
||||
<MiniRepl tune={`cat(c3, e3)`} />
|
||||
<MiniRepl tune={`cat(
|
||||
reify("c3").withLocation([1,4,4],[1,6,6]),
|
||||
reify("e3").withLocation([1,8,8],[1,10,10])
|
||||
)`} />
|
||||
<MiniRepl tune={`mini("c3 e3")`} />
|
||||
|
||||
with locations:
|
||||
|
||||
<MiniRepl tune={`// "c3 e3"
|
||||
mini("c3 e3").withMiniLocation([1,0,0],[1,7,7])`} />
|
||||
|
||||
(talk about mini adding locations of mini notation parser)
|
||||
|
||||
### top level await
|
||||
|
||||
<MiniRepl tune={`const p = (await piano()).toDestination()
|
||||
cat(c3).tone(p)`} />
|
||||
<MiniRepl tune={`(async()=>{
|
||||
const p = (await piano()).toDestination();
|
||||
return cat("c3").tone(p);
|
||||
})()`} />
|
||||
|
||||
# Musical examples
|
||||
|
||||
...
|
||||
|
||||
# Ongoing work/future aims
|
||||
|
||||
- WASM Sound Backend
|
||||
- OSC -\> Supercollider
|
||||
- mininotation as the 'regex' of metre
|
||||
|
||||
That
|
||||
@https://www.tandfonline.com/doi/abs/10.1080/14794713.2016.1227602?journalCode_x61_rpdm20
|
||||
are excellent, I reference their work at least twice per sentence
|
||||
[@https://www.tandfonline.com/doi/abs/10.1080/14794713.2016.1227602?journalCode_x61_rpdm20,
|
||||
p. 3]. Another reference [@https://zenodo.org/record/5788732].
|
||||
|
||||
<MiniRepl tune={`"1 2 3"`} />
|
||||
|
||||
# References
|
||||
|
||||
- gibber
|
||||
- krill
|
||||
- glicol
|
||||
@@ -1,354 +0,0 @@
|
||||
---
|
||||
title: 'StrudelCycles: live coding algorithmic patterns on the web'
|
||||
date: '2022-03-22'
|
||||
url2cite: all-links
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
This paper introduces Strudel, an alternative implementation of the TidalCycles live coding system, using the JavaScript programming language.
|
||||
|
||||
# Background
|
||||
|
||||
TidalCycles (or *Tidal* for short) has been developed since around 2009, as a system for live coding algorithmic patterns, particularly in music [@tidalcycles]. Tidal is embedded in the pure functional *Haskell* programming language, taking advantage of its terse syntax and advanced type system. Over the past decade, Tidal has undergone a number of re-writes, developing a functional reactive representation of pattern, where patterns may be combined and transformed in a wide variety of ways [@alternate-timelines]. Over this time is has gained diverse ideas from other patterned forms, including from computer music [@spiegel], Indian classical music [@bel], textiles [@fabricating], improvised percussion [@hession], and Ancient Greek lyric [@cyclic-patterns].
|
||||
|
||||
Most recently, attention has turned to transferring Tidal's ideas to other, less 'pure' languages; firstly, to the Python programming language as *TidalVortex* [@tidalvortex] (*Vortex* for short), and now to JavaScript as StrudelCycles (*Strudel* for short), the topic of the present paper. For general background on the motivations for porting Tidal to a multi-paradigm programming language, please see the TidalVortex paper [@tidalvortex]. The motivations for porting it to JavaScript are similar, with a particular slanting on accessibility - of course, a web browser based application does not require any installation. As with Vortex though, it is important to point out that this is a creative, free/open source project, and as such, an primary motivation will always be developer's curiosity, and market-driven perspectives on development choices may even be demotivational.
|
||||
|
||||
General motivations / related work.
|
||||
Reference vortex paper and summarise its background.
|
||||
|
||||
The reimplementation of TidalCycles in Python (cite TidalVortex) showed that it is possible to translate pure functional reactive programming ideas to a multi paradigm language. It proved to be a stepping stone to move to other multi-paradigm languages, like JavaScript. A significant part of of the Python codebase could be quickly ported to JavaScript by syntactical adjustments.
|
||||
|
||||
# Introducing Strudel
|
||||
|
||||
* Motivating musical example
|
||||
|
||||
# Tidal patterns
|
||||
|
||||
(should we explain shortly what tidal patterns do in general here?)
|
||||
|
||||
The essence of TidalCycles are Patterns. Patterns are abstract entities that represent flows of time, supporting both continuous changes (like signals) and discrete events (like notes).
|
||||
Taking a time span as its input, a Pattern can output a set of events that happen within that time span.
|
||||
It depends on the structure of the Pattern where the events are placed.
|
||||
From now on, this process of generating events from a time span will be called **querying**.
|
||||
Example:
|
||||
|
||||
```js
|
||||
const pattern = sequence(c3, [e3, g3]);
|
||||
const events = pattern.query(0, 1);
|
||||
console.log(events.map(e => e.show()))
|
||||
```
|
||||
|
||||
In this example, we create a pattern using the `sequence` function and **query** it for the timespan from `0` to `1`.
|
||||
Those numbers represent units of time called **cycles**. The length of one cycle defaults to one second, but could be any number of seconds.
|
||||
The console output looks like this:
|
||||
|
||||
```js
|
||||
(0 -> 1/2 c3)
|
||||
(1/2 -> 3/4 e3)
|
||||
(3/2 -> 1 g3)
|
||||
```
|
||||
|
||||
In this output, each line represents one event. The two fractions represent the begin and end time of the event, followed by its value.
|
||||
In this case, the events are placed in sequential order, where c3 takes the first half, and e3 and g3 together take the second half.
|
||||
This temporal placement is the result of the `sequence` function, which divides its arguments equally over one cycle.
|
||||
If an argument is an array, the same rule applies to that part of the sequence. In our example e3 and g3 are divided equally over the second half of the whole sequence.
|
||||
|
||||
# Mini Notation
|
||||
|
||||
In this example, the Pattern is created using the `mini` function, which parses Tidal's Mini Notation.
|
||||
The Mini Notation is a Domain Specific Language (DSL) that allows expressing rhythms in a short mannger.
|
||||
|
||||
* Some comparisons of -Strudel with -Vortex and -Cycles code?
|
||||
|
||||
(the following examples are from vortex paper, with added js versions)
|
||||
|
||||
## 1
|
||||
|
||||
```haskell
|
||||
sound "bd ~ [sd cp]"
|
||||
```
|
||||
|
||||
```python
|
||||
sound("bd", silence, ["sd", "cp"])
|
||||
```
|
||||
|
||||
```javascript
|
||||
sound("bd ~ [sd cp]")
|
||||
```
|
||||
|
||||
without mini notation:
|
||||
|
||||
```haskell
|
||||
sound $ cat
|
||||
[pure "bd", silence,
|
||||
cat(pure "sd", pure "cp")]
|
||||
```
|
||||
|
||||
```javascript
|
||||
sound('bd', silence, cat('sd', 'cp'))
|
||||
```
|
||||
|
||||
## 2
|
||||
|
||||
```haskell
|
||||
sound "bd ~ <sd cp>"
|
||||
```
|
||||
|
||||
```python
|
||||
sound("bd", silence, slowcat("sd", "cp"))
|
||||
```
|
||||
|
||||
```javascript
|
||||
sound("bd ~ <sd cp>")
|
||||
// sound('bd', silence, slowcat('sd', 'cp'))
|
||||
```
|
||||
|
||||
## 3
|
||||
|
||||
```haskell
|
||||
sound "bd {cp sd, lt mt ht}"
|
||||
```
|
||||
|
||||
```python
|
||||
sound("bd", pm(["cp", "sd"], ["lt", "mt", "ht"]))
|
||||
```
|
||||
|
||||
```js
|
||||
?
|
||||
```
|
||||
|
||||
## 4
|
||||
|
||||
```haskell
|
||||
sound "bd {cp sd, [lt mt,bd bd bd] ht}"
|
||||
```
|
||||
|
||||
```python
|
||||
sound("bd", pm(["cp", "sd"],
|
||||
[pr(["lt", "mt"],
|
||||
["bd", "bd", "bd"]
|
||||
),
|
||||
"ht" ]))
|
||||
```
|
||||
|
||||
```js
|
||||
??
|
||||
```
|
||||
|
||||
## 5
|
||||
|
||||
```haskell
|
||||
sound "bd sd cp" # speed "1 2"
|
||||
```
|
||||
|
||||
```python
|
||||
sound("bd", "sd", "cp") >> speed (1, 2)
|
||||
```
|
||||
|
||||
```javascript
|
||||
sound("bd sd cp").speed("1 2")
|
||||
```
|
||||
|
||||
(operator overloading like in vortex?)
|
||||
|
||||
## 6
|
||||
|
||||
```haskell
|
||||
rev $ sound "bd sd"
|
||||
```
|
||||
|
||||
```python
|
||||
rev(sound("bd", "sd"))
|
||||
sound("bd", "sd").rev()
|
||||
```
|
||||
|
||||
```javascript
|
||||
rev(sound("bd sd"))
|
||||
sound("bd sd").rev()
|
||||
```
|
||||
|
||||
## 7
|
||||
|
||||
```haskell
|
||||
jux rev $ every 3 (fast 2) $ sound "bd sd"
|
||||
```
|
||||
|
||||
```python
|
||||
jux(rev, every(3, fast(2), sound("bd", "sd")))
|
||||
sound("bd","sd").every(3, fast(2)).jux(rev)
|
||||
```
|
||||
|
||||
```js
|
||||
jux(rev, every(3, fast(2), sound("bd sd")))
|
||||
sound("bd sd").every(3, fast(2)).jux(rev)
|
||||
```
|
||||
|
||||
(partial application)
|
||||
|
||||
## 8
|
||||
|
||||
```haskell
|
||||
n ("1 2 3" + "4 5") # sound "drum"
|
||||
```
|
||||
|
||||
```python
|
||||
n (sequence(1,2,3) + sequence(4,5)) >> sound "drum"
|
||||
```
|
||||
|
||||
```js
|
||||
n("1 2 3".add("4 5")).sound("drum")
|
||||
n("5 [6 7] 8").sound("drum")
|
||||
```
|
||||
|
||||
(operator overloading?)
|
||||
|
||||
## 9
|
||||
|
||||
```haskell
|
||||
speed("1 2 3" + sine)
|
||||
```
|
||||
|
||||
```python
|
||||
speed(sequence(1,2,3) + sine)
|
||||
```
|
||||
|
||||
```js
|
||||
speed("1 2 3".add(sine))
|
||||
"c3*4".add(sine.mul(12).slow(8)).pianoroll()
|
||||
```
|
||||
|
||||
## 10
|
||||
|
||||
* Mininotation
|
||||
|
||||
# Strudel/web specifics
|
||||
|
||||
Some discussion about whether strudel is really a port of TidalCycles, or whether javascript affordances mean it's going its own way..
|
||||
|
||||
* Recursive Scheduling: "calling itself in the future"
|
||||
* Optimizing Syntax for minimal keystrokes / readability: "AST Hacking" via shift-ast
|
||||
pseudo variables
|
||||
* Handling mininotation - double quoted and template strings to mini calls
|
||||
* Operator overloading
|
||||
* Fixing inconsistencies (e.g. with stut/echo)
|
||||
adding source locations
|
||||
* Dynamic HUD: Highlighting + drawing
|
||||
* Translation of Tidal concepts to Javascript - different constraints, affordances, aesthetics
|
||||
* Dynamic Harmonic Programming?
|
||||
* emulating musician thought patterns
|
||||
* microtonal features?
|
||||
webserial
|
||||
|
||||
## User Code Transpilation
|
||||
|
||||
(compare user input vs shifted output)
|
||||
|
||||
### double quotes -> mini calls
|
||||
|
||||
```javascript
|
||||
"c3 e3" // or `c3 e3`
|
||||
```
|
||||
|
||||
```javascript
|
||||
mini("c3 e3")
|
||||
```
|
||||
|
||||
### operator overloading
|
||||
|
||||
```javascript
|
||||
cat(c3, e3) * 4
|
||||
```
|
||||
|
||||
```javascript
|
||||
reify(cat("c3","e3")).fast(4)
|
||||
```
|
||||
|
||||
(reify is redundant here, the shapeshifter could have an additional check...)
|
||||
|
||||
(TBD: ability to multiply mini notation strings)
|
||||
|
||||
### pseudo variables
|
||||
|
||||
```javascript
|
||||
cat(c3, r, e3)
|
||||
```
|
||||
|
||||
```javascript
|
||||
cat("c3",silence,"e3")
|
||||
```
|
||||
|
||||
### locations
|
||||
|
||||
```javascript
|
||||
cat(c3, e3)
|
||||
```
|
||||
|
||||
```javascript
|
||||
cat(
|
||||
reify("c3").withLocation([1,4,4],[1,6,6]),
|
||||
reify("e3").withLocation([1,8,8],[1,10,10])
|
||||
)
|
||||
```
|
||||
|
||||
```javascript
|
||||
mini("c3 e3")
|
||||
```
|
||||
|
||||
with locations:
|
||||
|
||||
```javascript
|
||||
// "c3 e3"
|
||||
mini("c3 e3").withMiniLocation([1,0,0],[1,7,7])
|
||||
```
|
||||
|
||||
(talk about mini adding locations of mini notation parser)
|
||||
|
||||
### top level await
|
||||
|
||||
```javascript
|
||||
const p = (await piano()).toDestination()
|
||||
cat(c3).tone(p)
|
||||
```
|
||||
|
||||
```javascript
|
||||
(async()=>{
|
||||
const p = (await piano()).toDestination();
|
||||
return cat("c3").tone(p);
|
||||
})()
|
||||
```
|
||||
|
||||
# Musical examples
|
||||
|
||||
...
|
||||
|
||||
# Ongoing work/future aims
|
||||
|
||||
* WASM Sound Backend
|
||||
* OSC -> Supercollider
|
||||
* mininotation as the 'regex' of metre
|
||||
|
||||
That @roberts2016 are excellent, I reference their work at least twice per sentence [@roberts2016, p. 3].
|
||||
|
||||
```javascript
|
||||
"1 2 3"
|
||||
```
|
||||
|
||||
# References
|
||||
|
||||
[@roberts2016]: https://www.tandfonline.com/doi/abs/10.1080/14794713.2016.1227602?journalCode=rpdm20
|
||||
[@alternate-timelines]: https://zenodo.org/record/5788732
|
||||
[@tidal.pegjs]: https://www.semanticscholar.org/paper/Bringing-the-TidalCycles-Mini-Notation-to-the-Roberts/74965efadd572ae3f40d14c633a5c8581c1b9f42
|
||||
[@tidalvortex]: https://zenodo.org/record/6456380
|
||||
[@ogborn17]: https://www.semanticscholar.org/paper/Estuary%3A-Browser-based-Collaborative-Projectional-Ogborn-Beverley/c6b5d34575d6230dfd8751ca4af8e5f6e44d916b
|
||||
[@tidalcycles]: https://dl.acm.org/doi/10.1145/2633638.2633647
|
||||
[@hession]: https://www.scopus.com/record/display.uri?eid=2-s2.0-84907386880&origin=inward&txGid=03307e26fba02a27bdc68bda462016f6266316467_Extending_Instruments_with_Live_Algorithms_in_a_Percussion_Code_Duo
|
||||
[@spiegel]: https://www.academia.edu/664807/Manipulations_of_musical_patterns
|
||||
[@bel]: https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.517.7129
|
||||
[@algorithmicpattern]: https://zenodo.org/record/4299661
|
||||
[@fabricating]: https://zenodo.org/record/2155745
|
||||
[@cyclic-patterns]: https://zenodo.org/record/1548969
|
||||
|
||||
- gibber
|
||||
- krill
|
||||
- glicol
|
||||
@@ -0,0 +1 @@
|
||||
<!doctype html><html lang="en"><head><meta charset="utf-8"/><link rel="icon" href="/favicon.ico"/><meta name="viewport" content="width=device-width,initial-scale=1"/><meta name="theme-color" content="#000000"/><meta name="description" content="Strudel REPL"/><title>Strudel REPL</title><script defer="defer" src="/static/js/main.77e38ada.js"></script><link href="/static/css/main.0d689283.css" rel="stylesheet"></head><body><noscript>You need to enable JavaScript to run this app.</noscript><div id="root"></div></body></html>
|
||||
@@ -0,0 +1,2 @@
|
||||
"use strict";(self.webpackChunk_strudel_repl=self.webpackChunk_strudel_repl||[]).push([[787],{787:function(e,t,n){n.r(t),n.d(t,{getCLS:function(){return y},getFCP:function(){return g},getFID:function(){return C},getLCP:function(){return P},getTTFB:function(){return D}});var i,r,a,o,u=function(e,t){return{name:e,value:void 0===t?-1:t,delta:0,entries:[],id:"v2-".concat(Date.now(),"-").concat(Math.floor(8999999999999*Math.random())+1e12)}},c=function(e,t){try{if(PerformanceObserver.supportedEntryTypes.includes(e)){if("first-input"===e&&!("PerformanceEventTiming"in self))return;var n=new PerformanceObserver((function(e){return e.getEntries().map(t)}));return n.observe({type:e,buffered:!0}),n}}catch(e){}},f=function(e,t){var n=function n(i){"pagehide"!==i.type&&"hidden"!==document.visibilityState||(e(i),t&&(removeEventListener("visibilitychange",n,!0),removeEventListener("pagehide",n,!0)))};addEventListener("visibilitychange",n,!0),addEventListener("pagehide",n,!0)},s=function(e){addEventListener("pageshow",(function(t){t.persisted&&e(t)}),!0)},m=function(e,t,n){var i;return function(r){t.value>=0&&(r||n)&&(t.delta=t.value-(i||0),(t.delta||void 0===i)&&(i=t.value,e(t)))}},v=-1,p=function(){return"hidden"===document.visibilityState?0:1/0},d=function(){f((function(e){var t=e.timeStamp;v=t}),!0)},l=function(){return v<0&&(v=p(),d(),s((function(){setTimeout((function(){v=p(),d()}),0)}))),{get firstHiddenTime(){return v}}},g=function(e,t){var n,i=l(),r=u("FCP"),a=function(e){"first-contentful-paint"===e.name&&(f&&f.disconnect(),e.startTime<i.firstHiddenTime&&(r.value=e.startTime,r.entries.push(e),n(!0)))},o=window.performance&&performance.getEntriesByName&&performance.getEntriesByName("first-contentful-paint")[0],f=o?null:c("paint",a);(o||f)&&(n=m(e,r,t),o&&a(o),s((function(i){r=u("FCP"),n=m(e,r,t),requestAnimationFrame((function(){requestAnimationFrame((function(){r.value=performance.now()-i.timeStamp,n(!0)}))}))})))},h=!1,T=-1,y=function(e,t){h||(g((function(e){T=e.value})),h=!0);var n,i=function(t){T>-1&&e(t)},r=u("CLS",0),a=0,o=[],v=function(e){if(!e.hadRecentInput){var t=o[0],i=o[o.length-1];a&&e.startTime-i.startTime<1e3&&e.startTime-t.startTime<5e3?(a+=e.value,o.push(e)):(a=e.value,o=[e]),a>r.value&&(r.value=a,r.entries=o,n())}},p=c("layout-shift",v);p&&(n=m(i,r,t),f((function(){p.takeRecords().map(v),n(!0)})),s((function(){a=0,T=-1,r=u("CLS",0),n=m(i,r,t)})))},E={passive:!0,capture:!0},w=new Date,L=function(e,t){i||(i=t,r=e,a=new Date,F(removeEventListener),S())},S=function(){if(r>=0&&r<a-w){var e={entryType:"first-input",name:i.type,target:i.target,cancelable:i.cancelable,startTime:i.timeStamp,processingStart:i.timeStamp+r};o.forEach((function(t){t(e)})),o=[]}},b=function(e){if(e.cancelable){var t=(e.timeStamp>1e12?new Date:performance.now())-e.timeStamp;"pointerdown"==e.type?function(e,t){var n=function(){L(e,t),r()},i=function(){r()},r=function(){removeEventListener("pointerup",n,E),removeEventListener("pointercancel",i,E)};addEventListener("pointerup",n,E),addEventListener("pointercancel",i,E)}(t,e):L(t,e)}},F=function(e){["mousedown","keydown","touchstart","pointerdown"].forEach((function(t){return e(t,b,E)}))},C=function(e,t){var n,a=l(),v=u("FID"),p=function(e){e.startTime<a.firstHiddenTime&&(v.value=e.processingStart-e.startTime,v.entries.push(e),n(!0))},d=c("first-input",p);n=m(e,v,t),d&&f((function(){d.takeRecords().map(p),d.disconnect()}),!0),d&&s((function(){var a;v=u("FID"),n=m(e,v,t),o=[],r=-1,i=null,F(addEventListener),a=p,o.push(a),S()}))},k={},P=function(e,t){var n,i=l(),r=u("LCP"),a=function(e){var t=e.startTime;t<i.firstHiddenTime&&(r.value=t,r.entries.push(e),n())},o=c("largest-contentful-paint",a);if(o){n=m(e,r,t);var v=function(){k[r.id]||(o.takeRecords().map(a),o.disconnect(),k[r.id]=!0,n(!0))};["keydown","click"].forEach((function(e){addEventListener(e,v,{once:!0,capture:!0})})),f(v,!0),s((function(i){r=u("LCP"),n=m(e,r,t),requestAnimationFrame((function(){requestAnimationFrame((function(){r.value=performance.now()-i.timeStamp,k[r.id]=!0,n(!0)}))}))}))}},D=function(e){var t,n=u("TTFB");t=function(){try{var t=performance.getEntriesByType("navigation")[0]||function(){var e=performance.timing,t={entryType:"navigation",startTime:0};for(var n in e)"navigationStart"!==n&&"toJSON"!==n&&(t[n]=Math.max(e[n]-e.navigationStart,0));return t}();if(n.value=n.delta=t.responseStart,n.value<0||n.value>performance.now())return;n.entries=[t],e(n)}catch(e){}},"complete"===document.readyState?setTimeout(t,0):addEventListener("load",(function(){return setTimeout(t,0)}))}}}]);
|
||||
//# sourceMappingURL=787.8f7ec9e0.chunk.js.map
|
||||
@@ -0,0 +1,56 @@
|
||||
/*
|
||||
object-assign
|
||||
(c) Sindre Sorhus
|
||||
@license MIT
|
||||
*/
|
||||
|
||||
/**
|
||||
* @license Fraction.js v4.2.0 05/03/2022
|
||||
* https://www.xarg.org/2014/03/rational-numbers-in-javascript/
|
||||
*
|
||||
* Copyright (c) 2021, Robert Eisele (robert@xarg.org)
|
||||
* Dual licensed under the MIT or GPL Version 2 licenses.
|
||||
**/
|
||||
|
||||
/**
|
||||
* Tone.js
|
||||
* @author Yotam Mann
|
||||
* @license http://opensource.org/licenses/MIT MIT License
|
||||
* @copyright 2014-2019 Yotam Mann
|
||||
*/
|
||||
|
||||
/** @license React v0.20.2
|
||||
* scheduler.production.min.js
|
||||
*
|
||||
* Copyright (c) Facebook, Inc. and its affiliates.
|
||||
*
|
||||
* This source code is licensed under the MIT license found in the
|
||||
* LICENSE file in the root directory of this source tree.
|
||||
*/
|
||||
|
||||
/** @license React v17.0.2
|
||||
* react-dom.production.min.js
|
||||
*
|
||||
* Copyright (c) Facebook, Inc. and its affiliates.
|
||||
*
|
||||
* This source code is licensed under the MIT license found in the
|
||||
* LICENSE file in the root directory of this source tree.
|
||||
*/
|
||||
|
||||
/** @license React v17.0.2
|
||||
* react-jsx-runtime.production.min.js
|
||||
*
|
||||
* Copyright (c) Facebook, Inc. and its affiliates.
|
||||
*
|
||||
* This source code is licensed under the MIT license found in the
|
||||
* LICENSE file in the root directory of this source tree.
|
||||
*/
|
||||
|
||||
/** @license React v17.0.2
|
||||
* react.production.min.js
|
||||
*
|
||||
* Copyright (c) Facebook, Inc. and its affiliates.
|
||||
*
|
||||
* This source code is licensed under the MIT license found in the
|
||||
* LICENSE file in the root directory of this source tree.
|
||||
*/
|
||||
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
@@ -1,197 +0,0 @@
|
||||
This document introduces you to Strudel in a technical sense.
|
||||
|
||||
It is rather out of date, but there might still be useful info below.
|
||||
|
||||
If you just want to *use* Strudel, have a look at the [Tutorial](https://strudel.tidalcycles.org/tutorial/).
|
||||
|
||||
## Strudel Packages
|
||||
|
||||
There are different packages for different purposes. They..
|
||||
|
||||
- split up the code into smaller chunks
|
||||
- can be selectively used to implement some sort of time based system
|
||||
|
||||
Please refer to the individual README files in the [packages folder](https://codeberg.org/uzu/strudel/src/branch/main/packages)
|
||||
|
||||
## REPL
|
||||
|
||||
The [REPL](https://strudel.tidalcycles.org/) is the place where all packages come together to form a live coding system. It can also be seen as a reference implementation for users of the library.
|
||||
|
||||
More info in the [REPL README](https://codeberg.org/uzu/strudel/src/branch/main/packages/repl/README.md)
|
||||
|
||||
# High Level Overview
|
||||
|
||||
<img src="strudelflow.png" width="600" />
|
||||
|
||||
## 1. End User Code
|
||||
|
||||
The End User Code is written in JavaScript with added syntax sugar. The [eval package](https://github.com/tidalcycles/strudel/tree/main/packages/eval#strudelcycleseval) evaluates the user code
|
||||
after a transpilation step, which resolves the syntax sugar. If you don't want the syntax sugar, you can omit the eval package and call the native javascript `eval` instead.
|
||||
|
||||
### 🍭 Syntax Sugar
|
||||
|
||||
JavaScript Transpilation = converting valid JavaScript to valid JavaScript:
|
||||
|
||||
```js
|
||||
"c3 [e3 g3]".fast(2)
|
||||
```
|
||||
|
||||
becomes
|
||||
|
||||
```js
|
||||
mini('c3 [e3 g3]')
|
||||
.withMiniLocation([1, 0, 0], [1, 11, 11]) // source location
|
||||
.fast(2);
|
||||
```
|
||||
|
||||
- double quoted strings and backtick strings are turned into `mini` calls (single quoted strings are left as is)
|
||||
- The source location is added by chaining `withMiniLocation`, which enables the real time highlighting later
|
||||
- (psuedo) variable names that look like notes (like `c4`, `bb2` or `fs3`) are turned into strings
|
||||
- support for top level await
|
||||
- operator overloading could be implemented in the future
|
||||
|
||||
This is how it works:
|
||||
|
||||
<img src="https://github.com/tidalcycles/strudel/blob/talk/talk/public/shiftflow.png?raw=true" width="800" />
|
||||
|
||||
- The user code is parsed with a [shift parser](https://github.com/shapesecurity/shift-parser-js), generating an AST
|
||||
- The AST is transformed to resolve the syntax sugar
|
||||
- The AST is used to generate code again (shift-codegen)
|
||||
|
||||
Shift will most likely be replaced with acorn in the future, see https://github.com/tidalcycles/strudel/issues/174
|
||||
|
||||
### Mini Notation
|
||||
|
||||
Another important part of the user code is the mini notation, which allows to express rhythms in a short manner.
|
||||
|
||||
- the mini notation is [implemented as a PEG grammar](https://github.com/tidalcycles/strudel/blob/main/packages/mini/krill.pegjs), living in the [mini package](https://github.com/tidalcycles/strudel/tree/main/packages/mini)
|
||||
- it is based on [krill](https://github.com/Mdashdotdashn/krill) by Mdashdotdashn
|
||||
- the peg grammar is used to generate a parser with [peggyjs](https://peggyjs.org/)
|
||||
- the generated parser takes a mini notation string and outputs an AST
|
||||
- the AST can then be used to construct a pattern using the regular Strudel API
|
||||
|
||||
Here's an example AST:
|
||||
|
||||
```json
|
||||
{
|
||||
"type_": "pattern",
|
||||
"arguments_": { "alignment": "h" },
|
||||
"source_": [
|
||||
{
|
||||
"type_": "element", "source_": "c3",
|
||||
"location_": { "start": { "offset": 1, "line": 1, "column": 2 }, "end": { "offset": 4, "line": 1, "column": 5 } }
|
||||
},
|
||||
{
|
||||
"type_": "element",
|
||||
"location_": { "start": { "offset": 4, "line": 1, "column": 5 }, "end": { "offset": 11, "line": 1, "column": 12 } }
|
||||
"source_": {
|
||||
"type_": "pattern", "arguments_": { "alignment": "h" },
|
||||
"source_": [
|
||||
{
|
||||
"type_": "element", "source_": "e3",
|
||||
"location_": { "start": { "offset": 5, "line": 1, "column": 6 }, "end": { "offset": 8, "line": 1, "column": 9 } }
|
||||
},
|
||||
{
|
||||
"type_": "element", "source_": "g3",
|
||||
"location_": { "start": { "offset": 8, "line": 1, "column": 9 }, "end": { "offset": 10, "line": 1, "column": 11 } }
|
||||
}
|
||||
]
|
||||
},
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
which translates to `seq(c3, seq(e3, g3))`
|
||||
|
||||
## 2. Querying & Scheduling
|
||||
|
||||
When the user code has been evaluated, we hopefully get a Pattern instance, which we can use to query events from.
|
||||
These events can then be used to trigger side effects in the real world. On that note, Events are mostly called Hap(s) in the codebase, because JS already has a built in `Event` class.
|
||||
|
||||
### Querying
|
||||
|
||||
> Querying = Asking a Pattern for Events within a certain time span
|
||||
|
||||
```js
|
||||
seq('c3', ['e3', 'g3']) // <--- Pattern
|
||||
.queryArc(0, 2) // query events within 0 and 2 cycles
|
||||
.map((hap) => hap.showWhole()); // make readable
|
||||
```
|
||||
|
||||
yields
|
||||
|
||||
```js
|
||||
[
|
||||
'0/1 -> 1/2: c3', // cycle 0
|
||||
'1/2 -> 3/4: e3',
|
||||
'3/4 -> 1/1: g3',
|
||||
'1/1 -> 3/2: c3', // cycle 1
|
||||
'3/2 -> 7/4: e3',
|
||||
'7/4 -> 2/1: g3',
|
||||
];
|
||||
```
|
||||
|
||||
### 🗓️ Scheduling
|
||||
|
||||
The scheduler will query events repeatedly, creating a possibly endless loop of time slices.
|
||||
Here is a simplified example of how it works
|
||||
|
||||
```js
|
||||
let step = 0.5; // query interval in seconds
|
||||
let tick = 0; // how many intervals have passed
|
||||
let pattern = seq('c3', ['e3', 'g3']); // pattern from user
|
||||
setInterval(() => {
|
||||
const events = pattern.queryArc(tick * step, ++tick * step);
|
||||
events.forEach((event) => {
|
||||
console.log(event.showWhole());
|
||||
const o = getAudioContext().createOscillator();
|
||||
o.frequency.value = getFreq(event.value);
|
||||
o.start(event.whole.begin);
|
||||
o.stop(event.whole.begin + event.duration);
|
||||
o.connect(getAudioContext().destination);
|
||||
});
|
||||
}, step * 1000); // query each "step" seconds
|
||||
```
|
||||
|
||||
## 3. Sound Output
|
||||
|
||||
The third and last step is to use the scheduled events to make sound.
|
||||
Patterns are wrapped with param functions to compose different properties of the sound.
|
||||
|
||||
```js
|
||||
note("[c2(3,8) [<eb2 g1> bb1]]") // sets frequency
|
||||
.s("<sawtooth square>") // sound source
|
||||
.gain(.5) // turn down volume
|
||||
.cutoff(sine.range(200,1000).slow(4)) // modulated cutoff
|
||||
.slow(2)
|
||||
.out().logValues()`,
|
||||
]}
|
||||
/>
|
||||
```
|
||||
|
||||
Here is an example Hap value with different properties:
|
||||
|
||||
```js
|
||||
{ note: 'a4', s: 'sawtooth', gain: 0.5, cutoff: 267 }
|
||||
```
|
||||
<img src="waa-nodes.png" width="600" />
|
||||
|
||||
<div className="text-left">
|
||||
|
||||
- Patterns represent just values in time!
|
||||
- Suitable for any time based output (music, visuals, movement, .. ?)
|
||||
|
||||
### Supported Outputs
|
||||
|
||||
At the time of writing this doc, the following outputs are supported:
|
||||
|
||||
- Web Audio API `.out()` see [/webaudio](https://github.com/tidalcycles/strudel/tree/main/packages/webaudio)
|
||||
- MIDI `.midi()` see [/midi](https://github.com/tidalcycles/strudel/tree/main/packages/midi)
|
||||
- OSC `.osc()` see [/osc](https://github.com/tidalcycles/strudel/tree/main/packages/osc)
|
||||
- Serial `.serial()` see [/serial](https://github.com/tidalcycles/strudel/tree/main/packages/serial)
|
||||
- Tone.js `.tone()` (deprecated?) [/tone](https://github.com/tidalcycles/strudel/tree/main/packages/tone)
|
||||
- WebDirt `.webdirt()` (deprecated?) [/webdirt](https://github.com/tidalcycles/strudel/tree/main/packages/webdirt)
|
||||
- Speech `.speak()` (experimental) part of [/core](https://github.com/tidalcycles/strudel/tree/main/packages/core)
|
||||
|
||||
These could change, so make sure to check the [packages folder](https://github.com/tidalcycles/strudel/tree/main/packages).
|
||||
|
Before Width: | Height: | Size: 88 KiB |
|
Before Width: | Height: | Size: 83 KiB |
|
Before Width: | Height: | Size: 49 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
@@ -0,0 +1 @@
|
||||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><link rel="icon" href="/tutorial/favicon.e3ab9dd9.ico"><link rel="stylesheet" type="text/css" href="/tutorial/index.999678aa.css"><meta name="viewport" content="width=device-width, initial-scale=1"><meta name="description" content="Strudel REPL"><title>Strudel Tutorial</title></head><body> <div id="root"></div> <noscript>You need to enable JavaScript to run this app.</noscript> <script src="/tutorial/index.097d520a.js" defer></script> </body></html>
|
||||
@@ -1,97 +0,0 @@
|
||||
import _import from 'eslint-plugin-import';
|
||||
import { fixupPluginRules } from '@eslint/compat';
|
||||
import globals from 'globals';
|
||||
import path from 'node:path';
|
||||
import { fileURLToPath } from 'node:url';
|
||||
import js from '@eslint/js';
|
||||
import { FlatCompat } from '@eslint/eslintrc';
|
||||
|
||||
const __filename = fileURLToPath(import.meta.url);
|
||||
const __dirname = path.dirname(__filename);
|
||||
const compat = new FlatCompat({
|
||||
baseDirectory: __dirname,
|
||||
recommendedConfig: js.configs.recommended,
|
||||
allConfig: js.configs.all,
|
||||
});
|
||||
|
||||
export default [
|
||||
{
|
||||
ignores: [
|
||||
'**/krill-parser.js',
|
||||
'**/krill.pegjs',
|
||||
'**/.eslintrc.json',
|
||||
'**/server.js',
|
||||
'**/tidal-sniffer.js',
|
||||
'**/*.jsx',
|
||||
'**/tunejs.js',
|
||||
'out/**/*',
|
||||
'**/postcss.config.js',
|
||||
'**/postcss.config.cjs',
|
||||
'**/tailwind.config.js',
|
||||
'**/tailwind.config.cjs',
|
||||
'**/vite.config.js',
|
||||
'**/dist/**/*',
|
||||
'!**/*.mjs',
|
||||
'**/*.tsx',
|
||||
'**/*.ts',
|
||||
'**/*.json',
|
||||
'**/dev-dist',
|
||||
'**/dist',
|
||||
'src-tauri/target/**/*',
|
||||
'**/reverbGen.mjs',
|
||||
'**/hydra.mjs',
|
||||
'**/jsdoc-synonyms.js',
|
||||
'packages/hs2js/src/hs2js.mjs',
|
||||
'packages/supradough/dough-export.mjs',
|
||||
'**/samples',
|
||||
],
|
||||
},
|
||||
...compat.extends('eslint:recommended').map((config) => ({
|
||||
...config,
|
||||
files: ['**/*.mjs', '**/*.js'],
|
||||
})),
|
||||
{
|
||||
files: ['**/*.mjs', '**/*.js'],
|
||||
|
||||
plugins: {
|
||||
import: fixupPluginRules(_import),
|
||||
},
|
||||
|
||||
languageOptions: {
|
||||
globals: {
|
||||
...globals.node,
|
||||
...globals.browser,
|
||||
},
|
||||
|
||||
ecmaVersion: 'latest',
|
||||
sourceType: 'module',
|
||||
},
|
||||
|
||||
rules: {
|
||||
'no-unused-vars': [
|
||||
'warn',
|
||||
{
|
||||
destructuredArrayIgnorePattern: '.',
|
||||
ignoreRestSiblings: false,
|
||||
},
|
||||
],
|
||||
|
||||
'import/no-extraneous-dependencies': [
|
||||
'error',
|
||||
{
|
||||
devDependencies: true,
|
||||
},
|
||||
],
|
||||
},
|
||||
},
|
||||
{
|
||||
// Properties provided by AudioWorkletGlobalScope
|
||||
files: ['packages/superdough/worklets.mjs'],
|
||||
languageOptions: {
|
||||
globals: {
|
||||
currentTime: 'readonly',
|
||||
sampleRate: 'readonly',
|
||||
},
|
||||
},
|
||||
},
|
||||
];
|
||||
@@ -1,3 +0,0 @@
|
||||
# examples
|
||||
|
||||
This folder contains usage examples for different scenarios.
|
||||
@@ -1,5 +0,0 @@
|
||||
# buildless examples
|
||||
|
||||
These examples show you how strudel can be used in a regular html file, without the need for a build tool.
|
||||
|
||||
Most examples are using [skypack](https://www.skypack.dev/)
|
||||
@@ -1,31 +0,0 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<!-- <script src="../../packages/web/dist/index.js"></script> -->
|
||||
<script src="https://unpkg.com/@strudel/web@1.0.3"></script>
|
||||
</head>
|
||||
<body style="background: #222">
|
||||
<button id="play">play</button>
|
||||
<button id="stop">stop</button>
|
||||
<script>
|
||||
strudel.initStrudel();
|
||||
document.getElementById('play').addEventListener('click', () =>
|
||||
evaluate(`
|
||||
//@title washover @by Switch Angel
|
||||
//@social https://www.instagram.com/_switch_angel/
|
||||
|
||||
n("{0 1 3 5 2 }%16")
|
||||
.add(n(tri.range(0, 6).slow(3)))
|
||||
.scale("C4:pentatonic")
|
||||
.sound("sawtooth").att(saw.range(0, 0.05).fast(6))
|
||||
.release(3).pan(rand).decay(rand.range(0.1, 0.3))
|
||||
.lpf(tri.range(200, 8000).slow(5)).lpq(0)
|
||||
.gain(.4).vib(1).vibmod(.1)
|
||||
.scope({pos:.5})
|
||||
`),
|
||||
);
|
||||
document.getElementById('stop').addEventListener('click', () => strudel.hush());
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,24 +0,0 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<!-- <script src="../../packages/web/dist/index.js"></script> -->
|
||||
<script src="https://unpkg.com/@strudel/web@1.0.3"></script>
|
||||
</head>
|
||||
<body style="background: #222">
|
||||
<button id="a">A</button>
|
||||
<button id="b">B</button>
|
||||
<button id="c">C</button>
|
||||
<button id="stop">stop</button>
|
||||
<script>
|
||||
initStrudel({
|
||||
prebake: () => samples('github:tidalcycles/dirt-samples'),
|
||||
});
|
||||
const click = (id, action) => document.getElementById(id).addEventListener('click', action);
|
||||
click('a', () => evaluate(`s('bd,jvbass(3,8)').jux(rev)`));
|
||||
click('b', () => s('bd*2,hh(3,4),jvbass(5,8,1)').jux(rev).play());
|
||||
click('c', () => s('bd*2,hh(3,4),jvbass:[0 4](5,8,1)').jux(rev).stack(s('~ sd')).play());
|
||||
click('stop', () => hush());
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,9 +0,0 @@
|
||||
<script src="https://unpkg.com/hs2js@0.0.4"></script>
|
||||
<button id="hello">hello</button>
|
||||
<script>
|
||||
hs2js.setBase('https://unpkg.com/hs2js@0.0.4/dist/');
|
||||
hs2js.loadParser();
|
||||
document.getElementById('hello').addEventListener('click', () => {
|
||||
hs2js.evaluate('alert "hello from haskell!"');
|
||||
});
|
||||
</script>
|
||||
@@ -1,90 +0,0 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>Buildless Vanilla Strudel REPL</title>
|
||||
</head>
|
||||
<body style="margin: 0; background: #222">
|
||||
<div style="display: grid; height: 100vh; grid-template-rows: 32px auto">
|
||||
<button id="start" style="width: 100vw; height: 32px">evaluate</button>
|
||||
<textarea
|
||||
id="text"
|
||||
style="font-size: 2em; border: 0; color: white; background: transparent; outline: none; padding: 20px"
|
||||
spellcheck="false"
|
||||
></textarea>
|
||||
</div>
|
||||
<div id="output"></div>
|
||||
<script type="module">
|
||||
// TODO: refactor to use newer version without controls import
|
||||
import { controls, repl, evalScope } from 'https://cdn.skypack.dev/@strudel/core@0.11.0';
|
||||
import { mini } from 'https://cdn.skypack.dev/@strudel/mini@0.11.0';
|
||||
import { transpiler } from 'https://cdn.skypack.dev/@strudel/transpiler@0.11.0';
|
||||
import {
|
||||
getAudioContext,
|
||||
webaudioOutput,
|
||||
initAudioOnFirstClick,
|
||||
registerSynthSounds,
|
||||
} from 'https://cdn.skypack.dev/@strudel/webaudio@0.11.0';
|
||||
|
||||
const ctx = getAudioContext();
|
||||
const input = document.getElementById('text');
|
||||
input.innerHTML = getTune();
|
||||
|
||||
const loadModules = evalScope(
|
||||
controls,
|
||||
import('https://cdn.skypack.dev/@strudel/core@0.11.0'),
|
||||
import('https://cdn.skypack.dev/@strudel/mini@0.11.0'),
|
||||
import('https://cdn.skypack.dev/@strudel/tonal@0.11.0'),
|
||||
import('https://cdn.skypack.dev/@strudel/webaudio@0.11.0'),
|
||||
);
|
||||
|
||||
const initAudio = Promise.all([initAudioOnFirstClick(), registerSynthSounds()]);
|
||||
|
||||
const { evaluate } = repl({
|
||||
defaultOutput: webaudioOutput,
|
||||
getTime: () => ctx.currentTime,
|
||||
transpiler,
|
||||
});
|
||||
document.getElementById('start').addEventListener('click', async () => {
|
||||
await loadModules;
|
||||
await initAudio;
|
||||
evaluate(input.value);
|
||||
});
|
||||
|
||||
function getTune() {
|
||||
return `samples('github:tidalcycles/dirt-samples')
|
||||
setcps(1);
|
||||
stack(
|
||||
// amen
|
||||
n("0 1 2 3 4 5 6 7")
|
||||
.sometimes(x=>x.ply(2))
|
||||
.rarely(x=>x.speed("2 | -2"))
|
||||
.sometimesBy(.4, x=>x.delay(".5"))
|
||||
.s("amencutup")
|
||||
.slow(2)
|
||||
.room(.5)
|
||||
,
|
||||
// bass
|
||||
sine.add(saw.slow(4)).range(0,7).segment(8)
|
||||
.superimpose(x=>x.add(.1))
|
||||
.scale('G0 minor').note()
|
||||
.s("sawtooth").decay(.1).sustain(0)
|
||||
.gain(.4).cutoff(perlin.range(300,3000).slow(8)).resonance(10)
|
||||
.degradeBy("0 0.1 .5 .1")
|
||||
.rarely(add(note("12")))
|
||||
,
|
||||
// chord
|
||||
note("Bb3,D4".superimpose(x=>x.add(.2)))
|
||||
.s('sawtooth').cutoff(1000).struct("<~@3 [~ x]>")
|
||||
.decay(.05).sustain(.0).delay(.8).delaytime(.125).room(.8)
|
||||
,
|
||||
// alien
|
||||
s("breath").room(1).shape(.6).chop(16).rev().mask("<x ~@7>")
|
||||
,
|
||||
n("0 1").s("east").delay(.5).degradeBy(.8).speed(rand.range(.5,1.5))
|
||||
).reset("<x@7 x(5,8)>")`;
|
||||
}
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,98 +0,0 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>tidal.html</title>
|
||||
</head>
|
||||
<body style="margin: 0; padding: 0">
|
||||
<textarea id="code" style="width: 100%; height: 200px"></textarea>
|
||||
<pre id="result"></pre>
|
||||
<script src="https://unpkg.com/hs2js@0.0.8"></script>
|
||||
<script src="https://unpkg.com/@strudel/web@1.0.3"></script>
|
||||
<script>
|
||||
const { initStrudel } = strudel;
|
||||
const { run, parse, setBase, loadParser } = hs2js;
|
||||
setBase('https://unpkg.com/hs2js@0.0.4/dist/');
|
||||
const ready = loadParser();
|
||||
initStrudel({
|
||||
prebake: () => samples('github:tidalcycles/dirt-samples'),
|
||||
});
|
||||
|
||||
const textarea = document.getElementById('code');
|
||||
if (window.location.hash) {
|
||||
textarea.value = atob(window.location.hash.slice(1));
|
||||
} else {
|
||||
textarea.value = 'd1 $ s "jvbass(3,8)"';
|
||||
}
|
||||
textarea.addEventListener('input', (e) => {
|
||||
window.location.hash = btoa(e.target.value);
|
||||
update();
|
||||
});
|
||||
update();
|
||||
|
||||
function getInfixOperators() {
|
||||
let operators = {
|
||||
'>': 'set',
|
||||
'#': 'set',
|
||||
'+': 'add',
|
||||
'-': 'sub',
|
||||
'*': 'mul',
|
||||
'/': 'div',
|
||||
};
|
||||
let alignments = {
|
||||
in: (s) => '|' + s,
|
||||
out: (s) => s + '|',
|
||||
mix: (s) => '|' + s + '|',
|
||||
};
|
||||
let ops = {};
|
||||
Object.entries(operators).forEach(([o, name]) => {
|
||||
// operator without alignment
|
||||
ops[o] = (l, r) => reify(l)[name](reify(r));
|
||||
Object.entries(alignments).forEach(([a, getSymbol]) => {
|
||||
// get symbol with alignment
|
||||
let symbol = getSymbol(o);
|
||||
ops[symbol] = (l, r) => reify(l)[name][a](reify(r));
|
||||
});
|
||||
});
|
||||
ops['~>'] = (l, r) => reify(l).late(reify(r));
|
||||
ops['<~'] = (l, r) => reify(l).early(reify(r));
|
||||
ops['<$>'] = (l, r) => reify(r).fmap(l).outerJoin(); // is this right?
|
||||
return ops;
|
||||
}
|
||||
const ops = getInfixOperators();
|
||||
|
||||
async function update() {
|
||||
let result, tree;
|
||||
await ready;
|
||||
try {
|
||||
tree = parse(textarea.value);
|
||||
} catch (err) {
|
||||
console.warn('parse error');
|
||||
console.error(err);
|
||||
}
|
||||
console.log('parsed tree');
|
||||
console.log(tree.rootNode.toString());
|
||||
try {
|
||||
let patterns = {};
|
||||
window.p = (name, pattern) => {
|
||||
patterns[name] = pattern;
|
||||
};
|
||||
window.d1 = (pat) => window.p(1, pat);
|
||||
window.d2 = (pat) => window.p(2, pat);
|
||||
window.d3 = (pat) => window.p(3, pat);
|
||||
window.rot = late;
|
||||
result = run(tree.rootNode, window, ops);
|
||||
if (Object.values(patterns).length) {
|
||||
stack(...Object.values(patterns)).play();
|
||||
}
|
||||
} catch (err) {
|
||||
console.warn('eval error');
|
||||
console.error(err);
|
||||
result = 'ERROR: ' + err.message;
|
||||
}
|
||||
document.getElementById('result').innerHTML = 'Result: ' + result;
|
||||
}
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,22 +0,0 @@
|
||||
<script src="https://unpkg.com/@strudel/embed@0.11.0"></script>
|
||||
<!-- <script src="./embed.js"></script> -->
|
||||
<strudel-repl>
|
||||
<!--
|
||||
note(`[[e5 [b4 c5] d5 [c5 b4]]
|
||||
[a4 [a4 c5] e5 [d5 c5]]
|
||||
[b4 [~ c5] d5 e5]
|
||||
[c5 a4 a4 ~]
|
||||
[[~ d5] [~ f5] a5 [g5 f5]]
|
||||
[e5 [~ c5] e5 [d5 c5]]
|
||||
[b4 [b4 c5] d5 e5]
|
||||
[c5 a4 a4 ~]],
|
||||
[[e2 e3]*4]
|
||||
[[a2 a3]*4]
|
||||
[[g#2 g#3]*2 [e2 e3]*2]
|
||||
[a2 a3 a2 a3 a2 a3 b1 c2]
|
||||
[[d2 d3]*4]
|
||||
[[c2 c3]*4]
|
||||
[[b1 b2]*2 [e2 e3]*2]
|
||||
[[a1 a2]*4]`).slow(16)
|
||||
-->
|
||||
</strudel-repl>
|
||||
@@ -1,31 +0,0 @@
|
||||
<script src="https://unpkg.com/@strudel/repl@1.0.2"></script>
|
||||
<strudel-editor>
|
||||
<!--
|
||||
// @date 23-08-15
|
||||
// "golf rolf" @by froos @license CC BY-NC-SA 4.0
|
||||
|
||||
setcps(1)
|
||||
stack(
|
||||
s("bd*2, ~ rim*<1!3 2>, hh*4").bank('RolandTR909')
|
||||
.off(-1/8, set(speed("1.5").gain(.25)))
|
||||
.mask("<0!16 1!64>")
|
||||
,
|
||||
note("g1(3,8)")
|
||||
.s("gm_synth_bass_2:<0 2>")
|
||||
.delay(".8:.25:.25")
|
||||
.clip("<.5!16 2!32>")
|
||||
.off(1/8, add(note("12?0.7")))
|
||||
.lpf(sine.range(500,2000).slow(32)).lpq(8)
|
||||
.add(note("0,.05"))
|
||||
.mask("<0!8 1!32>")
|
||||
,
|
||||
n("<0 1 2 3 4>*8").scale('G4 minor')
|
||||
.s("gm_lead_6_voice")
|
||||
.clip(sine.range(.2,.8).slow(8))
|
||||
.jux(rev)
|
||||
.room(2)
|
||||
.sometimes(add(note("12")))
|
||||
.lpf(perlin.range(200,20000).slow(4))
|
||||
).reset("<x@15 x(5,8)>")
|
||||
-->
|
||||
</strudel-editor>
|
||||
@@ -1,8 +0,0 @@
|
||||
<script src="https://unpkg.com/@strudel/web@1.0.3"></script>
|
||||
<button id="play">PLAY</button>
|
||||
<script>
|
||||
initStrudel({
|
||||
prebake: () => samples('github:tidalcycles/dirt-samples'),
|
||||
});
|
||||
document.getElementById('play').addEventListener('click', () => s('bd sd').play());
|
||||
</script>
|
||||
@@ -1,24 +0,0 @@
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
lerna-debug.log*
|
||||
|
||||
node_modules
|
||||
dist
|
||||
dist-ssr
|
||||
*.local
|
||||
|
||||
# Editor directories and files
|
||||
.vscode/*
|
||||
!.vscode/extensions.json
|
||||
.idea
|
||||
.DS_Store
|
||||
*.suo
|
||||
*.ntvs*
|
||||
*.njsproj
|
||||
*.sln
|
||||
*.sw?
|
||||
@@ -1,8 +0,0 @@
|
||||
# codemirror-repl example
|
||||
|
||||
This folder demonstrates how to set up a full strudel repl with the `@strudel/codemirror` package. Run it using:
|
||||
|
||||
```sh
|
||||
pnpm i
|
||||
pnpm dev
|
||||
```
|
||||
@@ -1,22 +0,0 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>Vite Vanilla Strudel REPL</title>
|
||||
</head>
|
||||
<body>
|
||||
<main>
|
||||
<nav>
|
||||
<button id="play">eval</button>
|
||||
<button id="stop">stop</button>
|
||||
</nav>
|
||||
<div class="container">
|
||||
<div id="editor"></div>
|
||||
<div id="output"></div>
|
||||
</div>
|
||||
<canvas id="roll"></canvas>
|
||||
</main>
|
||||
<script type="module" src="./main.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,40 +0,0 @@
|
||||
import { StrudelMirror } from '@strudel/codemirror';
|
||||
import { funk42 } from './tunes';
|
||||
import { evalScope } from '@strudel/core';
|
||||
import { drawPianoroll } from '@strudel/draw';
|
||||
import './style.css';
|
||||
import { initAudioOnFirstClick } from '@strudel/webaudio';
|
||||
import { transpiler } from '@strudel/transpiler';
|
||||
import { getAudioContext, webaudioOutput, registerSynthSounds } from '@strudel/webaudio';
|
||||
import { registerSoundfonts } from '@strudel/soundfonts';
|
||||
|
||||
// init canvas
|
||||
const canvas = document.getElementById('roll');
|
||||
canvas.width = canvas.width * 2;
|
||||
canvas.height = canvas.height * 2;
|
||||
const drawContext = canvas.getContext('2d');
|
||||
const drawTime = [-2, 2]; // time window of drawn haps
|
||||
|
||||
const editor = new StrudelMirror({
|
||||
defaultOutput: webaudioOutput,
|
||||
getTime: () => getAudioContext().currentTime,
|
||||
transpiler,
|
||||
root: document.getElementById('editor'),
|
||||
initialCode: funk42,
|
||||
drawTime,
|
||||
onDraw: (haps, time) => drawPianoroll({ haps, time, ctx: drawContext, drawTime, fold: 0 }),
|
||||
prebake: async () => {
|
||||
initAudioOnFirstClick(); // needed to make the browser happy (don't await this here..)
|
||||
const loadModules = evalScope(
|
||||
import('@strudel/core'),
|
||||
import('@strudel/draw'),
|
||||
import('@strudel/mini'),
|
||||
import('@strudel/tonal'),
|
||||
import('@strudel/webaudio'),
|
||||
);
|
||||
await Promise.all([loadModules, registerSynthSounds(), registerSoundfonts()]);
|
||||
},
|
||||
});
|
||||
|
||||
document.getElementById('play').addEventListener('click', () => editor.evaluate());
|
||||
document.getElementById('stop').addEventListener('click', () => editor.stop());
|
||||
@@ -1,24 +0,0 @@
|
||||
{
|
||||
"name": "vite-vanilla-repl-cm6",
|
||||
"private": true,
|
||||
"version": "0.0.0",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"dev": "vite",
|
||||
"build": "vite build",
|
||||
"preview": "vite preview"
|
||||
},
|
||||
"devDependencies": {
|
||||
"vite": "^6.0.11"
|
||||
},
|
||||
"dependencies": {
|
||||
"@strudel/codemirror": "workspace:*",
|
||||
"@strudel/core": "workspace:*",
|
||||
"@strudel/draw": "workspace:*",
|
||||
"@strudel/mini": "workspace:*",
|
||||
"@strudel/soundfonts": "workspace:*",
|
||||
"@strudel/tonal": "workspace:*",
|
||||
"@strudel/transpiler": "workspace:*",
|
||||
"@strudel/webaudio": "workspace:*"
|
||||
}
|
||||
}
|
||||
@@ -1,31 +0,0 @@
|
||||
body,
|
||||
html {
|
||||
margin: 0;
|
||||
height: 100%;
|
||||
background: #282c34;
|
||||
}
|
||||
|
||||
main {
|
||||
height: 100%;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
}
|
||||
|
||||
.container {
|
||||
flex-grow: 1;
|
||||
max-height: 100%;
|
||||
position: relative;
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
#editor {
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
.cm-editor {
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
#roll {
|
||||
height: 300px;
|
||||
}
|
||||
@@ -1,112 +0,0 @@
|
||||
export const bumpStreet = `// froos - "22 bump street", licensed with CC BY-NC-SA 4.0
|
||||
samples('github:felixroos/samples')
|
||||
samples('https://strudel.cc/tidal-drum-machines.json', 'github:ritchse/tidal-drum-machines/main/machines/')
|
||||
|
||||
"<[0,<6 7 9>,13,<17 20 22 26>]!2>/2"
|
||||
// make it 22 edo
|
||||
.fmap(v => Math.pow(2,v/22))
|
||||
// mess with the base frequency
|
||||
.mul("<300 [300@3 200]>/8").freq()
|
||||
.layer(
|
||||
// chords
|
||||
x=>x.div(freq(2)).s("flute").euclidLegato("<3 2>",8)
|
||||
.shape(.4).lpf(sine.range(800,4000).slow(8)),
|
||||
// adlibs
|
||||
x=>x.arp("{0 3 2 [1 3]}%1.5")
|
||||
.s('xylo').mul(freq(2))
|
||||
.delay(.5).delayfeedback(.4).juxBy(.5, rev)
|
||||
.hpf(sine.range(200,3000).slow(8)),
|
||||
// bass
|
||||
x=>x.arp("[0 [2 1?]](5,8)").s('sawtooth').div(freq(4))
|
||||
.lpf(sine.range(400,2000).slow(8)).lpq(8).shape(.4)
|
||||
.off(1/8, x=>x.mul(freq(2)).degradeBy(.5)).gain(.3)
|
||||
).clip(1).release(.2)
|
||||
.stack(
|
||||
// drums
|
||||
s("bd sd:<2 1>, [~ hh]*2, [~ rim]").bank('RolandTR909')
|
||||
.off(1/8, x=>x.speed(2).gain(.4)).sometimes(ply(2)).gain(.8)
|
||||
.mask("<0@4 1@12>/4")
|
||||
.reset("<x@15 [x(3,8) x*[4 8]]>")
|
||||
// wait for it...
|
||||
).fast(2/3)
|
||||
//.crush(6) // remove "//" if you dare`;
|
||||
|
||||
export const trafficFlam = `// froos - "traffic flam", licensed with CC BY-NC-SA 4.0
|
||||
|
||||
samples('github:felixroos/samples')
|
||||
samples('https://strudel.cc/tidal-drum-machines.json', 'github:ritchse/tidal-drum-machines/main/machines/')
|
||||
|
||||
addVoicings('hip', {
|
||||
m11: ['2M 3m 4P 7m'],
|
||||
'^7#11': ['3M 4A 5P 7M'],
|
||||
}, ['C4', 'C6'])
|
||||
|
||||
stack(
|
||||
stack(
|
||||
"<Bbm11 A^7#11>/2".voicings('hip').note()
|
||||
.s("gm_epiano1:2")
|
||||
.arp("[<[0 1 2 3] [3 2 1 0]> ~@5]/2")
|
||||
.release(2).late(.25).lpf(2000),
|
||||
"<Bb1 A1>/2".note().s('gm_acoustic_bass'),
|
||||
n("<0 2 3>(3,8)".off(1/8, add(4)))
|
||||
.scale("<Bb4:minor A4:lydian>/2")
|
||||
.s('gm_electric_guitar_jazz')
|
||||
.decay(sine.range(.05, .2).slow(32)).sustain(0)
|
||||
.delay(.5).lpf(sine.range(100,5000).slow(64))
|
||||
.gain(.7).room(.5).pan(sine.range(0,1).slow(11))
|
||||
).add(perlin.range(0,.25).note()),
|
||||
stack(
|
||||
s("bd:1(3,8) rim").bank('RolandTR707').slow(2).room("<0 <.1 .6>>")
|
||||
.when("<0@7 1>",x=>x.echoWith(3, .0625, (x,i) => x.speed(1+i*.24))),
|
||||
s("rim*4").end(.05).bank('RolandTR808').speed(.8).room(.2)
|
||||
)
|
||||
)
|
||||
.late("[0 .05]*2").late(12)
|
||||
|
||||
`;
|
||||
|
||||
export const funk42 = `// froos - how to funk in 42 lines of code
|
||||
// adapted from "how to funk in two minutes" by marc rebillet https://www.youtube.com/watch?v=3vBwRfQbXkg
|
||||
// thanks to peach for the transcription: https://www.youtube.com/watch?v=8eiPXvIgda4
|
||||
|
||||
samples('github:felixroos/samples')
|
||||
samples('https://strudel.cc/tidal-drum-machines.json', 'github:ritchse/tidal-drum-machines/main/machines/')
|
||||
|
||||
setcps(.5)
|
||||
|
||||
let drums = stack(
|
||||
s("bd*2, ~ sd").bank('RolandTR707').room("0 .1"),
|
||||
s("hh*4").begin(.2).release(.02).end(.25).release(.02)
|
||||
.gain(.3).bank('RolandTR707').late(.02).room(.5),
|
||||
//s("shaker_small").struct("[x x*2]*2").speed(".8,.9").release(.02)
|
||||
).fast(2)
|
||||
|
||||
let wurli = note(\`<
|
||||
[[a2,g3,[b3 c4],e4] ~ [g3,c4,e4](3,8)@4 ~@2]!3
|
||||
[[e2,e3,a3,b3,e4]@3 [e2,e3,ab3,b3,e4]@5]>\`)
|
||||
.s("gm_epiano1:5").decay(.2).sustain("<[1 0@7]!3 1>")
|
||||
.gain("<[.8@2 .4@14]!3 .7>").room(.3)
|
||||
|
||||
let organ = note("<[~@3 [a3,d4,f#4]@2 [[a3,c4,e4]@2 ~] ~@2]!3 ~>".add(12))
|
||||
.s("gm_percussive_organ:2").gain(.6).lpf(1800).pan(.2).room(.3);
|
||||
|
||||
let clav = note(\`<
|
||||
[~@3 a2 [g3,[b3 c4],e4]@2 ~ a2 [g3,b3,e4] ~@2 [g3,c4,e4] ~@4]!3
|
||||
[~@3 e3 [[a3 b3],c3,e3]@2 ~ e2 [e3,a3]@3 [b3,e3] ~@2 [b3,e3]@2]>\`)
|
||||
.s("gm_clavinet:1").decay("<.25!3 [.25 .4]>").sustain(0)
|
||||
.gain(.7).pan(.8).room(.2);
|
||||
|
||||
let bass = note(\`<
|
||||
[a1 [~ [g2 a2]] [g1 g#1] [a1 [g2 a2]]]
|
||||
[a1 [~ [g2 a2]] [e3 d3] [c3 [g3 a3]]]
|
||||
[a1 [~ [g2 a2]] [g1 g#1] [a1 [g2 a2]]]
|
||||
[e2@6 e1@5 e1 [[d2 e3] g1]@4]
|
||||
>\`).s("gm_electric_bass_pick:1").release(.1)
|
||||
|
||||
stack(
|
||||
drums
|
||||
,wurli
|
||||
,organ
|
||||
,clav
|
||||
,bass
|
||||
)`;
|
||||
@@ -1,24 +0,0 @@
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
lerna-debug.log*
|
||||
|
||||
node_modules
|
||||
dist
|
||||
dist-ssr
|
||||
*.local
|
||||
|
||||
# Editor directories and files
|
||||
.vscode/*
|
||||
!.vscode/extensions.json
|
||||
.idea
|
||||
.DS_Store
|
||||
*.suo
|
||||
*.ntvs*
|
||||
*.njsproj
|
||||
*.sln
|
||||
*.sw?
|
||||
@@ -1,13 +0,0 @@
|
||||
# headless-repl demo
|
||||
|
||||
This demo shows how to use strudel in "headless mode".
|
||||
Buttons A / B / C will switch between different patterns.
|
||||
It showcases the usage of the `@strudel/web` package, using [vite](https://vitejs.dev/) as the dev server.
|
||||
|
||||
## Running
|
||||
|
||||
```sh
|
||||
pnpm i && cd examples/headless-repl
|
||||
pnpm dev
|
||||
# open http://localhost:5173/
|
||||
```
|
||||
@@ -1,28 +0,0 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<link rel="icon" type="image/svg+xml" href="https://strudel.cc/favicon.ico" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>@strudel/web REPL Example</title>
|
||||
</head>
|
||||
<body>
|
||||
<div id="app"></div>
|
||||
<button id="a">A</button>
|
||||
<button id="b">B</button>
|
||||
<button id="c">C</button>
|
||||
<button id="stop">stop</button>
|
||||
<script type="module">
|
||||
import { initStrudel } from '@strudel/web';
|
||||
initStrudel({
|
||||
prebake: () => samples('github:tidalcycles/dirt-samples'),
|
||||
});
|
||||
|
||||
const click = (id, action) => document.getElementById(id).addEventListener('click', action);
|
||||
click('a', () => evaluate(`s('bd,jvbass(3,8)').jux(rev)`));
|
||||
click('b', () => s('bd*2,hh(3,4),jvbass(5,8,1)').jux(rev).play());
|
||||
click('c', () => s('bd*2,hh(3,4),jvbass:[0 4](5,8,1)').jux(rev).stack(s('~ sd')).play());
|
||||
click('stop', () => hush());
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,18 +0,0 @@
|
||||
{
|
||||
"name": "repl-example",
|
||||
"private": true,
|
||||
"version": "0.0.0",
|
||||
"type": "module",
|
||||
"license": "AGPL-3.0-or-later",
|
||||
"scripts": {
|
||||
"dev": "vite",
|
||||
"build": "vite build",
|
||||
"preview": "vite preview"
|
||||
},
|
||||
"devDependencies": {
|
||||
"vite": "^6.0.11"
|
||||
},
|
||||
"dependencies": {
|
||||
"@strudel/web": "workspace:*"
|
||||
}
|
||||
}
|
||||
@@ -1 +0,0 @@
|
||||
dist
|
||||
@@ -1,10 +0,0 @@
|
||||
# minimal repl
|
||||
|
||||
This folder demonstrates how to set up a minimal strudel repl using vite and vanilla JS. Run it using:
|
||||
|
||||
```sh
|
||||
npm i
|
||||
npm run dev
|
||||
```
|
||||
|
||||
If you're looking for a more feature rich alternative, have a look at the [../codemirror-repl](codemirror-repl example)
|
||||
@@ -1,35 +0,0 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>Vite Vanilla Strudel REPL</title>
|
||||
</head>
|
||||
<body style="margin: 0; background: #222">
|
||||
<div style="display: grid; height: 100vh">
|
||||
<textarea
|
||||
id="text"
|
||||
style="font-size: 2em; border: 0; color: white; background: transparent; outline: none; padding: 20px"
|
||||
spellcheck="false"
|
||||
></textarea>
|
||||
</div>
|
||||
<button
|
||||
id="start"
|
||||
style="
|
||||
position: absolute;
|
||||
border-radius: 10px;
|
||||
top: 20px;
|
||||
right: 20px;
|
||||
padding: 20px;
|
||||
border: 2px solid white;
|
||||
background: transparent;
|
||||
color: white;
|
||||
cursor: pointer;
|
||||
"
|
||||
>
|
||||
evaluate
|
||||
</button>
|
||||
<div id="output"></div>
|
||||
<script type="module" src="./main.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,23 +0,0 @@
|
||||
import { repl, evalScope } from '@strudel/core';
|
||||
import { getAudioContext, webaudioOutput, initAudioOnFirstClick, registerSynthSounds } from '@strudel/webaudio';
|
||||
import { transpiler } from '@strudel/transpiler';
|
||||
import tune from './tune.mjs';
|
||||
|
||||
const ctx = getAudioContext();
|
||||
const input = document.getElementById('text');
|
||||
input.innerHTML = tune;
|
||||
initAudioOnFirstClick();
|
||||
registerSynthSounds();
|
||||
|
||||
evalScope(import('@strudel/core'), import('@strudel/mini'), import('@strudel/webaudio'), import('@strudel/tonal'));
|
||||
|
||||
const { evaluate } = repl({
|
||||
defaultOutput: webaudioOutput,
|
||||
getTime: () => ctx.currentTime,
|
||||
transpiler,
|
||||
});
|
||||
document.getElementById('start').addEventListener('click', () => {
|
||||
ctx.resume();
|
||||
console.log('eval', input.value);
|
||||
evaluate(input.value);
|
||||
});
|
||||
@@ -1,22 +0,0 @@
|
||||
{
|
||||
"name": "vite-vanilla-repl",
|
||||
"private": true,
|
||||
"version": "0.0.0",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"dev": "vite",
|
||||
"build-githack": "vite build --base /tidalcycles/strudel/use-acorn/packages/core/examples/vite-vanilla-repl/dist/",
|
||||
"build": "vite build",
|
||||
"preview": "vite preview"
|
||||
},
|
||||
"devDependencies": {
|
||||
"vite": "^6.0.11"
|
||||
},
|
||||
"dependencies": {
|
||||
"@strudel/core": "workspace:*",
|
||||
"@strudel/mini": "workspace:*",
|
||||
"@strudel/transpiler": "workspace:*",
|
||||
"@strudel/webaudio": "workspace:*",
|
||||
"@strudel/tonal": "workspace:*"
|
||||
}
|
||||
}
|
||||
@@ -1,31 +0,0 @@
|
||||
export default `samples('github:tidalcycles/dirt-samples')
|
||||
setcps(1)
|
||||
stack(
|
||||
// amen
|
||||
n("0 1 2 3 4 5 6 7")
|
||||
.sometimes(x=>x.ply(2))
|
||||
.rarely(x=>x.speed("2 | -2"))
|
||||
.sometimesBy(.4, x=>x.delay(".5"))
|
||||
.s("amencutup")
|
||||
.slow(2)
|
||||
.room(.5)
|
||||
,
|
||||
// bass
|
||||
sine.add(saw.slow(4)).range(0,7).segment(8)
|
||||
.superimpose(x=>x.add(.1))
|
||||
.scale('G0 minor').note()
|
||||
.s("sawtooth").decay(.1).sustain(0)
|
||||
.gain(.4).cutoff(perlin.range(300,3000).slow(8)).resonance(10)
|
||||
.degradeBy("0 0.1 .5 .1")
|
||||
.rarely(add(note("12")))
|
||||
,
|
||||
// chord
|
||||
note("Bb3,D4".superimpose(x=>x.add(.2)))
|
||||
.s('sawtooth').cutoff(1000).struct("<~@3 [~ x]>")
|
||||
.decay(.05).sustain(.0).delay(.8).delaytime(.125).room(.8)
|
||||
,
|
||||
// alien
|
||||
s("breath").room(1).shape(.6).chop(16).rev().mask("<x ~@7>")
|
||||
,
|
||||
n("0 1").s("east").delay(.5).degradeBy(.8).speed(rand.range(.5,1.5))
|
||||
).reset("<x@7 x(5,8)>")`;
|
||||
@@ -1,24 +0,0 @@
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
lerna-debug.log*
|
||||
|
||||
node_modules
|
||||
dist
|
||||
dist-ssr
|
||||
*.local
|
||||
|
||||
# Editor directories and files
|
||||
.vscode/*
|
||||
!.vscode/extensions.json
|
||||
.idea
|
||||
.DS_Store
|
||||
*.suo
|
||||
*.ntvs*
|
||||
*.njsproj
|
||||
*.sln
|
||||
*.sw?
|
||||
@@ -1,11 +0,0 @@
|
||||
# superdough demo
|
||||
|
||||
This demo shows how to use [superdough](https://www.npmjs.com/package/superdough) with [vite](https://vitejs.dev/).
|
||||
|
||||
## Running
|
||||
|
||||
```sh
|
||||
pnpm i && cd examples/headless-repl
|
||||
pnpm dev
|
||||
# open http://localhost:5173/
|
||||
```
|
||||
@@ -1,38 +0,0 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Superdough Example</title>
|
||||
<meta charset="UTF-8" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<button id="play">PLAAAAAAAY</button>
|
||||
<script type="module">
|
||||
import { superdough, samples, initAudioOnFirstClick, registerSynthSounds } from 'superdough';
|
||||
|
||||
const init = Promise.all([
|
||||
initAudioOnFirstClick(),
|
||||
samples('github:tidalcycles/dirt-samples'),
|
||||
registerSynthSounds(),
|
||||
]);
|
||||
|
||||
const loop = (t = 0) => {
|
||||
// superdough(value, time, duration)
|
||||
superdough({ s: 'bd', delay: 0.5 }, t);
|
||||
superdough({ note: 'g1', s: 'sawtooth', cutoff: 600, resonance: 8 }, t, 0.125);
|
||||
superdough({ note: 'g2', s: 'sawtooth', cutoff: 600, resonance: 8 }, t + 0.25, 0.125);
|
||||
superdough({ s: 'hh' }, t + 0.25);
|
||||
superdough({ s: 'sd', room: 0.5 }, t + 0.5);
|
||||
superdough({ s: 'hh' }, t + 0.75);
|
||||
};
|
||||
|
||||
document.getElementById('play').addEventListener('click', async () => {
|
||||
await init;
|
||||
let t = 0.1;
|
||||
while (t < 16) {
|
||||
loop(t++);
|
||||
}
|
||||
});
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,17 +0,0 @@
|
||||
{
|
||||
"name": "superdough-example",
|
||||
"private": true,
|
||||
"version": "0.0.0",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"dev": "vite",
|
||||
"build": "vite build",
|
||||
"preview": "vite preview"
|
||||
},
|
||||
"dependencies": {
|
||||
"superdough": "workspace:*"
|
||||
},
|
||||
"devDependencies": {
|
||||
"vite": "^6.0.11"
|
||||
}
|
||||
}
|
||||
@@ -1,27 +0,0 @@
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
lerna-debug.log*
|
||||
|
||||
node_modules
|
||||
dist
|
||||
dist-ssr
|
||||
*.local
|
||||
|
||||
# Editor directories and files
|
||||
.vscode/*
|
||||
!.vscode/extensions.json
|
||||
.idea
|
||||
.DS_Store
|
||||
*.suo
|
||||
*.ntvs*
|
||||
*.njsproj
|
||||
*.sln
|
||||
*.sw?
|
||||
|
||||
public/tree-sitter.wasm
|
||||
public/tree-sitter-haskell.wasm
|
||||
@@ -1,10 +0,0 @@
|
||||
# @strudel/tidal
|
||||
|
||||
This is an experiment in implementing tree-sitter for parsing haskell.
|
||||
|
||||
```sh
|
||||
pnpm i
|
||||
cd haskell
|
||||
pnpm copy-wasm
|
||||
pnpm dev
|
||||
```
|
||||
@@ -1,32 +0,0 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>Tree sitter test</title>
|
||||
<style>
|
||||
body {
|
||||
background-color: #121213;
|
||||
color: white;
|
||||
}
|
||||
textarea {
|
||||
padding: 10px;
|
||||
color: white;
|
||||
background-color: transparent;
|
||||
outline: none;
|
||||
}
|
||||
a {
|
||||
color: white;
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body style="margin: 0; padding: 0">
|
||||
<textarea id="code" style="width: 100%; height: 200px"></textarea>
|
||||
<pre id="result"></pre>
|
||||
<script
|
||||
type="module"
|
||||
src="/main.js
|
||||
"
|
||||
></script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -1,83 +0,0 @@
|
||||
import { run, parse, loadParser } from 'hs2js';
|
||||
import { initStrudel, reify, late, samples, stack } from '@strudel/web';
|
||||
|
||||
initStrudel({
|
||||
prebake: () => samples('github:tidalcycles/dirt-samples'),
|
||||
});
|
||||
|
||||
const ready = loadParser();
|
||||
|
||||
const textarea = document.getElementById('code');
|
||||
if (window.location.hash) {
|
||||
textarea.value = atob(window.location.hash.slice(1));
|
||||
} else {
|
||||
textarea.value = 'd1 $ s "jvbass(3,8)"';
|
||||
}
|
||||
textarea.addEventListener('input', (e) => {
|
||||
window.location.hash = btoa(e.target.value);
|
||||
update();
|
||||
});
|
||||
update();
|
||||
|
||||
function getInfixOperators() {
|
||||
let operators = {
|
||||
'>': 'set',
|
||||
'#': 'set',
|
||||
'+': 'add',
|
||||
'-': 'sub',
|
||||
'*': 'mul',
|
||||
'/': 'div',
|
||||
};
|
||||
let alignments = {
|
||||
in: (s) => '|' + s,
|
||||
out: (s) => s + '|',
|
||||
mix: (s) => '|' + s + '|',
|
||||
};
|
||||
let ops = {};
|
||||
Object.entries(operators).forEach(([o, name]) => {
|
||||
// operator without alignment
|
||||
ops[o] = (l, r) => reify(l)[name](reify(r));
|
||||
Object.entries(alignments).forEach(([a, getSymbol]) => {
|
||||
// get symbol with alignment
|
||||
let symbol = getSymbol(o);
|
||||
ops[symbol] = (l, r) => reify(l)[name][a](reify(r));
|
||||
});
|
||||
});
|
||||
ops['~>'] = (l, r) => reify(l).late(reify(r));
|
||||
ops['<~'] = (l, r) => reify(l).early(reify(r));
|
||||
ops['<$>'] = (l, r) => reify(r).fmap(l).outerJoin(); // is this right?
|
||||
return ops;
|
||||
}
|
||||
const ops = getInfixOperators();
|
||||
|
||||
async function update() {
|
||||
let result, tree;
|
||||
await ready;
|
||||
try {
|
||||
tree = parse(textarea.value);
|
||||
} catch (err) {
|
||||
console.warn('parse error');
|
||||
console.error(err);
|
||||
}
|
||||
console.log('parsed tree');
|
||||
console.log(tree.rootNode.toString());
|
||||
try {
|
||||
let patterns = {};
|
||||
window.p = (name, pattern) => {
|
||||
patterns[name] = pattern;
|
||||
};
|
||||
window.d1 = (pat) => window.p(1, pat);
|
||||
window.d2 = (pat) => window.p(2, pat);
|
||||
window.d3 = (pat) => window.p(3, pat);
|
||||
window.rot = late;
|
||||
result = run(tree.rootNode, window, ops);
|
||||
if (Object.values(patterns).length) {
|
||||
stack(...Object.values(patterns)).play();
|
||||
}
|
||||
} catch (err) {
|
||||
console.warn('eval error');
|
||||
console.error(err);
|
||||
result = 'ERROR: ' + err.message;
|
||||
}
|
||||
document.getElementById('result').innerHTML = 'Result: ' + result;
|
||||
}
|
||||
@@ -1,36 +0,0 @@
|
||||
{
|
||||
"name": "tidal-repl",
|
||||
"private": true,
|
||||
"version": "0.0.1",
|
||||
"type": "module",
|
||||
"scripts": {
|
||||
"dev": "vite",
|
||||
"build": "pnpm copy-wasm && vite build",
|
||||
"preview": "vite preview",
|
||||
"copy-wasm": "cp node_modules/hs2js/dist/tree-sitter.wasm public && cp node_modules/hs2js/dist/tree-sitter-haskell.wasm public"
|
||||
},
|
||||
"repository": {
|
||||
"type": "git",
|
||||
"url": "git+https://codeberg.org/uzu/strudel.git"
|
||||
},
|
||||
"keywords": [
|
||||
"titdalcycles",
|
||||
"strudel",
|
||||
"pattern",
|
||||
"livecoding",
|
||||
"algorave"
|
||||
],
|
||||
"author": "Felix Roos <flix91@gmail.com>",
|
||||
"license": "AGPL-3.0-or-later",
|
||||
"bugs": {
|
||||
"url": "https://codeberg.org/uzu/strudel/issues"
|
||||
},
|
||||
"homepage": "https://codeberg.org/uzu/strudel#readme",
|
||||
"dependencies": {
|
||||
"@strudel/web": "workspace:*",
|
||||
"hs2js": "workspace:*"
|
||||
},
|
||||
"devDependencies": {
|
||||
"vite": "^6.0.11"
|
||||
}
|
||||
}
|
||||
@@ -1,3 +0,0 @@
|
||||
# public
|
||||
|
||||
this file is just here to make sure the public folder exists
|
||||
@@ -0,0 +1,128 @@
|
||||
# Tidal Features in Strudel
|
||||
|
||||
## Basics
|
||||
|
||||
- [ ] drawLine
|
||||
- [ ] setcps
|
||||
- [ ] naming patterns? block based evaluation?
|
||||
- [ ] once
|
||||
- [ ] silence
|
||||
- [x] hush
|
||||
- [ ] panic
|
||||
|
||||
## Concatenation
|
||||
|
||||
https://tidalcycles.org/docs/patternlib/tour/concatenation
|
||||
|
||||
- [x] cat: is synonym to fastcat in strudel, while [in tidal, cat is slowcat](https://tidalcycles.org/docs/patternlib/tour/concatenation#cat)
|
||||
- [x] fastcat
|
||||
- [x] timeCat: why is this camel case?
|
||||
- [ ] randcat
|
||||
- [x] append: but is like fastAppend in tidal
|
||||
- [ ] fastAppend
|
||||
- [ ] slowAppend
|
||||
- [ ] wedge
|
||||
- [ ] brak
|
||||
- [ ] flatpat
|
||||
|
||||
## Accumulation
|
||||
|
||||
- [ ] overlay => like stack? "The overlay function is similar to cat" => wrong?
|
||||
- [ ] `<>` operator (=== overlay)
|
||||
- [x] stack
|
||||
- [x] superimpose => strudel supports multiple args => is this layer?
|
||||
- [ ] layer => is this like superimpose but with multiple args?
|
||||
- [ ] steps ?
|
||||
- [ ] iter, iter'
|
||||
|
||||
## Alteration
|
||||
|
||||
- [ ] range, rangex
|
||||
- [ ] quantise
|
||||
- [ ] ply
|
||||
- [ ] stutter
|
||||
- [ ] stripe, slowstripe
|
||||
- [ ] palindrome = every(2, rev)
|
||||
- [ ] trunc
|
||||
- [ ] linger
|
||||
- [ ] chunk, chunk'
|
||||
- [ ] shuffle
|
||||
- [ ] scramble
|
||||
- [ ] rot
|
||||
- [ ] step / step'
|
||||
- [ ] lindenmeyer
|
||||
- [ ] spread / spreadf / fastspread
|
||||
- [ ] spreadChoose / spreadr
|
||||
|
||||
## conditions
|
||||
|
||||
- [x] every
|
||||
- [ ] every'
|
||||
- [ ] whenmod
|
||||
- [ ] sometimes, sometimesBy, someCycles, someCyclesBy
|
||||
- [ ] choose, chooseby, wchoose, wchooseby
|
||||
- [x] struct
|
||||
- [x] mask
|
||||
- [ ] sew
|
||||
- [ ] stitch
|
||||
- [ ] select, selectF
|
||||
- [ ] pickF
|
||||
- [ ] squeeze
|
||||
- [ ] euclid, euclidInv, euclidFull
|
||||
- [ ] ifp
|
||||
|
||||
## Time
|
||||
|
||||
- [x] fast
|
||||
- [x] fastGap
|
||||
- [x] slow
|
||||
- [ ] hurry
|
||||
- [ ] compress: is this compressSpan?
|
||||
- [ ] zoom
|
||||
- [ ] within
|
||||
- [x] off
|
||||
- [ ] rotL / rotR
|
||||
- [x] rev
|
||||
- [ ] jux / juxBy
|
||||
- [ ] swingBy / swing
|
||||
- [ ] ghost
|
||||
- [ ] inside / outside
|
||||
|
||||
## Harmony & Melody
|
||||
|
||||
- [x] scale
|
||||
- [ ] scaleList
|
||||
- [ ] getScale
|
||||
- [ ] toScale
|
||||
- [ ] chordList
|
||||
- [ ] arpeggiate
|
||||
- [ ] arp
|
||||
|
||||
## Transitions
|
||||
|
||||
- [ ] anticipate / anticipateIn
|
||||
- [ ] clutch / clutchIn
|
||||
- [ ] histpan
|
||||
- [ ] interpolate / interpolateIn
|
||||
- [ ] jump / jumpIn / jumpIn' / jumpMod
|
||||
- [ ] wait / waitT
|
||||
- [ ] wash / washIn
|
||||
- [ ] xfade / xfadeIn
|
||||
|
||||
## Sampling
|
||||
|
||||
- [ ] chop
|
||||
- [ ] striate / striateBy
|
||||
- [ ] loopAt
|
||||
- [ ] segment
|
||||
- [ ] discretise
|
||||
|
||||
## Randomness
|
||||
|
||||
- [ ] rand / irand
|
||||
- [ ] perlin / perlinWith / perlin2 / perlin2With
|
||||
|
||||
## Composition
|
||||
|
||||
- [ ] ur
|
||||
- [ ] seqP / seqPLoop
|
||||
@@ -0,0 +1,14 @@
|
||||
<!DOCTYPE html>
|
||||
<script>import("./strudel.js").then(m => strudel = m)
|
||||
</script>
|
||||
<html>
|
||||
<head>
|
||||
<title>Bingo</title>
|
||||
</head>
|
||||
<body>
|
||||
<button onclick="foo()">hello</button>
|
||||
<button onclick="bar()">hello</button>
|
||||
|
||||
<script type="module" src="./strudel.js"></script>
|
||||
</body>
|
||||
</html>
|
||||