https://github.com/enzienaudio/hvcc/blob/master/README.md

There’s the newly open source code. Heavy compiles highly effiecient and optimized C code from patches (you can only use a subset of objects, but they have stand-ins for ones you might miss).

A lot of options are for embedding patches into other development environments. But it can create VST’s from your patch, and possibly externals for Pd (there’s a generator called Pdext). If so, it would be a great way to turn subpatches/abstractions into resource efficient objects. There’s also other options for optimizing code for your hardware (like embedded ARM applications).

This is a great resource, and now that its open source it would be great to see it adopted by the community and actively developed. I personally wouldn’t mind seeing this code find its way into things like Purr data. It might be useful for a “performance mode” or something similar.

@jancsika Right, I don't think so, but I am not completely sure.

@EEight Thanks.

One other question-- does Heavy use the burgeoning AudioWorklet interface for the web assembly binaries it generates?

@jancsika Don't think so (nothing return when doing a grep for that term). I can see that it use WebAudioContext.

I would guess it's using the ScriptProcessorNode interface.

The AudioWorklet interface lets you process your script in the audio processing thread instead of the main thread. That should cause a significant improvement to the performance.

That brings up a separate direction that I've been wondering about-- can I just compile Purr Data itself as a web assembly binary and then have it running in the audio thread?

Ignoring all the obvious things like file system access et al, the main question would be how to fetch the system time which is needed for each dsp tick. It doesn't look like the interface gives access to that data in the worker thread.

I made a web synth with heavy (it is basically the synth example from the pure data doc and a little sequencer).
And I combined it with web MIDI. Sadly the MIDI timing (clock) over the internet is not very precise (perhaps there is something wrong with my code). But at least for controlling parameters web MIDI is nice. The timing inside the website is good.

https://libpd3.handmadeproductions.de/

For me it was much easier to create something with Pure Data / Heavy compared to creating sound with webAudio.
Still it is just a small subset of Pure Data vanilla.

@jancsica It would be really great if it is possible to create something like the heavy java script compiler (but more complete) with purr data. I am not sure if i understand your idea with the web assembly binary right...

a strange thing regarding midi in / out timing, it works much better in this example: https://webmidi.handmadeproductions.de/
what i did not expect, because I thought the video processing needs more ressources than the audio processing ( at least in these examples)...
perhaps because midi is send from and to the heavy file while in the webmidi examples everything happens in java script? It is basically the same web MIDI method...

edit: here is a nice timing example, but i do not understand it yet...
http://webaudiodemos.appspot.com/metronome/index.html

does anybody know how to port this code to jave script? that could improve the midi performane...
https://github.com/enzienaudio/hvcc/blob/master/docs/09.midi.md

Edit: I dont think that I need that code at all, because webmidi already uses numbers for midi data. Still, the __hv_notein etc. objects could be useful. But until now they only output the first value and not the whole list in my example.

VstInt32 HeavyVst2_sine::processEvents(VstEvents* events) {
  for (int i = 0; i < events->numEvents; ++i) {
    VstEvent *vste = events->events[i];
    switch (vste->type) {
      case kVstMidiType: {
        VstMidiEvent *vstme = (VstMidiEvent *) vste;

        const unsigned char command = vstme->midiData[0] & 0xF0;
        const unsigned char channel = vstme->midiData[0] & 0x0F;
        const unsigned char data0   = vstme->midiData[1] & 0x7F;
        const unsigned char data1   = vstme->midiData[2] & 0x7F;

        hv_uint32_t receiverHash = 0;
        switch (command) {
          case 0x80:   // note off
          case 0x90: { // note on
            receiverHash = 0x67E37CA3; // __hv_notein
            break;
          }
          case 0xB0: { // control change
            receiverHash = 0x41BE0F9C; // __hv_ctlin
            break;
          }
          default: continue;
        }

        _context->sendMessageToReceiverV(receiverHash, 1000.0*vste->deltaFrames/sampleRate, "fffff",
            (float) data1,
            (float) data0,
            (float) channel,
            (float) command,
            0.0f // port
        );
        break;
      }
      case kVstSysExType: {
        // not handling this case at the moment, VstMidiSysexEvent *vstmse;
        break;
      }
      default: break;
    }
  }
  return 1;
}

This year I've been trying to pick up the project to get it to python3 (and package at pypi.org), some new generators (for vst2/lv2 audio plugins), updated documentation, and some bugfixes submitted by the community.

There are so many different targets that hvcc is used for and I'm not able to test all the features by myself. If anyone is up for trying the Unity, Wwise, javascript, and any of the other builds that would be great

Currently I've added Distrho Plugin Format (DPF) and Daisy generators, and am looking for better OWL integration (although that will need some transition period on patch compatibility, since they use a separate parameter messaging at the moment).

Check it out here: https://github.com/Wasted-Audio/hvcc

Hopefully we can improve pd-vanilla compatibility and behaviour (we really want [expr] objects that could help a ton with optimizations).

@dreamer said:

Check it out here: https://github.com/Wasted-Audio/hvcc

I've tinkered with this over the past week and successfully compiled a couple of patches to functional linux vsts. Great fun! I have some questions though.

Since the [block~] and [switch~] objects are unsupported, how can i know what block size the vst will use? Will it just default to whatever the daw running it is using? (is it possible to do one sample feedback delays?)

Besides float, bool and trig, are there any other assignable types for DPF parameters? (is a drop down list selection possible?)

I can't seem to make lv2 ports work. I am copying the created <pluginname>.lv2 folder to my local .lv2 folder but the plugins dont register...?

Other than that, great work! I love it!

@bocanegra said:

Since the [block~] and [switch~] objects are unsupported, how can i know what block size the vst will use? Will it just default to whatever the daw running it is using?

Yes, the process() function is handled by the DPF wrapper and eventually the host-thread that the plugin is running in.

(is it possible to do one sample feedback delays?)

I don't know, this may depend on the host. Afaik the heavy engine can run at single sample blocks, but in general I don't believe DAWs run their plugins like this.

Besides float, bool and trig, are there any other assignable types for DPF parameters? (is a drop down list selection possible?)

Specifically the case of drop-down lists is something that I want as well! I tried playing with this using an "enumerator" type (there is a branch that does this), but it's a bit of a dirty fix for it. Ideally we come up with a specific method for these kind off messages. It certainly is possible to add this both to the heavy messaging system and to the DPF wrapper.

I can't seem to make lv2 ports work. I am copying the created <pluginname>.lv2 folder to my local .lv2 folder but the plugins dont register...?

You may need to run make twice in order for the ttl to be properly generated. I think atm you also still have to copy over the ttl into the lv2 directory. Small "quality of life"-improvements to be made there.

Other than that, great work! I love it!

Thnx for testing! Latest releases have a bunch of midi improvements and Electro-Smith is working on a more proper integration with their platform that will be coming soon!

In the mean time please direct all issues and questions regarding the project over to Github or the Discord and IRC chats please, I don't frequent these forums very much and it's better to centralize some of the communication around the project.

Would love to hear more feedback on functionality and tests of the various generator targets!
Am now looking at VCV Rack exporting and some people are working on additional embedded targets based on ESP32 hardware.

Lots of things to come!

@bocanegra said:

Besides float, bool and trig, are there any other assignable types for DPF parameters? (is a drop down list selection possible?)

I have implemented enumerated parameters via the metadata json in the latest release (v0.9.0)
Here is an example plugin that uses it: https://github.com/Wasted-Audio/wstd-dlay/blob/main/wstd_dlay.json#L16

This results in a 0 to n-1 integer being output by the selector, but on the plugin/host side you can get a dropdown with the configured strings instead.

@bocanegra said:

is it possible to do one sample feedback delays?

Btw the answer to this is that the HV_SIMD_NONE flag does single sample processing that allows for such feedback and filter design.

This does compromise any performance increases for targets that enable SSE/NEON/AVX.

The AVX implementation is still buggy and missing some stuff, anyway. However the ~4x performance increase on NEON is valuable enough to keep this in mind.