[declare] causing crash

A single [declare] object is causing this error:

ERROR: dictionary update sequence element #0 has length 5; 2 is required

Understandably we don't really need the [declare] object as the abstraction implementation assumes all patches are in the same directory (right?), but some better error handling to inform people that this is the case would be nice.

#N canvas 0 22 450 300 10;
#X declare -path foo;
#X obj 138 69 declare -path foo;

C++ wrapper target

Create a C++ class wrapper for handling namespacing and memory management in an easier way for C++ projects.

Right inlet of [sel] unsupported

#N canvas 386 187 163 106 10;
#X obj 52 14 loadbang;
#X obj 25 62 sel 0;
#X msg 52 36 1;
#X connect 0 0 2 0;
#X connect 2 0 1 1;

returns

ERROR: {
  "exception": "('Connection [message {local:[[1.0]] remote:[]}:0] --> [__graph.gMa8P(_main.hv.json):1] connects to out-of-range let.', None)",
  "has_error": true
}

[div] does not seem to be supported, contrary to the supported objects list...

Even a patch with just a [div] object throws a fatal error for the compiler.

Enable SIMD optimisations in Javascript target

https://hacks.mozilla.org/2014/10/introducing-simd-js/

Our code already has many SIMD optimisations, will need to figure how to make use of them when compiling javascript code using emscripten. This will have drastic improvement on the performance when running in the browser.

Support [expr] and [expr~]

Include patch preview on individual version pages as well as project page

metro does not respond to right inlet

#N canvas -1546 -487 182 131 10;
#X obj 11 74 metro 1000;
#X obj 11 11 loadbang;
#X obj 11 97 print;
#X msg 68 53 2000;
#X obj 11 32 t a a;
#X connect 0 0 2 0;
#X connect 1 0 4 0;
#X connect 3 0 0 1;
#X connect 4 0 0 0;
#X connect 4 1 3 0;

[swap] throws error if not initialised

ERROR: Cannot convert argument "" into float.

#N canvas 307 118 795 679 10;
#X obj 393 209 swap;

Just needs better error reporting.

osc~ playing at the wrong pitch

Windows 8.1.
Chrome 42.0.2311.90
Pd 0.46.5

[osc~ 440] in the patch is playing at 478.9Hz in the browser. Possibly a sample rate issue? The ratio is the same as 48000/44100. Windows runs at 48KHz by default.

Use Heavy Markup in PureData to export specific receivers

When generating parameters from [receive] objects we should only create code from user specified instances. [receive]/[send] objects are commonly used within a patch architecture and having a global scope for these in the integration interface would be too verbose and potentially confusing.

Proposal for a Heavy mark-up specification to tag certain [receiver] objects for automatic code generation of parameters.

i.e. in a patch a user would create an object such as [r @hv_param freq 0 1 0.5], which would generate a parameter to the patch called "freq" with minValue=0, maxValue=1 and defaultValue=0.5

Optimise [sqrt~] performance

Support [vcf~]

automatically compile from a cloudsynced drive

heavy could have an open watch folder in google drive/dropbox etc and then when a file gets changed automatically start to recompile, removing the upload step and click compile step from the process.

tabread~ Expecting , delimiter error

ERROR: Expecting , delimiter: line 33 column 5 (char 516)

Caused by this:

#N canvas 405 80 237 238 10;
#X obj 64 74 tabread~ blah;

Don't initialize GUI sliders from patch preview

Currently they initialise with a value of 0.5 for patch preview, which can override some essential initialisation in the patch itself...

Show all unsupported Pd objects when compiling

Instead of exiting on the first one it gets to.

Support implicit sends in message box

biquad~ should support set and clear messages

[line] doesn't update correctly if input message is queued before first process loop

In javascript this patch should begin interpolating from 0 through to 0.5, but instead it outputs all 0's until the end of the ramp period where it then outputs 0.5

N canvas 405 102 409 431 10;

X obj 120 210 line;

X msg 120 188 $1 1000;

X obj 149 124 t a a;

X obj 210 220 print A;

X obj 106 288 print B;

X obj 149 70 r input;

X connect 0 0 4 0;

X connect 1 0 0 0;

X connect 2 0 1 0;

X connect 2 1 3 0;

X connect 5 0 2 0;

How should we support [block~] ?

Is [tabwrite~] supported?

Getting this error with a patch consisting of just a [tabwrite~] object

ERROR: {
  "exception": "('Object type \"samplerate~\" cannot be found.', None)",
  "has_error": true
}

Support [tabread]

[tabwrite], [tabread] etc. cannot find named [table] objects, but can find named arrays

Optimise [cos~] performance

Generate the Heavy Javascript wrapper code as a separate file

Currently this is compiled into the main javascript *Lib.min.js file. However it's useful to see this when trying to understand how the js interface works.

Support [throw~], [catch~], [send~] and [receive~]

Context(_c) macro is too generic

The C source code makes us of preprocessor macros, there are some in the generated code that are a bit too generic and could conflict with projects that it's integrated into.

Support [samphold~]

Prune connections and remove unnecessary objects in Pd graph

Subpatches do not take on parent patch's creation arguments

[f $1] inside an abstraction with a creation argument works fine, but [f $1] inside a sub-patch inside the abstraction throws an error:
ERROR: dictionary update sequence element #0 has length 4; 2 is required

Sub-patches cannot have creation arguments of their own, and should implicitly take the creation arguments of their parent patch.

Heavy does not concatinate inputs in message boxes

#N canvas 365 249 286 155 10;
#X obj 15 10 loadbang;
#X obj 15 51 f 3;
#X obj 23 30 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X msg 15 75 hello-\$1;
#X obj 15 99 print;
#X text 13 120 hello-3 is expected. Heavy returns hello-\$1;
#X connect 0 0 1 0;
#X connect 1 0 3 0;
#X connect 2 0 1 0;
#X connect 3 0 4 0;

Support signal input to control frequency in [phasor~]

This is needed for simple synthesis techniques such as FM.

Also affects [osc~] and other abstractions that use [phasor~] internally.

Command line util for speedier patch upload workflow

Support [pack] and [unpack]

Consider using only up to SSE3 for HV_SIMD_SSE

Only 75% of CPUs support > SSE3 according to http://store.steampowered.com/hwsurvey, but > 99% support up to SSE3.

tabread4~ and tabwrite~ require initialisation argument

tabread4~ and tabwrite~ should be able to instantiate without needing a creation argument of a table name, but currently this produces this error:

ERROR: {
  "exception": "('No corresponding table with name \"None\" found for object __tabread~if {table:None}.', None)",
  "has_error": true
}

Compiler crashes if there are inlets/outlets where there is no parent patch

Understandable that this would cause an error, but would be nice if there was some reporting of why the error has occurred to the user.

Support [vline~]

Support [fft~], [ifft~], [rfft~] and [fifft~]

special version of puredata with only the supported objects

it might be interseting to take a generic version of puredata vanilla and removing all the objects that are not supported by heavy. then it is clear what will not work before you compile

Support [biquad~]

Consider a different system for auto-generation of GUI sliders for patch preview

It's a really great feature, but...
some patches e.g. reverbs, have many [receives], only a few of which are actually useful to visualise.

Could there perhaps be a special string that must be present in the [receive] name in order for Heavy to auto-generate a GUI slider for it?

e.g.
[r myParameter] would NOT auto-generate a slider whereas
[r myParameter-GUI] would auto-generate a slider

[table] doesn't seem to be correctly supported

"exception": "('No corresponding table with name \"major\" found for object __tabread {table:major}.', None)"

But arrays work correctly...

Dollar arguments not working correctly in [route]

Wwise plugin target

This will contain a visual studio project with the necessary source files to compile an audio generator plugin for Audiokinetic's Wwise platform.
[receive] can be mapped to RTPC values from the plugin
[send] can be used to pipe messages out of the plugin to the rest of the system
[adc~] and [dac~] would determine the plugin channel configuration
Additional tools might include a build script to deploy the plugin components (*.dll, *.lib and xml file to correct directories)

Add an optional flag to uploader to determine amount of memory allocated to JS by emscripten

Optimise [pow~] performance

How to handle [adc~] in javascript target

Currently in the javascript target the process method is fed null buffers for the input channels, regardless of the patch contents, i.e. if it should accept input audio

One solution was to open up the microphone input via the web audio api and pipe that in. However I feel this shouldn't be automatically generated by the compiler and that it is down to the user to decide what to feed into the patch.

I propose that we create an additional temporary input buffer in the javascript wrapper and copy over the data from the AudioBuffer source that's passed through with the process method. The contents of the input buffer should be determined by the user.

If an [adc~] object is not present then the number of input channels to the patch will be 0 and we can opt to always pass a null pointer through.

enzienaudio / heavy Goto Github PK

heavy's People

Contributors

Stargazers

Watchers

Forkers

heavy's Issues