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.

@not.tachyons This looks like quite an ambitious project!

Are the binaries that get compiled able to talk to a GUI using the same interface that Pd itself uses to talk to a GUI?

I did a quick hello osc~ test and exporting in js and it works (100k total):
https://s3.amazonaws.com/eeight/heavy/index.html

But a bigger patch (Shore) is simply too... heavy (violating time to process audio).

Very cool indeed.

@EEight What happens if you compile a patch that has [loadbang]---[metro 1000]---[bng]-- is there any way to receive the gui update messages from the binary that Heavy compiled?

@jancsika Yes according to the documentation (JS output):
https://github.com/enzienaudio/hvcc/blob/master/docs/07.javascript.md

 function onModuleLoaded() {
    // instantiate the AudioLibLoader object
    loader = new heavyModule.AudioLibLoader();

    // this will set up the WebAudio context add a new audio node
    loader.init({
      blockSize: 2048, // number of samples on each audio processing block
      printHook: onPrint, // callback for [print] messages, can be null
      sendHook: onFloatMessage // callback for output parameters [s {name} @hv_param], can be null
    });
  }

  // print callback
  function onPrint(message) {
    console.log(message);
  }

  // output parameter callback
  function onFloatMessage(sendName, floatValue) {
    console.log(sendName, floatValue);
  }
 // send a bang to an event receiver called "Attack"
  loader.audiolib.sendEvent("Attack");

  // send a float value to a parameter receiver called "Distance"
  loader.audiolib.setFloatParameter("Distance", 10);

@EEight That code presumably sets a callback for a global receive symbol which exists in the patch.

I'm asking about setting a callback for all messages sent from Pd to the GUI. In Pd Vanilla this would mean setting a callback for all messages which are sent to sys_vgui/sys_gui.

@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;
}