Missing features for Heavy

[dromer]

Few things that are currently not possible:

• Uploading more than one file: one typically organizes a pd/heavy project by having one main entry point and then a library of "abstractions". Requiring everything in a single patch file is extremely inconvenient and inefficient.
• It would be good to at least include the latest Heavylib in the path -p so these abstractions are included (plugdata ships with Heavylib in the path, for instance): https://github.com/Wasted-Audio/heavylib
• There are currently as good as no options available. We can't enable midi i/o and we cannot setup port-groups or in the future CV ports.

There are probably other things missing, but these are the main features that should be included to make the cloud compiler work well.

For the options I suppose this is currently partially limited by having uniform arguments for all 3 targets.

[falkTX]

• Uploading more than one file: one typically organizes a pd/heavy project by having one main entry point and then a library of "abstractions". Requiring everything in a single patch file is extremely inconvenient and inefficient.

agree, though not sure how we handle the selection of the main file. should we allow to pick from the uploaded filenames list or is there some consensus on what name(s) to use for the main file?

• It would be good to at least include the latest Heavylib in the path -p so these abstractions are included (plugdata ships with Heavylib in the path, for instance): https://github.com/Wasted-Audio/heavylib

PR welcome for this, is it just tweaking the build/configuration stage?

• There are currently as good as no options available. We can't enable midi i/o and we cannot setup port-groups or in the future CV ports.

how would this work? used supplied conf file or expose the options in the web gui for the builder? maybe both? (web gui option would override conf file?)

regarding all options being the same for all 3 builders, we dont need to keep that restriction.

[dromer]

agree, though not sure how we handle the selection of the main file. should we allow to pick from the uploaded filenames list or is there some consensus on what name(s) to use for the main file?

I was thinking the same: select the specific file you want as the main. Sometimes something like _main.pd is used, but this can also get in the way. The user knows best which file should be used here.

PR welcome for this, is it just tweaking the build/configuration stage?

I guess? we could just do a git clone and add the local path to the command. It would at least save users from having to copy-paste these (common) abstractions into their project. Otherwise have a global copy of heavylib and add this to the path argument. Which do you think is better?

how would this work? used supplied conf file or expose the options in the web gui for the builder? maybe both? (web gui option would override conf file?)

The later would be most ideal I suppose. The advantage of being able to supply your own json would be that a user doesn't have to fill in all the details any time they want to test a new build. Downside of the web-ui for ie. port-groups is that it's not easy to create a nice form for it: https://github.com/Wasted-Audio/wstd-3q/blob/master/wstd_3q.json#L16-L31

However you'd probably want to parse and pick only those options that are actually used by the cloud builder. Things like enabling UI builds, custom library and DPF paths should be ignored.

And for that last one: instead of a symlink we can just point the root dpf path in the config (unless you prefer the symlink approach).

regarding all options being the same for all 3 builders, we dont need to keep that restriction.

Yeah I figured, was just a reflection on the current setup :)

[dromer]

Getting started with some of the missing features.

With this one can at least enable midi i/o: #3