Merge branch 'develop' into feature/expr-sig

.bumpversion.cfg

@@ -1,5 +1,5 @@
 [bumpversion]
-current_version = 0.7.0
+current_version = 0.12.0
 
 [bumpversion:file:setup.cfg]
 

.github/FUNDING.yml

@@ -0,0 +1,4 @@
+github: Wasted-Audio
+patreon: WastedAudio
+ko_fi: wastedaudio
+liberapay: WastedAudio

.github/workflows/build.yml

@@ -8,10 +8,10 @@ on:
 jobs:
   build:
 
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-20.04
     strategy:
       matrix:
-        python-version: ['3.7', '3.8', '3.9', '3.10', '3.11']
+        python-version: ['3.8', '3.9', '3.10', '3.11', '3.12']
 
     steps:
       - uses: actions/checkout@v3

.gitmodules

@@ -1,3 +1,6 @@
 [submodule "tests/src/midifile"]
 	path = tests/src/midifile
 	url = https://github.com/craigsapp/midifile.git
+[submodule "tests/src/tinywav"]
+	path = tests/src/tinywav
+	url = https://github.com/mhroth/tinywav.git

CHANGELOG.md

@@ -1,12 +1,71 @@
 CHANGELOG
 =====
 
-Next Release
+0.12.0
+-----
+
+* Core: parse remote/send messages
+* Core: MIDI i/o added to memoryPool
+* Core: support `[else/knob]` as `[float]`
+* Daisy: set heavy context after hw.init()
+* OWL: add Polytouchin and Polytouchout
+* JS: webmidi input
+* Docs: add instructions for loading custom samples in JS
+* Small Bugfixes:
+  * MIDI out objects in output Paremeters
+  * JS: AudioWorklet fillTableWithFloatBuffer
+
+0.11.0
+-----
+
+* Core: add attributes and send type to send params
+* DPF: add "read only" outputParameter type based on send params
+* JS: add output Parameter and output Event to generator and html template
+* Daisy: update `wstd2daisy` and allow for setting `displayprocess` code into the template
+* Testing: move `tinywav` to git submodule
+* JS Bugfix: printHook and sendHook for AudioWorklet; mention emsdk limitations in docs
+* Object Bugfix: `[stripnote]` missing right inlet
+* Small Bugfixes:
+  * set default name argument
+  * `emcc` call on Windows - thanks to @vulcu
+  * deallocation in test_signal - thanks to @eu-ch
+  * quotes around WWISE paths - thanks to @eu-ch
+
+0.10.0
+-----
+
+* Objects: `[bang~]`
+* Object improvements: support `[clear(` message for `[delwrite~]`
+* Documentation fixes/additions
+* Daisy: ability to set samplerate and blocksize
+* Daisy: adding midirealtimein, polytouchin/out, midiin (midiout WIP)
+* Daisy: use `libdaisy_path` in meta config; both string/path and int/depth possible
+* DPF: enum for UI parameter IDs
+* DPF bugfixes: correct input PortGroup names; correct UI slider updates; midiout reimplementation
+* Wwise: complete rewrite/refactor - now uses SDK build tools - thanks to @eu-ch !!
+* Bugfix: correct alignment in AVX pow~ implementation
+* Cleanup: remove deprecated build.json
+* Deprecate py37, enable py312
+
+0.9.0
+-----
+
+* Daisy: set bootloader type in Makefile
+* Daisy: MIDI i/o for NoteOn/Off, ControlChange, ProgramChange, ChannelPressure, and PitchBend
+* Daisy: USB MIDI toggle (disabled by debug printing)
+* Daisy: allow for debug printing (off by default, increases program size due to formatting)
+* DPF bugfixes: broken midi template include; MIDI_RT_CLOCK fails under certain conditions
+* Pdext bugfixes: Windows library linking
+
+0.8.0
 -----
 
 * DPF: enumerated parameters
 * DPF: special `__hv_dpf_bpm` receiver of transport BPM value
-* bugfix: issues #50, #106
+* Pdext: migrate to `pd-lib-builder` and newer `m_pd.h` and add some initial documentation.
+* deprecated: Fabric generator - no longer supported
+* docs: updates on missing objects and limitations
+* bugfix: issues #24, #50, #100, #106
 
 0.7.0
 -----

README.md

@@ -1,6 +1,8 @@
 # Heavy Compiler Collection (hvcc)
 
 [![Build Status](https://github.com/Wasted-Audio/hvcc/actions/workflows/build.yml/badge.svg)](https://github.com/Wasted-Audio/hvcc/actions)
+[![pypi](https://img.shields.io/pypi/v/hvcc.svg)](https://pypi.python.org/pypi/hvcc)
+[![python](https://img.shields.io/pypi/pyversions/hvcc.svg)](https://pypi.python.org/pypi/hvcc)
 
 `hvcc` is a python-based dataflow audio programming language compiler that generates C/C++ code and a variety of specific framework wrappers.
 
@@ -12,14 +14,47 @@ The goal was to leverage Pure Data as a design interface and statically interpre
 
 It has since then been expanded to provide further support for many different platforms and frameworks, targeting game audio design, daw plugins and embedded production tools. In 2021 Wasted Audio took over maintenance of the project.
 
+## Documentation
+
+* [Introduction](/docs/01.introduction.md)
+  * [What is heavy?](/docs/01.introduction.md#what-is-heavy)
+  * [Supported patch formats](/docs/01.introduction.md#supported-patch-formats)
+  * [Supported platforms](/docs/01.introduction.md#supported-platforms)
+  * [Supported frameworks](/docs/01.introduction.md#supported-frameworks)
+  * [Licensing](/docs/01.introduction.md#licensing)
+* [Getting Started](/docs/02.getting_started.md)
+* [Generators](/docs/03.generators.md)
+* [MIDI](/docs/04.midi.md)
+* [C API](/docs/05.c.md)
+* [C++ API](/docs/06.cpp.md)
+* [Heavy Lang Info](/docs/07.heavy_lang.md)
+* [Heavy IR Info](/docs/08.heavy_ir_lang.md)
+* [Supported vanilla objects](/docs/09.supported_vanilla_objects.md)
+* [Unsupported vanilla objects](/docs/10.unsupported_vanilla_objects.md)
+
+## Integrations
+
+hvcc has been integrated into several projects and services. This allows to easily compile patches without having to install hvcc manually.
+
+* [plugdata](https://plugdata.org/) - Modern interface for Pure Data. Includes a full cross-platform toolchain and targets Daisy, DPF and PD Externals.
+* [mod-cloud-builder](https://github.com/moddevices/mod-cloud-builder) - Online service for building LV2 plugins for the MOD platform.
+* [OWL Patch Library](https://www.rebeltech.org/patch-library) - Online service for building OWL plugins (uses an old fork).
+
 ## Requirements
 
-* python 3.7 or higher
-  * `jinja2` (for generator templating)
-  * `importlib_resources` (for reading static resources)
-  * `json2daisy` (for daisy integration)
-  * `tox` (for tests, optional)
-  * `clang/clang++` (for building tests, optional)
+Python 3.8 up to 3.12
+
+* `jinja2` (for generator templating)
+* `importlib_resources` (for reading static resources)
+* `json2daisy` (for daisy integration)
+
+For tests:
+
+* `tox` (python install)
+* `numpy/scipy` (requirements-dev)
+* `midifile` (git submodule)
+* `tinywav` (git submodule)
+* `clang/clang++` (system install)
 
 ## Installation
 
@@ -111,24 +146,6 @@ This can be changed with `--copyright` parameter
 
 Displays all the available parameters and options for hvcc.
 
-## Documentation
-
-* [Introduction](/docs/01.introduction.md)
-  * [What is heavy?](/docs/01.introduction.md#what-is-heavy)
-  * [Supported patch formats](/docs/01.introduction.md#supported-patch-formats)
-  * [Supported platforms](/docs/01.introduction.md#supported-platforms)
-  * [Supported frameworks](/docs/01.introduction.md#supported-frameworks)
-  * [Licensing](/docs/01.introduction.md#licensing)
-* [Getting Started](/docs/02.getting_started.md)
-* [Generators](/docs/03.generators.md)
-* [MIDI](/docs/04.midi.md)
-* [C API](/docs/05.c.md)
-* [C++ API](/docs/06.cpp.md)
-* [Heavy Lang Info](/docs/07.heavy_lang.md)
-* [Heavy IR Info](/docs/08.heavy_ir_lang.md)
-* [Supported vanilla objects](/docs/09.supported_vanilla_objects.md)
-* [Unsupported vanilla objects](/docs/10.unsupported_vanilla_objects.md)
-
 ## Contact
 
 There are several places where heavy/hvcc conversation is happening:

docs/01.introduction.md

@@ -25,7 +25,7 @@ Heavy can interpret and convert a subset of features from Pure Data patches:
 
 ## Supported Platforms
 
-* Windows 8, 10 and WSA
+* Windows 10, 11 and WSA
 * Mac OSX
 * Linux
 * PS4
@@ -40,7 +40,6 @@ Heavy can interpret and convert a subset of features from Pure Data patches:
 
 ## Supported Frameworks
 
-* [Fabric](http://www.tazman-audio.co.uk)
 * [Unity 5](https://unity3d.com)
 * [Distrho Plugin Framework](https://distrho.github.io/DPF)
   * [LV2](https://lv2plug.in)

docs/02.getting_started.md

@@ -8,6 +8,8 @@ To send audio output add a `[dac~]` The number of channels can be configured by
 
 Note that top-level graphs (e.g. `_main.pd`) should not have any `[inlet~]` or `[outlet~]` objects. These are reserved only for abstractions.
 
+> NOTE: Currently if your main patch does not have at least an `adc~` or `dac~` configured signal rate objects will not be evaluated in the graph!
+
 ## Exposing Parameters
 
 ### Input Parameters
@@ -40,7 +42,7 @@ See the specific framework details for more information on output parameter supp
 
 ## Exposing Events
 
-All (control) `[receive]` and `[r]` objects annotated with `@hv_event` will be exposed as events in the Unity target only.
+All (control) `[receive]` and `[r]` objects annotated with `@hv_event` will be exposed as events in the Unity and Javascript targets only.
 
 ![events](img/docs_exposed_events.png)
 
@@ -80,9 +82,28 @@ Heavy will also perform patch analysis to look for common mistakes and inconsite
 
 If you experience any problems or have some thoughts on how to improve heavy make sure to browse and contribute to our [public issue tracker](https://github.com/Wasted-Audio/hvcc/issues).
 
+## Tips and Tricks
+
+Just because pd-vanilla can run your patch, does not mean it will behave exactly the same using Heavy. Extra care needs to be taken when dealing with control messages and certain PD object features.
+
+* Make sure to go over the [known limitations](#known-limitations) to see if you are using objects incorrectly.
+* Try to move as much of your patch into the signal domain as you can. Heavy is optimized for signal processing and every control rate operation can introduce interruptions and additional delay. Use control logic at the very beginning or the very end of the dataflow if possible.
+* Make sure the order in your control flow works as intended. Use `[t]`/trigger objects to force the correct order of operations.
+* When using Daisy the receive objects continuously output control messages, which can potentially interrupt your intended behavior.
+* If you run into problems with a patch try to reduce it in order to localize the problem to a specific object or use-case before reporting an issue.
+
 ## Known Limitations
 
+This list will be continuously epanded to document differences in object behavior between PD and Heavy.
+
+* Many objects do not take control signals on their left inlet. `[osc~]` for instance always requires the use of `[sig~]` before connecting a value.
+* Heavy does not support symbols in `[pack]`. e.g. `[pack s f]`.
 * Heavy does not support numbers in `[unpack]`, e.g. `[unpack 0 0]` gives `Heavy only supports arguments 'f' and 's' to unpack.` Workaround is to use `f` instead, e.g. `[unpack f f]`, and if necessary prime the default values with a `[loadbang]` and `[0 0(`.
+* Sliders and number inputs are converted to `[f ]` and thus do not store send/receive/initialization/etc. settings.
 * Heavy does not accept arguments and control connections to: `[rzero~]`, `[rzero_rev~]`, `[czero~]`, `[czero_rev~]`. In Heavy, these objects accept only signal inputs. Arguments and control connections are ignored.
 * On the `[select]` object it is currently not possible to set the arguments via the right inlet (internally a hardcoded switch_case is used).
-* Certain filters are sensitive to ‘blowing up’ at very low or very high cutoff frequencies and/or resonances, due to the filter coefficients not being perfectly represented with a finite number of bits. While Pure data natively uses 64 bits, platforms like `OWL` and `Daisy`  that use 32 bit float are more sensitive to this. For example, the Pure data `[lp~]`, `[bp~]` and `[hp~]` filters are implemented with biquads which are prone to fail or distort with cutoff frequencies less than around 200 Hz (at 48kHz sample rate).
+* Heavy supports remote/send messages, however empty messages are currently removed. So the typical `[; bla 1(` multiline message needs to contain at least something on the first line: `[_; bla 1(`.
+* `[metro]` and `[timer]` objects do not accept tempo messages or unit arguments.
+* `[snapshot~]` does not respond within the same control flow as it executes in signal context. Its output happens on the next audio cycle, so additional care for this control flow needs to be taken into account if you depend on synchronous execution.
+* Certain filters are sensitive to ‘blowing up’ at very low or very high cutoff frequencies and/or resonances, due to the filter coefficients not being perfectly represented with a finite number of bits. While Pure data natively uses 64 bits, platforms like `OWL` and `Daisy`  that use 32 bit float are more sensitive to this. For example, the Pure data `[bp~]` filter is implemented with a biquad which is prone to fail or distort with cutoff frequencies less than around 200 Hz (at 48kHz sample rate).
+* Heavy does not support multichannel connections.

docs/03.gen.daisy.md

@@ -2,15 +2,15 @@
 
 Daisy is an embedded platform for music. It features everything you need for creating high fidelity audio hardware devices.
 
-This Generator is typically it is used in combination with [pd2dsy](https://github.com/electro-smith/pd2dsy).
-
 Currently daisy platform is supported for:
 
-* `field`
 * `seed`
 * `pod`
 * `petal`
 * `patch`
+* `patch_init`
+* `patch_sm`
+* `field`
 
 Which can be configured using the `-m` metadata.json `daisy.board` setting:
 
@@ -22,4 +22,96 @@ Which can be configured using the `-m` metadata.json `daisy.board` setting:
 }
 ```
 
-However one can also create custom board layouts. See the pd2dsy documentation for more information.
+However one can also create custom board layouts. See [the Electro-Smith documentation](https://github.com/electro-smith/DaisyWiki/wiki/Pd2dsy-Guide) for more information.
+
+The custom layout can be passed on via the meta.json as such:
+
+```json
+{
+    "daisy": {
+        "board_file": <path to board.json>
+    }
+}
+```
+
+You can also set a custom path to your libDaisy directory. This can either be a string to the full or relative path or a number indicating the levels deep this directory is compared to the output directory. The default value for this is `2`.
+
+```json
+{
+    "daisy": {
+        "libdaisy_path": "/somewhere/libdaisy/"
+    }
+}
+```
+
+Or the level:
+
+```json
+{
+    "daisy": {
+        "libdaisy_path": 5
+    }
+}
+```
+
+## MIDI
+
+Board files that have `OOPSY_TARGET_HAS_MIDI_INPUT` configured will automatically set up UART MIDI on the default USART1 Rx and Tx pins of the Daisy (D13/14).
+
+Additionally `usb_midi`, running on the onboard micro-usb, can be enabled separately via the meta.json
+
+```json
+{
+    "daisy": {
+        "usb_midi": true
+    }
+}
+```
+
+At the moment all midi messages will be merged between USB and UART MIDI interfaces. In the future it will likely be possible to assign additional UART pins and group them under a specific PD midi "port".
+
+Currently supported MIDI messages are: Note On/Off, Poly Aftertouch, Control Change, Program Change, Channel Pressure, Pitch Bend, and Midi Realtime messages.
+
+## [print] object
+
+Printing to serial console can be enabled using the `debug_printing` flag in the meta.json:
+
+```json
+{
+    "daisy": {
+        "debug_printing": true
+    }
+}
+```
+
+This will increase the program size with a few kb and will disable `usb_midi` as we currently do not have composite USB device yet.
+
+## Custom samplerate and blocksize
+
+This can be done by adding either to the meta.json:
+
+```json
+{
+    "daisy": {
+        "samplerate": 96000,
+        "blocksize": 128
+    }
+}
+```
+
+Do note that the samplerate will be automatically set to either 16k, 32k, 48k, or 96k. Blocksize will need to be 256 or less and is automatically capped.
+
+## Custom Linker script and Bootloader APP_TYPE
+
+Using the Daisy bootloader you can flash the program to other parts of the Daisy memory. Read the [libDaisy documentation](https://github.com/electro-smith/libDaisy/blob/master/doc/md/_a7_Getting-Started-Daisy-Bootloader.md) for more information.
+
+The linker and `APP_TYPE` can be set in the json metadata accordingly:
+
+```json
+{
+    "daisy": {
+        "linker_script": <path_to_lds_file>,
+        "bootloader": <APP_TYPE>
+    }
+}
+```