@v3470: there is also the option of using text snippets. This is still an undocumented feature, and may be updated in the future; but it's there.
See #587 for details.

(VS Code team member here)

I wonder if a vscode extension could handle the code writing, intellisense, hovers, etc., and delegate out to Sonic Pi for interpreting? @ethancrawford Is there any programmatic interface to the application?

Alternatively, is there any work being done on a web-tech frontend? Whereby a monaco editor could be swapped in for the one you've made, or perhaps the surrounding widgets could be dropped into a vscode webview?

I've only just found this project (I like it so far though!) so I'm not sure what all is involved. Is it accurate that the frontend consists entirely of:

• editor
  • buffer selection tabs
• play/stop/record/etc. action bar
• docs panel
• sidebar with:
  • text log stream
  • 'scope' visualization
  • 'cues' section (not sure what this does)

?

Hi @JacksonKearl,

There are a few other folks that might be more knowledgeable about specific details than I am at the moment - /cc @rbnpi / @samaaron / @xavriley or whoever...
I personally haven't kept much up to date with methods to control Sonic Pi externally. I know that there are a few things that exist here and there, such as projects to control Sonic Pi's server component from python.

There is a rudimentary html GUI in the Sonic Pi codebase. However, it has not been kept up to date for some time - it hasn't be a focus for Sam for quite a while. We would always be happy for assistance in resurrecting it though.

Regarding the front end editor: the components that make up the layout are described in the built in tutorial: See https://github.com/samaaron/sonic-pi/blob/master/etc/doc/tutorial/01.2-Exploring-the-Interface.md for example.

As far as using Sonic Pi from other editors, including VS Code, you may want to have a look at the following issue: #1902 - there appears to be a link there to an existing VS Code plugin.

I'm not entirely sure when easier command line/headless control of Sonic Pi might be built in, but I'm sure that Sam would be in favour of it.

Thanks for the follow up! I saw the plugin mentioned in #1902, but it’s a bit more barebones than I had in mind.

For you or anyone else, it would appear on a surface level that Sonic Pi is a thin wrapper around SuperCollider. Is this the case, and if so would you recommend interfacing with SuperCollider directly for any possible VSCode integration, or working through Sonic Pi?

(I should note that while I’m on the VS Code team, this wouldn’t be an official Msft product in any way, it’s just of personal interest! 🙂)

Hi @JacksonKearl,

Great that you’re interested in getting VSCode to play nicely with Sonic Pi. I’d love to see that happen too.

Super happy to jump on a call with you to explore ideas and sync if that’s something you’d be interested in.

Hey @samaaron,

Nice work at Satellite!

Yes I'd be happy to jump on a call. I can make myself free most times besides 1PM-2PM pacific, let me know what works for you. :)

I see mentions of VS Code here. I believe more people will benefit from the ability to uee SonicPI "headless" and pick their own favorite text editor.

I for one believe such an implementation might not be that complex, and should include something like this:

• Set up a global system shortcut key to "reload the last file loaded, and play"
• Set up a global system shortcut key to "stop playback"

This way, we can open SonicPI, load the file we want to edit, minimize it, and go use our editor, and press these hotkeys to play/stop.

I have configured something like this with AutoHotkey, but it is clunky and reduces the level of fun.

Agreed that making it possible to use Sonic Pi headless would be nice. It's something I'ld like to make easier in the future.

However, I think it's important to realise that "more people" really means "more developers" as most people in the world don't currently program and don't use a developer tool.

Sonic Pi's primary user focus is on people that don't program so providing an out-of-the-box editor is the main goal and helps it to lower the barrier to entry. This is where 99% of my energy is going and whilst I do support the idea of enabling other editors to get involved it's not something I'm personally going to spend a huge amount of time on.

I think it's important to realise that "more people" really means "more developers" as most people in the world don't currently program and don't use a developer tool.

Sonic Pi's primary user focus is on people that don't program so providing an out-of-the-box editor is the main goal and helps it to lower the barrier to entry.

As a developer (primarily writing Python using VS Code) and a newcomer to Sonic Pi, I had immediate thoughts like "the autocomplete could be better", which got me thinking "how can I use VS Code from Sonic Pi?", which lead me here. Now I'm thinking "how can I help improve Sonic Pi's native autocomplete?" Things like fuzzy completion would be awesome, but sound like a big lift. I'm guessing there are smaller bits (like filling in missing opts) that would improve the experience for the primary audience.

With that in mind, could one of the maintainers link to some starting points for understanding the autocompletion mechanism?

That said, I would still love to play Sonic Pi from VS Code. 😉

Sonic Pi's autocomplete system is built on top of QScintilla (which is in turn built on top of Scintilla). Both are implemented in C++.

I'd love to see any improvements to the autocompletion system!

Thanks, @samaaron. If you have a moment, can you add a link here to a relevant spot in the codebase?

I'm not sure QScintilla supports fuzzy autocompletion - but I'm pretty sure that's the package that you'd need to be hacking.

Sonic Pi just tells which "context" to be using depending on the previous words in the buffer. It's pretty basic: https://github.com/samaaron/sonic-pi/blob/master/app/gui/qt/utils/sonicpiapis.cpp#L79

Thank you! To be clear, it's unlikely that I'll be working on this any time soon (if ever), but this seems helpful for folks who might.

Here's a permalink to updateAutoCompletionList, just in the code is modified:

https://github.com/samaaron/sonic-pi/blob/0bf4e35259c9e7c5c0cf3b841e404a08a1ca65dd/app/gui/qt/utils/sonicpiapis.cpp#L79

Hi, @JacksonKearl, I started recently with a proof of concept to see if a vs code extension could work with Sonic Pi, and so far I am very pleased. With just around 300 lines of code I have something that boots the the servers, can send code to be run on Sonic Pi, can stop it, and shows the logs, cues and all that. It is very immature so far, but it looks very promising. And as you mention, you get all the goodies that vscode has when working with ruby code.

I can also see some limitations that may be crucial: can only show one thing in the output panel (log OR cues - or other things). Would be nice to be able to split the view to show logs and cues at the same time. And it's not very clear how we could integrate the oscilloscope view, help, etc.

At the moment it is working on Windows only, I want to make it work under Linux too, and then I'll share it here on github, so that people can have a look, and we can use that as a draft for discussion. Hopefully will be able to do that this weekend.

I am also looking at the OSS version, because for our use case it might make more sense. What do you think?

It would be great to have a vscode expert on this... :)

(DISCLAIMER: I am using this as a project to learn JS / Typescript, my background is C++ / Python, so it might be a big mess - but so far I am really enjoying doing it, the vscode API is very clean and intuitive).

Hi, I have just uploaded my initial work on using Sonic Pi from vscode to github. Find it here: https://github.com/llloret/sonic-pi-vscode-editor.

I have tested it on Windows for now, but Linux should work too. Make sure you update the paths as necessary as explained in the README.

@JacksonKearl , it would be great if you can share some insight and let us know if this is what you were thinking of. It would be interesting to understand the possible future limitations as well... (but perhaps not yet ;). As I said, my professional background is mostly C++ / python, and ts / js is quite new to me.

We've been discussing the possibility of using other editors inside the Sonic Pi core group and I think that in general we are quite excited about it. (People from core - please feel free to contradict me if this is not the case!).

Cheers!

@llloret nice! I just tried it out on macOS, and after updating the paths it seems to work quite nicely.
It still uses Alt+R for run, not Cmd+R like in Sonic Pi - Cmd+R seems to refresh the whole app screen and lose any unsaved changes.

@llloret nice, sounds like good progress!

I can also see some limitations that may be crucial: can only show one thing in the output panel

This is true... could anyone who has significant experience with the product explain various ways in which they use those views (log & cues)? (@samaaron) I ask because we could in theory make them tree views rather than simple output channels, which could possibly provide more benefits but it's hard to say without knowing how the views actually get used. Alternatively these could be read-only editors to which the extension writes.

And it's not very clear how we could integrate the oscilloscope view, help, etc.

The oscilloscope view could be implemented as a webview, though one consideration here is that if the cues and log are not implemented as editors, the scope and those views wouldn't be able to be shown in one column as they are in Sonic Pi.

For help, in my (limited) use of Sonic Pi, it seemed like the help was mostly for docs, which ideally would be instead provided via hovers, to be more in-line with the typical VS Code experience (though it could also be a tree view). Besides that there's also the tutorial, which I'd say could be skipped for now (this could be implemented as a notebook), and the examples, which I might implement as a quick pick (i.e. select command "Sonic Pi: Examples", then pick from a list and it opens that example in a fresh editor), though perhaps they could instead be implemented as a filesystem (i.e. select command "Sonic Pi: Examples", then a fake "examples" directory is created and either added as an additional root, or just opened in a new window).

I am also looking at the OSS version, because for our use case it might make more sense. What do you think?

Could you explain what you mean by this?

@emlyn you can customize all your keybindings with Preferences: Open Keyboard Shortcuts (in the command palette: f1). But it's concerning that you lose unsaved changes, we should be backing those up. Do you have any settings configured regarding "hot exit"?

@JacksonKearl one hesitation I have about some of the changes you describe around the documentation is that accessing things by typing to select a command such as Sonic Pi: Examples doesn't sound 10 year old friendly. I may be misunderstanding what you mean - but I know that buttons to trigger things, like in the existing SP GUI, are easily discoverable.
I can't recall if a similar thing has been discussed before, but if there's a desire to make things fit a standard VS Code workflow/design, it seems to me that it would be good to perhaps ensure that there is a '10 year old friendly mode' and an 'advanced mode'. (If such a thing would be possible).

@ethancrawford I understand where you’re coming from re. discoverability. I think a bigger question here is what role a VS Code "head" plays in the Sonic Pi ecosystem. Such as...

1. is it a "pro feature", specific to people familiar with vs code, with other editors having their own extensions?
2. Is it a "pro feature" and the single (or at least main) alternative head?
3. Is it offered as an alternative interface to both beginners and experienced?

I think most likely would be 1 or 2, which to me means that making the total novice experience as smooth as possible isn’t as high a priority, as the expected users would have experience enough to know what they’re looking for. On the flip side, making the experience more in-like with how users expect vscode to behave (I.e. commands being discovered through the command pallete) would be a higher priority.

Agreed. I'm all in favour of making things fit with a standard VS Code workflow/design if what we are discussing here is an extension for VS Code as an alternative editor.
Also, unless I understand wrong, our interest was also in exploring the idea of a customised version of VS Code as the primary editor (which would need to be simple enough for a 10 year old to use).

Nice to see all this discussion, but it seems like there are two paths here. The predominant one seems to be about VS Code.

However, there's also discussion about improving the native autocomplete, which seems more aligned with the title.

I wonder if the VS Code conversation might be more appropriate on the extension's repo, or on the forum, or ???

Which is precisely what I was thinking. @JacksonKearl - if you are willing, let's continue this discussion over at https://in-thread.sonic-pi.net/t/vs-code-extension/3935

Hey @JacksonKearl, now that v4 is finally out and has the basics for an boot architecture that should make integration with external editors like VSCode possible - perhaps now is a good time to re-ignite this conversation if you still happen to be interested?