wasted-audio/hvcc

The heavy hvcc compiler for Pure Data patches. Updated to python3 and additional generators

Heavy Compiler Collection (hvcc)

hvcc is a python-based dataflow audio programming language compiler that generates C/C++ code and a variety of specific framework wrappers.

Background

Originaly created by Enzien Audio, the need for hvcc arose from running against performance limitations while creating interactive music and sound products for the iPhone. Pure Data (libpd) was the only real choice for a design tool as it was embeddable and provided a high enough abstraction level that musicians or sound designers could be creative.

The goal was to leverage Pure Data as a design interface and statically interpret the resultant patches to generate a low-level, portable and optimised C/C++ program that would be structured to take advantage of modern hardware whilst still generating the same behaviour and audio output as Pure Data.

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
  • What is heavy?
  • Supported patch formats
  • Supported platforms
  • Supported frameworks
  • Licensing
• Getting Started
• Generators
• MIDI
• C API
• C++ API
• Heavy Lang Info
• Heavy IR Info
• Supported vanilla objects
• Unsupported vanilla objects

Integrations

hvcc has been integrated into several projects and services. This allows to easily compile patches without having to install hvcc manually.

• plugdata - Modern interface for Pure Data. Includes a full cross-platform toolchain and targets Daisy, DPF and PD Externals.
• mod-cloud-builder - Online service for building LV2 plugins for the MOD platform.
• OWL Patch Library - Online service for building OWL plugins (uses an old fork).

Requirements

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

hvcc is available from pypi.org and can be installed using python3 pip:

$ pip3 install hvcc

If you want to develop hvcc you can install it from the source directory:

$ git clone https://github.com/Wasted-Audio/hvcc.git

$ cd hvcc/

$ pip3 install -e .

Usage

hvcc requires at least one argument that determines the top-level patch file to be loaded.

Generate a C/C++ program from input.pd and place the files in ~/myProject/

$ hvcc ~/myProject/_main.pd

This command will generate the following directories:

• ~/myProject/hv heavylang representation of the input pd patch(es)
• ~/myProject/ir heavyir representation of the heavylang patch
• ~/myProject/c final generated C/C++ source files (this is what you would use in your project)

-o Select output directory

As seen in the above command, typical output of hvcc is split into several directories that contain the intermediate files used by the compiler itself, the final generated source files, and any additional framework specific files and projects.

The -o or --out_dir parameter will specify where the output files are placed after a successful compile.

For example:

$ hvcc ~/myProject/_main.pd -o ~/Desktop/somewhere/else/

Will place all the generated files in ~/Desktop/somewhere/else/.

-n Specify Patch Name

The -n or --name parameter can be used to easily namespace the generated code so that there are no conflicts when integrating multiple patches into the same project.

$ hvcc ~/myProject/_main.pd -o ~/Desktop/somewhere/else/ -n mySynth

-g Generators

Once hvcc has generated internal information about the patch the -g or --gen parameter can be used to specify the output files it should generate. By default it will always include c for the C/C++ source files and additional generators can specified for certain framework targets.

For example:

$ hvcc ~/myProject/_main.pd -o ~/Desktop/somewhere/else/ -n mySynth -g unity

Will also generate a unity section in the output directory contain all the build projects and source files to compile a Unity plugin.

It is also possible to pass a list of generators:

$ hvcc ~/myProject/_main.pd -o ~/Desktop/somewhere/else/ -n mySynth -g unity wwise js

A list of available generator options can be found here

-p Search Paths

hvcc will iterate through various directories when resolving patch objects and abstractions. The -p or --search_paths argument can be used to add additional folders for hvcc to look in. Note that this argument is not needed for abstractions in the same folder as the top-level patch.

This can be handy when using a third-party patch library like heavylib for example.

Simply append any folder paths after the -p flag like so:

$ hvcc ~/myProject/_main.pd -o ~/Desktop/somewhere/else/ -n mySynth -p ~/Workspace/Projects/Enzien/heavylib/ ~/Desktop/myLib/

-m Meta Data

hvcc can take extra meta-data via a supplied json file. It depends on the generator which fields are supported.

--copyright User Copyright

By default all the generated source files via hvcc will have the following copyright text applied to the top of the file:

Copyright (c) 2018 Enzien Audio, Ltd.

This can be changed with --copyright parameter

$ hvcc ~/myProject/_main.pd -o ~/Desktop/somewhere/else/ -n mySynth --copyright "Copyright (c) Los Pollos Hermanos 2019"

--help

Displays all the available parameters and options for hvcc.

Contact

There are several places where heavy/hvcc conversation is happening:

• Discord
• IRC
• A number of forums:
  • Bela
  • Rebel Technology
  • Daisy
  • MOD

Or you can use the discussions tab of this repository

hvcc's Issues

tabplay~ implementation broken

It's giving recursion errors, which is because the current heavy abstraction contains another tabplay~ ...

This abstraction seems to not be complete, which means it will need some work to properly implement and verify.

Lists for receive and send objects

Hello! I think having different kinds of data possible to send and receive would be very interesting! I'm working on a project with Wwise and Unity and i need to send a list of numbers from unity to PD and I found out that only floats could be sent

Migrate tinywav to a git submodule

So we get the latest version which includes fixes for windows: https://github.com/mhroth/tinywav

Get original tests working

Not all of them will be functional (like test_uploader.py), but at least the basic ones would be nice to have.

Some work has been done in #7 to achieve this.

Feature: Support clear message for delwrite~

This is currently missing, but shouldn't be too hard to support (I think).

Missing __eq~f implementation

Needs to be added to:

• heavy.ir.json
• SignalMath.py
• HvMath.h

Bug: c2daisy should set samplerate for the Heavy context as well

This should include the logic here: https://github.com/electro-smith/json2daisy/blob/main/src/json2daisy/templates/daisy.h#L292-L311

remove all xcodeproj files/infra

Supposedly major MacOS packaging no longer provides xcodeproj generation and it's being phased out.

Personally I have no use for this and can't maintain it. If someone finds this really important then please speak up before it's gone :)

Issues with [pow~]

Possibly a bug with the [pow~] object?

When used to create a exponential-type of envelope, i.e., feed output of [line~] into [pow~] and have it drive a level [*~], a LOT of clicks and xruns are generated. No issues with the patch in PureData. Don't see any weird values sent to line~ (nothing large or neg).

But inserting a [max~] object between [pow~] and [*~] fixes it; the [max~] levels are kept a fraction above zero (like 1e-07).

Actually, a test with just [max~ 0] in between seems OK, too.

expr/expr~

Hi all,
thanks for the great initiative!
One addition which would be a big leap forward, is the inclusion of expr/expr~ objects.
The current code size and performance overhead of messaging for simple calculations is considerable and an expr port could generate higly optimized static code for that purpose.
Especially on daisy, with its 128kB flash size, i am constantly running out of code space.
best, Thomas

bendin with no argument is broken

If no argument (or 0) is given, then one gets as at the left outlet the same as the right outlet minus 1. This is because

[route $1]
|      |
|      [$1(
|      |
|      [spigot]
|      |
[outlet]

should actually be

[route $1]
|      |
|      [$2(
|      |
|      [spigot]
|      |
[outlet]

I think. With this fix it seems to work the way I expect it to. But do I expect it right?

I think also pgmin and touchin have the same issue (didn't test).

[select] doesn't respond to [symbol( messages

The test for this is currently skipped since it fails: https://github.com/Wasted-Audio/hvcc/blob/develop/tests/test_control.py#L270

E   Result (HV_SIMD_NONE)
E   -----------
E   [@ 0.000] C: symbol bill
E   [@ 0.000] C: symbol zack
E   [@ 0.000] C: symbol cort
E   [@ 0.000] A: bang
E   [@ 0.000] B: bang
E   [@ 0.000] C: bang
E   [@ 0.000] D: 234
E   [@ 0.000] B: symbol zack
E   [@ 0.000] B: symbol cort
E   [@ 0.000] B: symbol zack
E   [@ 0.000] B: symbol cort
E   [@ 0.000] A: bang
E   [@ 0.000] B: 234
E   [@ 0.000] A: bang
E   [@ 0.000] B: 234
E   
E   Golden
E   -----------
E   [@ 0.000] C: symbol bill
E   [@ 0.000] B: bang
E   [@ 0.000] A: bang
E   [@ 0.000] A: bang
E   [@ 0.000] B: bang
E   [@ 0.000] C: bang
E   [@ 0.000] D: 234
E   [@ 0.000] A: bang
E   [@ 0.000] B: symbol cort
E   [@ 0.000] B: symbol zack
E   [@ 0.000] A: bang
E   [@ 0.000] A: bang
E   [@ 0.000] B: 234
E   [@ 0.000] B: 6
E   [@ 0.000] A: bang

Emscripten version 3.1.42 and up cause errors in the js output

When compiling patches with emscripten versions > 3.1.41, the outputted js wrapper throws errors such as the following:

Converting base64 string to bytes failed

Upon debugging, it appears there was a reference error around the atob() function, previous versions included a fallback for this function in the compiled output.

remove build.json output

This module is used to create compilation instructions for the deprecated Enzien Audio online build service courtesan:
https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/generators/buildjson/buildjson.py

Unless someone is actively using this (should check with OWL) we can probably safely remove it.

On principle I do like some sort of included build info for various OSes and architectures that can be reused by CI and other toolchains and such. However I feel it needs some new consideration (and better documentation).

Multichannel signal cables

Very much a long shot, but since it's announced for pd 0.54 it would be awesome if hvcc could also support this of course.

Don't expect this to happen before we have a v1.0 out though.

Supported Wwise version?

Hi, I am trying to compile Pd-patches for Wwise, so I can use them in Godot 4.
I am on Windows 10 btw.
The current Godot-Integration for Wwise seems to require using the 2023.1.0 Beta version. This version however does not seem to like the output from hvcc. It seems to have issues with the newest SDK / build tools / platform tool set (?)
Which is the highest Wwise version supported by hvcc at the moment?
Thank you!
Jan

Bug: c2wwise forces plugin version to correspond to Wwise version

bundle_template.json sets targetWwiseVersion to be the same as plugin version, but it should be set based on parsing AkWwiseSDKVersion.h or $WWISEROOT/install-entry.json

    "id": "Heavy.{{name}}.${year}_${major}_${minor}_${build}",
    "name": "{{name}}",
    "tag": "{{name}}",
    "description": "",
    "vendor": "Heavy",
    "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=",
    "type": "plugin",
    "productDependentData": {
        "targetWwiseVersion": {
            "year": ${year},
            "major": ${major}
        }
    },

Building for Unity Android doesn't compile a plugin

Thanks for sharing this great work. I'm trying to compile a plugin with the unity generator for Android arm64 architecture (to be used on Oculus Quest 2).

I get no errors but there are no errors as shown below:

Android NDK: APP_PLATFORM not set. Defaulting to minimum supported version android-16.
Android NDK: WARNING:C:/Users/Max/Desktop/to-test/noise/unity/android/jni/Android.mk:heavy_lib: non-system libraries in linker flags: -latomic
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK:     current module
Android NDK: WARNING:C:/Users/Max/Desktop/to-test/noise/unity/android/jni/Android.mk:heavy_plugin: non-system libraries in linker flags: -latomic
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK:     current module
[arm64-v8a] Compile        : hv_static <= HvControlBinop.c
[arm64-v8a] Compile        : hv_static <= HvControlCast.c
[arm64-v8a] Compile        : hv_static <= HvControlDelay.c
[arm64-v8a] Compile        : hv_static <= HvControlRandom.c
[arm64-v8a] Compile        : hv_static <= HvControlSlice.c
[arm64-v8a] Compile        : hv_static <= HvControlSystem.c
[arm64-v8a] Compile        : hv_static <= HvControlUnop.c
[arm64-v8a] Compile        : hv_static <= HvControlVar.c
[arm64-v8a] Compile        : hv_static <= HvLightPipe.c
[arm64-v8a] Compile        : hv_static <= HvMessage.c
[arm64-v8a] Compile        : hv_static <= HvMessagePool.c
[arm64-v8a] Compile        : hv_static <= HvMessageQueue.c
[arm64-v8a] Compile        : hv_static <= HvSignalBiquad.c
[arm64-v8a] Compile        : hv_static <= HvSignalVar.c
[arm64-v8a] Compile        : hv_static <= HvTable.c[arm64-v8a][arm64-v8a] Compile++      : hv_static <= Heavy_noise.cpp Compile++      :[arm64-v8a][arm64-v8a]
[arm64-v8a]
 hv_static <= HvHeavy.cpp Compile++      : heavy_plugin <= AudioPluginUtil.cpp[arm64-v8a] Compile++      : heavy_plugin <= Hv_noise_AudioPlugin.cpp

 Compile        : hv_static <= HvUtils.c
 Compile++      : hv_static <= HeavyContext.cpp

[arm64-v8a] StaticLibrary  : libhv_static.a
[arm64-v8a] SharedLibrary  : libHv_heavy_AudioLib.so
[arm64-v8a] SharedLibrary  : AudioPlugin_Hv_heavy.so
[arm64-v8a] Install        : libHv_heavy_AudioLib.so => libs/arm64-v8a/libHv_heavy_AudioLib.so
[arm64-v8a] Install        : AudioPlugin_Hv_heavy.so => libs/arm64-v8a/AudioPlugin_Hv_heavy.so

The process with the last line is shown here and no builds appear in the unity/build/ dir.

Android.mk:

LOCAL_PATH := $(call my-dir)

# ------------------------------------------------------------------------------
# static heavy library
include $(CLEAR_VARS)
LOCAL_MODULE := hv_static
# LOCAL_CFLAGS := -std=c11 -DNDEBUG -DHV_SIMD_NEON -O3 -ffast-math -fPIC
LOCAL_CPPFLAGS := -std=c++11
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../../source/heavy
LOCAL_SRC_FILES := $(wildcard $(LOCAL_PATH)/../../source/heavy/*.c)
LOCAL_SRC_FILES += $(wildcard $(LOCAL_PATH)/../../source/heavy/*.cpp)
# LOCAL_ARM_NEON := true
# LOCAL_ARM_MODE := arm
include $(BUILD_STATIC_LIBRARY)

# ------------------------------------------------------------------------------
# audiolib.so
include $(CLEAR_VARS)
LOCAL_MODULE := heavy_lib
LOCAL_MODULE_FILENAME := libHv_heavy_AudioLib
# LOCAL_CFLAGS := -std=c11 -DNDEBUG -DHV_SIMD_NEON -O3 -ffast-math -fPIC
LOCAL_CPPFLAGS := -std=c++11
# there are no additional source files for the library wrapper,
# just build a shared library version of it
LOCAL_WHOLE_STATIC_LIBRARIES := hv_static
LOCAL_LDLIBS := -latomic
# LOCAL_ARM_NEON := true
# LOCAL_ARM_MODE := arm
include $(BUILD_SHARED_LIBRARY)
ifeq ($(TARGET_ARCH),arm)
LOCAL_ARM_NEON := true
LOCAL_ARM_MODE := arm
LOCAL_CFLAGS := -std=c11 -DNDEBUG -DHV_SIMD_NEON -O3 -ffast-math -fPIC
endif
ifeq ($(TARGET_ARCH),x86_64)
LOCAL_CFLAGS := -std=c11 -DNDEBUG -DHV_SIMD_NONE -O3 -ffast-math -fPIC
endif


# ------------------------------------------------------------------------------
# libplugin.so
include $(CLEAR_VARS)
LOCAL_MODULE := heavy_plugin
LOCAL_MODULE_FILENAME := AudioPlugin_Hv_heavy
# LOCAL_CFLAGS := -std=c11 -DNDEBUG -DHV_SIMD_NEON -O3 -ffast-math -fPIC
LOCAL_CPPFLAGS := -std=c++11
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../../source
LOCAL_SRC_FILES := $(wildcard $(LOCAL_PATH)/../../source/unity/*.c)
LOCAL_SRC_FILES += $(wildcard $(LOCAL_PATH)/../../source/unity/*.cpp)
LOCAL_LDLIBS := -latomic
LOCAL_STATIC_LIBRARIES := hv_static
# LOCAL_ARM_NEON := true
# LOCAL_ARM_MODE := arm
include $(BUILD_SHARED_LIBRARY)
ifeq ($(TARGET_ARCH),arm)
LOCAL_ARM_NEON := true
LOCAL_ARM_MODE := arm
LOCAL_CFLAGS := -std=c11 -DNDEBUG -DHV_SIMD_NEON -O3 -ffast-math -fPIC
endif
ifeq ($(TARGET_ARCH),x86_64)
LOCAL_CFLAGS := -std=c11 -DNDEBUG -DHV_SIMD_NONE -O3 -ffast-math -fPIC
endif

Application.mk:

APP_OPTIM := release
APP_STL := c++_static
APP_ABI := arm64-v8a
APP_MODULES := heavy_lib heavy_plugin

Do you have any ideas about what could be going wrong? Thanks in advance

Also when using hvcc command before compiling the plugin, I get this error:

PS C:\Users\Max\Desktop\to-test\noise> hvcc whitenoise.pd -n noise -g unity
  1) ←[91mError←[0m c2unity: Unicode-objects must be encoded before hashing

I'm not sure if that's a problem or how to resolve it? It still proceeds with generating and compiling for Windows x64 platform works.

Thanks!

is this no longer a enzienaudio/hvcc fork?

I used to be able to open PRs to this repo from my fork https://github.com/giuliomoro/hvcc/ of https://github.com/enzienaudio/hvcc/ , however this is no longer the case.

What happened? I have a couple of useful commits https://github.com/giuliomoro/hvcc/tree/fix-X-f

Very cool update!

Hi,

Awesome! Very cool update for hvcc. It's great to revive this project which really shouldn't be neglected as it was.

It would be great to get your PR accepted at enzienaudio/hvcc and have everyone convert to a python3 version since there seem to be quite a number of projects which continue to depend on it: rebel technology's uses it and now befaco (with their lich eurorack module) and also electrosmith's daisy via py2dsy.

What else needs to be done? I just forked your project and if I get some time, I'll check it in more detail over the weekend.

print and send hooks in webasm audioworklet seem broken.

I thought this worked fine, but somehow the callbacks are not properly triggered?

Supporting some of the yet unsupported vanilla objects

Is the support for the yet unsupported vanilla objects possible in theory, or is there some major road-blocker? It would be nice to have support for expr~, fexpr~, fft~ and ifft~, these object alone might open up a lot of possibilities with patching.

If I understand correctly, hvcc is just reading the pure data patches and providing completely custom implementations for the various objects, but would it be possible to at least partially "copy" and reuse the original code for some of those more advanced objects? Would there be licensing issues, or technical issues that have already been evaluated and deemed too complex to overcome?

I am poking the code base to try and understand how one would introduce support for a new object, if anyone has any tips to get started with the architecture and on development and testing practices within the project, it would be much appreciated!

DPF: add bypass type/option

Some references:
https://distrho.github.io/DPF/group__BasePluginStructs.html#ga9a7e733c40008f92e96e2ccf24f890de
https://github.com/DISTRHO/Cardinal/blob/main/src/CardinalPlugin.cpp#L497-L501

deprecate max support?

There are some remnants that suggest that max support was once there, but afaik this is currently not actually working and max users have ~gen anyway.

Better drop any mention/support and just focus on Pd?

See: hvcc/interpreters/max2hv

update c2pdext generator

The current c2pdext only gives some minimal xcode project output.

It would be good to update this at least to a cross platform Makefile, or perhaps look at https://github.com/grrrr/flext as a way to wrap the code for use as an external (with added benefit of supporting max/msp externals as well?)

vcf~ requires signal into second inlet in order to work

If you have a message into it it won't error, won't warn, won't work. This is probably because vcf~ is implemented as an external with a [inlet~].

Desired behaviour: turn it into a signal automatically.

Feature request: ability to change samplerate and blocksize for Daisy

my reason being that i'm tackling the well documented digital noise (https://forum.electro-smith.com/t/questions-about-digital-noise-and-grounding/432/83) that the Daisy Seed can produce when used in a purpose built circuit. On the forum thread linked above there are lots of suggestions for hardware/circuit based solutions to try and reduce the noise but some people have also had success with changing the blocksize and/or moving specific things around in the code such as moving LED function from the main loop to the AudioCallback.

I wondered if there was a way for me to try these solutions given the fact that I'm using pd2dsy.

How do I control the order in which the parameters show up?

If I wanted to arrange my parameters in a specific order, is there an argument I can pass or something? Or are they ordered in the order that the object is created?

add midirealtimein

I find that I'd really like to work with real-time midi messages, like clock signals

Any ideas how to add this?

Update c2wwise to support Wwise 2022, remove support of older versions

Problem - Current Wwise generator was built in 2017 and it cannot easily build plugins for recent versions.

This generator has to be updated. Discussed this a bit on Discord and decided to drop support for old version and rewrite it setting Wwise 2022 as minimal supported version.

Bug: JS ScriptProcessorNode fallback doesn't seem to work any more

After testing by forcing var audioWorkletSupported = false; I can't get a functioning ScriptProcessorNode instance.

It is recognized by the browser, but we don't get any sound or printHook.

Bug: simd of line~ broken

With SSE and AVX implementations of [line~] it seems to output only 0 value.

Needs further investigation.

Non-GUI builds fail with hvcc 0.7.0

Ubuntu 22.04, hvcc 0.7.0

If the .json option "enable_ui": true is set to false, the builds fail. I.E., a non-gui interface can't be built.

With hvcc-examples-dpf, the build stops on this error:

Compiling DistrhoPluginMain.cpp (LV2)
Creating LV2 plugin library for delay_simple
make[2]: *** No rule to make target '../../build/HeavyDPF_delay_simple_UI.cpp.o', needed by '../../bin/delay_simple.lv2/delay_simple_ui.so'.  Stop.
make[2]: Leaving directory '/home/doug/Documents/dev/hvcc_0_7_0/hvcc-examples-dpf/delay_simple/plugin/source'
make[1]: *** [Makefile:21: plugin] Error 2

The "true" option works correctly.

Replace custom simd intrinsics with simde?

Mainly looking at:
https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/generators/ir2c/static/HvMath.h
https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/generators/ir2c/static/HvUtils.h

and wondering if this could be simplified and offloaded in part to:
https://github.com/simd-everywhere/simde

Bug: missing simd instructions

Just to document it a bit better.

The instructions currently used by pd objects obviously have priority.
A patch using these objects would fail using that instruction set.

AVX

• __hv_log2_f - used by rmstodb~, ftom~ and powtodb~
• __hv_samphold_f - used by samphold~

All simd missing

But these are also not used anywhere yet.
However they might be useful for expr~ in the future.

• __hv_acos_f
• __hv_cosh_f
• __hv_acosh_f
• __hv_sin_f
• __hv_asin_f
• __hv_sinh_f
• __hv_asinh_f
• __hv_tan_f
• __hv_atan_f
• __hv_atan2_f
• __hv_tanh_f
• __hv_atanh_f

Reported issues with [table] vs graphical array

Need to investigate some of the differences between [table] objects and the use of graphical arrays in patches.
Writing, and then reading, from [table] seems to just generates noise.

Several users reported this issue (targeting Daisy, but confirmed using DPF wrapper).

Example patch:
motestest.zip

Feature: DPF - support [playhead] receiver (from plugdata)

Which has some nice transport input controls:

Ideally it will use a more private receive symbol instead of the generic string.

Strings must be encoded before hashing

Error 1
When running c2Wwise.py getting the first error I am getting is

plugin_id = int(hashlib.md5(patch_name).hexdigest()[:4], 16) & 0x7FFF # unique id from patch name [0...32767]
TypeError: Strings must be encoded before hashing

This can be easily fixed by adding .encode('utf-8-sig') to line 66 in c2Wwise.py
plugin_id = int(hashlib.md5(patch_name.encode('utf-8-sig')).hexdigest()[:4], 16) & 0x7FFF # unique id from patch name [0...32767]

Error 2
After this getting a similar error

1. ←[91mError←[0m c2wwise: Strings must be encoded before hashing

Isolated this to be coming from line 166 c2Wwise.py_ when passing the files to the writer

                with open(file_path, "w") as g:
                  g.write(env.get_template(f).render(
                      name=patch_name,
                      parameters=in_parameter_list,
                      sends=out_parameter_list,
                      events=event_list,
                      tables=table_list,
                      plugin_type=plugin_type,
                      plugin_id=plugin_id,
                      wwise_version=wwise_sdk_version,
                      msbuild_version="140",
                      files=files)) <--------------      line 166

The issue is only present when writing a .pbxproj file for the xcode project. I managed to bypass it by just removing the creation of this file as I develop on Visual Studio.

I an not sure how to fix this one
Was thinking they should probably be fixed in the same commit as they seems related

Thank you

check python requirements

currently we're pinning some versions, but only a minimum version should be needed.

Submit to pypi as python package

Develop is almost in a good enough state to submit to Pypi (I hope).

Most important thing is to have at least some confirmations that the original targets are still fully functional.
Also some basic tests (see #10) should be working again.

After this a 0.1.0 submission to pypi would be nice, so that we are just a pip3 install hvcc away from having it available on supported operating systems.

Add generator for daisy

To replace https://github.com/electro-smith/pd2dsy

Work ongoing here: #18

env~ runs expensive computations occasionally instead of spreading them across callbacks

hvcc/generators/ir2c/static/HvSignalEnvelope.c

The inputs are stored in the internal buffer as squared, which is good, but the sum is performed all at once when the result is needed. This will cause a spike in CPU usage instead of having even CPU usage across all audio callbacks which would start causing dropouts while the average CPU usage is still low.

The sum should instead be computed incrementally at every callback. This would require adding a running sum variable per eachwindowSize/period element to the base struct.

I can look into implementing this, posting here ahead of that for any feedback.

Bug: stripnote doesn't allow second inlet

We've only implemented the list case where you have to use the object like so:

But of course we also need to be able to just send two messages straight out of [notein]:

Stripnote is currently implemented as so:

is msg_hasFormat() reading past end of fmt?

https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/generators/ir2c/static/HvMessage.c#L97-L110

bool msg_hasFormat(const HvMessage *m, const char *fmt) {
  hv_assert(fmt != NULL);
  const int n = msg_getNumElements(m);
  for (int i = 0; i < n; ++i) {
    switch (fmt[i]) {
      case 'b': if (!msg_isBang(m, i)) return false; break;
      case 'f': if (!msg_isFloat(m, i)) return false; break;
      case 'h': if (!msg_isHash(m, i)) return false; break;
      case 's': if (!msg_isSymbol(m, i)) return false; break;
      default: return false;
    }
  }
  return (fmt[n] == '\0');
}

It looks like this may well be trying to access fmt beyond its end if the message has more elements than the length of fmt. This may be expected/desired (because of speed potential), but it should be documented that if you are unsure a priori about the message length, then it's your task to ensure strlen(fmt) is hv_msg_getNumElements().

As an additional note, it could be useful to add a method to get the message format (or is there one already?), so that one doesn't have to "guess" what the full current format is (sure one can use hv_msg_is{Float,Bang,Symbol,Hash} to obtain that, but it feels a bit cumbersome).

.lower() on generator arguments

Because apparently users are confused about this.

Just turn any generator argument to lower-case.

msg_copy: "Copy a message onto the stack" wrong?

The source and documentation say:

/** Copy a message onto the stack. The message persists. */
HvMessage *hv_msg_copy(const HvMessage *const m);

However, that's not "copied onto the stack". I'd suggest a new description:

Copy a message, allocating memory for it
The returned pointer MUST be deallocated by the caller via hv_msg_free().

The implementation (after one indirection), for reference:

// the message is serialised such that all symbol elements are placed in order at the end of the buffer
HvMessage *msg_copy(const HvMessage *m) {
  const hv_uint32_t heapSize = msg_getSize(m);
  char *r = (char *) hv_malloc(heapSize);
  hv_assert(r != NULL);
  msg_copyToBuffer(m, r, heapSize);
  return (HvMessage *) r;
}

wrapper for openFrameworks?

Just started learning oF and eager to use it with Heavy. oF uses C++ so the hvcc c plugin generator should work, but if anyone here works with oF, it'd be nice to have a wrapper to facilitate implementation . Otherwise, I'll see if I can't make one once I've learned a bit more.

https://openframeworks.cc/

requires perf information

If I build this patch

#N canvas 63 63 450 300 12;
#X obj 197 124 pow~;
#X obj 207 205 dac~;
#X obj 251 122 sqrt~;
#X connect 0 0 1 0;
#X connect 2 0 1 0;

I get

__sqrt~f requires perf information.
__pow~f requires perf information.

As part of a larger patch I have also seen

__cos~f requires perf information.

but I haven't been able to reproduce it by simply adding a [cos~] object.

Any idea what these are for?

Wwise: add port groups

As described in a use-case in the Audiokinetic blog: https://blog.audiokinetic.com/en/sound-in-the-silence-of-space-the-systems-of-hardspace-shipbreaker/ under Heavy Gotchas.

Here they setup a multi-channel/surround config, where by default the c2wwise generator only supports stereo: https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/generators/c2wwise/c2wwise.py#L77-L82

Likely we should go a similar route as the DPF wrapper and its meta.json for port groups. So this means adding the meta config and adjusting the templates to allow for extending the channel i/o setup.

local variable 'patch_meta' referenced before assignment

As reported by a user.

Likely something since python 3.10 where variable assignment is more strict.

Easy fix (will do asap).