Sonica always creates an editor group, which takes up sspace on the screen

[Neurrone]

As per title. An extra editor group is always created which is troublesome when e.g, doing a screen share.

[ahicks92]

As far as we know, we can't work around it without doing something complicated with a Synthizer subprocess. That's not off the table at this point I don't think, and waveforms are planned over there, but the long and the short of it is that you have to have a browser to hook into WebAudio and that's how you get one. @wiresong did most of the code (primarily I was consulting) and maybe he has more details. Also if you have an idea, do share. I think it's news to both of us that there's an actual visual problem, though.

Maybe sufficient justification to bump synthizer/synthizer#17 up the list.

[Neurrone]

I don't have any ideas for now, will share if I think of something.

Yeah, I mentioned because it does cause visual problems. To the effect of it using half the screen width and what appears visually in the Sonica window is a blank editor group.

[wiresong]

Hi,

Yes-as @ahicks92 said, we're doing all of the audio processing via WebAudio (for good-ish reasons, some of it is that there weren't reasonable alternatives at the time for what I'm doing), and that requires a webview frame.

We should get Synthizer to support what we need in the next week or two, and this problem should disappear at that point.

[Neurrone]

Wondering if you meant to close this issue?

[wiresong]

Yes-I'm somewhat unfamiliar with github norms, I thought to close the issue because the question was answered. In retrospect I realize that's not really how issues are generally used.

I'll reopen and comment here once we shift to Synthizer.

[ahicks92]

I have made Synthizer support waveforms. In order to move this to a subprocess, we must:

• get someone to confirm that we can call subprocesses from extensions as we need to, particularly:
  • That we can do so when connecting to remote ssh hosts
  • That we can get access to stdin and stdout of the process.
  • If we can do so easily, get the latency of writing to stdin (maybe a Python script that echoes timestamps back, and output the timestamp in node before we send? I dunno).
• Move the current JS logic to a binary, in Rust.
• Implement the binary's protocol: write messages to stdin, get messages from stdout, log if there's errors or whatever.

This is actually not as bad as it seems. I can do the Rust part of this in an hour or so, I think: grab Serde, approximate something close to the state the add-on already extracts and sends to the webview, and go. That may or may not turn into Synthizer bugs, but I'm not opposed to this being a way that we find them and I am of course positioned to fix them. The JS/VScode side of this isn't something I'd want to take on; @wiresong are you willing to do that? if not, maybe someone else is. I don't think the vscode side should be hard for someone who already knows what they're doing: it's just replacing the thing that sends messages to the webview with a thing that sends messages to the subprocess.

I don't want to start work on the subprocess, though, until we're sure that we can get it working. Someone needs to run those experiments. Due to lack of time, lacking vscode/node knowledge sufficient to do it quickly, and also that the extension works perfectly for my needs, I consider someone else doing that step to be blocking on any work I might do here.

[wiresong]

I'm currently busy with college and am unsure how soon I'd be able to do the refactor. My ETA on getting us the subprocess experiments is this weekend on the earliest, the next weekend on the latest (if I'm lucky enough to get time earlier this week, I'll do it then and update).

If anyone else wants to take this up in the meantime, though, I'd be more than happy to walk them through what's required.