To receive audio input into your patch add an [adc~] object.
To send audio output add a [dac~] The number of channels can be configured by providing arguments to object. For example [dac~ 1 2 3] will generate three output channels. [adc~ 1] will make a single channel of audio input.
Note that top-level graphs (e.g. _main.pd) should not have any [inlet~] or [outlet~] objects. These are reserved only for abstractions.
All (control) [receive] and [r] objects annotated with @hv_param will be exposed as input parameters in each framework. The name provided will propagate through to the plugin interface.
For example, [r gain @hv_param 0 1 0.5] will show up as "gain", with a minimum value of 0, a maximum value of 1, and a default value of 0.5. If a patch has multiple exposed receivers with the same name, they must all have the same minimum, maximum, and default values as well.
Receivers not annotated with @hv_param are still completely functional, they simply will not be exported to the framework interface.
An optional parameter type can be set to which generator implementations can program custom features. The default type is float.
For example, [r toggle @hvparam 0 1 1 bool].
See the DPF docs for more information on how parameter types can be integrated into a generator.
In the same manner as above, all (control) [send] and [s] objects annotated with @hv_param will be exposed as output parameters.
For example, [s envelope @hv_param].
Messages passed to these send objects can be forwarded on to other parts of the application. This is useful for creating audio-driven behaviours or extracting analysis information.
See the specific framework details for more information on output parameter support and integration details.
All (control) [receive] and [r] objects annotated with @hv_event will be exposed as events in the Unity target only.
For example, [r bang @hv_event] will show up as a button called "bang" in the Unity Editor interface.
See the Unity docs for more information on exposing events and controlling them.
Some generators, like Daisy and DPF, enable support for extra configuration metadata.json file using the -m. It depends on the generator what is supported. See the DPF docs for more information on setting meta data for plugins.
Simple Daisy example that selects the desired board to build for:
{
"daisy": {
"board": "seed"
}
}If there's an incompatibility within the patch, Heavy will generate an error message.
Heavy will also perform patch analysis to look for common mistakes and inconsitencies between Pd and heavy behaviour. The targets will still be generated correctly but it might be useful information for example when cleaning up the patch.
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.
- Heavy does not support numbers in
[unpack], e.g.[unpack 0 0]givesHeavy only supports arguments 'f' and 's' to unpack.Workaround is to usefinstead, e.g.[unpack f f], and if necessary prime the default values with a[loadbang]and[0 0(. - 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. - 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
OWLandDaisythat 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).