Copying and pasting nodes

[maximecb]

Copying and pasting nodes

[alexlitty]

However, we could potentially reproduce input-side connections coming from outside when copying and pasting within the same project/tab. The question is, do we want to? I'm thinking it might be simpler and more predictable not to.

I'm pretty torn on this. This is a wonderful idea, I definitely see the usefulness of this feature, though I find it to be potentially confusing or even an obstacle as default paste behavior in some scenarios.

Consider the simplest case: You have some nodes with input-side connections. You want to copy them without copying the input-side connections. All you can do is copy and paste them, remove the connections, and create the new connections you actually want.

My brain found this weird at first, but I admit the more I think about this, the more I've come to like it -- At some point you'll need to create the new connections anyway, so there's not really an issue if your paste creates some default connections.

But then consider: You have some nodes with input-side connections in Project A. You copy them and paste them into Project B, and they're inserted with no input-side connections. You go back to Project A, paste again, and they're inserted with input-side connections.

It totally makes sense, but if you're in a flow it might be (admittedly probably trivially) jarring.

Copying and pasting is going to be even more powerful because of what I've been calling "modules", which are just a group of nodes fused into a single meta-node (created using Ctrl+G)

This is working great by the way! Very excited about these.

Copying and pasting modules is going to be a little complicated because it needs to be done recursively.

A passing thought comes to mind about pasting blocking JS execution; I wonder if modules might become complex enough to worry about that, and if we need to design an asynchronous "chunking" solution over multiple event loops.

My intuition says it'll be okay for now, and maybe we revisit this if it ever becomes a problem?

In terms of API, [...]

Sounds great, no objections! I'll get this started and check in if I run into any issues with this.

[maximecb]

But then consider: You have some nodes with input-side connections in Project A. You copy them and paste them into Project B, and they're inserted with no input-side connections. You go back to Project A, paste again, and they're inserted with input-side connections.

Yeah, that's one issue I'm thinking of. I think I honestly prefer having simpler and more uniform behavior. Kind of going along with the principle of least surprise. The other thing is, if you copy a set of nodes and paste it into the same project, and the input-side connections get pasted, it might not be visually obvious which are the connections that just got pasted. You could reconnect them to whatever you want, but it might not be obvious which ones they are if you're copying 20-40 nodes at once.

But then I don't know. There's also an argument to be made that you could have say, a sequencer with some sound output nodes connected to it... And you could easily just copy and paste that whole thing, with the input-side connections... And then you'd have multiple voices for your track where you can just tweak the melody on each sequencer a bit. I can definitely see the input-side connections being copied being better in terms of user productivity. So I'll let you make that choice. At the end of the day, it's not hard to change this after it's implemented if we find the behavior suboptimal when we actually try it.

A passing thought comes to mind about pasting blocking JS execution; I wonder if modules might become complex enough to worry about that, and if we need to design an asynchronous "chunking" solution over multiple event loops.

JavaScript JITs are very fast. In my opinion, for this to be a problem, we'd need to have graphs with like 150K+ nodes. Before that becomes a problem in terms of blocking UI rendering, we're going to run into problems in the audio rendering thread which is going to start glitching because it can't keep up. I think we might bottleneck at around 500 to 3000 nodes. At which point some optimization work in the audio thread will become necessary.

My intuition says it'll be okay for now, and maybe we revisit this if it ever becomes a problem?

Yes totally. Let's avoid complex async solutions for now. However, I just realize this morning that there's something we probably want to refactor in the way the state is stored in order to improve performance. I will open a new issue for that.

For the copy and paste buffer API, can we put the glue code in main? I think I'd like the model to remain as "pure" as possible, and free of web-related code. In part because eventually, we might want to import model.js to do some validation of uploads on the server side.

[alexlitty]

Very well! Let's start with having the input-side connections included, just so we're giving it a chance. If we find ourselves fighting with it, or if users comment negatively on it, we can reconsider then -- You're right, it won't take much effort to change this in the future.

(If we do end up removing it later, I can also see this being "power user" behavior accessible through a different paste shortcut, like CMD/CTRL + SHIFT + V to paste with input-side connections, and CMD/CTRL + V to paste without input-side connections)

Before that becomes a problem in terms of blocking UI rendering, we're going to run into problems in the audio rendering thread which is going to start glitching because it can't keep up.

Excellent point.

For the copy and paste buffer API, can we put the glue code in main? I think I'd like the model to remain as "pure" as possible, and free of web-related code. In part because eventually, we might want to import model.js to do some validation of uploads on the server side.

Absolutely! I've had similar hopes for the Model class, I'll keep that in mind for all of model.js too.