rmw2/updo

A makeover for Puredata in your browser

updo's Issues

Sequential doing Pd.start(), Pd.stop() create separate hardware contexts

NotSupportedError: Failed to construct 'AudioContext': The number of hardware contexts provided (6) is greater than or equal to the maximum bound (6).

Seems like each Pd.stop doesn't remove the AudioContext, but start creates one so if you spam off/on you'll hit a max

Select multiple nodes with click and drag

Desired behavior:
Clicking and dragging in a part of the drawing area with no nodes or patch cords begins drawing a rectangle. On mouse up, all nodes and patch cords that are entirely enclosed by the rectangle are selected.

Current behavior:
Nothing

Drag and drop to upload

Just a nifty little enhancement: make the button area on load also a drop zone for pd files. Drag from your desktop into the drop area to load the patch!

Discuss: State schema for Pd patch / Redux

So after crawling through the WebPd code a little more, it looks like the patch definition found in patch.patchData is only used for initialization. This explains why it is redundant to patch.objects and terribly inefficient to edit. It is used exactly once in Pd.loadPatch() to create each object and establish all of the necessary connections. As far as WebPd is concerned, patch.objects is the only source of truth for what objects are in the patch, and there is no global list of connections. Instead, each object has an inlet and outlet list (lib/core/BaseNode.js), and each portlet object has a list, connections, of other portlets it's connected to (lib/core/portlet.js). The only positioning information is stored in patch.patchData, as it is irrelevant to the running of the patch (aside: maybe there is no top-right to bottom-left tiebreak then?).

Further, patch.createObject simply creates an object from a prototype defined in the "library" (lib/glue.js), assigns it a unique, strictly increasing id, and assigns patch.objects[id] to it. To add connections, you need to reference the proper portlet in patch.objects[id].inlets or patch.objects[id].outlets, and call connect(otherPortlet). This function is symmetric, and will call the otherPortlet.connect(thisPortlet) as well. Disconnect does the opposite. Deleting an object is matter of calling stop(), destroy(), and removing it from the objects list. It seems WebPd does not provide a method to do this automatically.

Bottom line is, we can trash patch.patchData and replace it with our own representation, and then to write back to pd, use normalizr to go from our representation to pdjson, and pdfu to go from pdjson to pd.

As far as things we need to keep track of for editing, we need

• All (real) nodes, with their type, args, x, y, width, height
• All broken/incomplete nodes, with text, x, y, width, height
• All connections, with source (id & port), sink (id & port), and type (signal vs. regular)
• All selected nodes, all selected patch cords
• Whether we are currently drawing a patch cord, and where it started from (id, port, x, y)
• Which node we are currently editing, if any
• [stretch] A clipboard of copied nodes/cords
• [stretch] The previous state (for undoing)

Then we need to be able to respond to actions on the state, including select, deselect, delete, create, move, add preobject, add object, start patch cord, finish patch cord, copy, paste, undo, and maybe some others that I can't think of right now. Anyway, sounds like a job for redux.

TODO:

• formally define the state schema described above
• formally define the list of actions, and write reducers that compute their effect on the state
• rewrite the UI to take state information from the redux store
• profit

Export edited pd patch as Pd file

This is pretty essential functionality: we would like to be able to actually save the patch that you're working on. pd-fileutils seems to have a method for going from its custom pd-json to pd, so we just need a way of going from whatever internal representation we have to pd-json, and then call the pdfu method and download the result