Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated export for the autocompletion (synths, sounds, samples...)? #17

Open
jtpio opened this issue Apr 10, 2017 · 3 comments
Open

Comments

@jtpio
Copy link

jtpio commented Apr 10, 2017

It looks like the file sonicpicomplete.vim was last updated more than 2 years ago.

Meanwhile, a few more synths and other options have been added to Sonic Pi, and it would be great to have them with the autocomplete feature of sonicpi.vim!

How is this file usually updated? By manually comparing with the Sonic Pi source code?

Otherwise, it could be interesting to automate this process, for example with a bunch of regular expressions on specific files to extract synth names, fx names and so on.

Also, the information about synths has been moved to: https://github.com/samaaron/sonic-pi/blob/master/app/server/sonicpi/lib/sonicpi/synths/synthinfo.rb

@dermusikman
Copy link
Owner

dermusikman commented Apr 11, 2017

You are correct that it has been quite some time since this has been updated. I've been meaning to get things up to speed, but simply haven't.

When I first wrote this, I found that there was no... sophisticated way to automate the import of data. Looking at the code you provided, it would probably a be lot easier to leverage some automation.

I do have two concerns, as follows:

  1. I feel ashamed enough to force the user to concern themselves with configuring the CLI command - the last thing I'd want them to do is provide a path to the source code. For this reason, I'm more inclined to write a script to aid us maintainers in manually updating the plugin, as opposed to requiring the user to conform to some arbitrary filesystem structure or update yet another configuration field.

  2. If auto-configuration were to be part of the loading procedure, I'd want the automatic configuration to be cache-able, and the process short-circuit-able. This foreign Ruby code is called every time Sonic Pi mode is invoked, and I'd hate to force the user to endure 200ms of loadup time each and every time. (Even if the load time is imperceptible, it feels like wasted resources to me.)

I'll make a point of going over that code to make that automation script and decide whether that will be part of the bundle load or just ease the maintenance burden. Honestly, being reluctant to wade through the code is one of the primary reasons it's been so long since this has been updated -- seeing that the process should be significantly easier is a real help, thanks!

If you have any code, I'm happy to consider it. Otherwise, I'll make a point to give this project some more love in the coming days and weeks.

@jtpio
Copy link
Author

jtpio commented Apr 11, 2017

Option 1 is exactly what I had in mind: it should just be a script to help maintainers automatically generate the autoload/sonicpicomplete.vim and syntax/sonicpi.vim files:

  1. Run the script to automatically add new synths and other options, directly parsed from the Sonic Pi source code.
  2. Commit and push the changes to this git repo.
  3. When vim users update their dependencies, they will just get the new stuff for these two files as usual

In the first place, I wanted to manually add new synths spotted in the Sonic Pi documentation that are missing in the autocompletion (dtri, synth_violin and others). But then realized that you might already have a tool to ease the process.

@dermusikman
Copy link
Owner

I've just put up #20 with the utility script we discussed and its fruit.

Truthfully, I've been a bit rusty with sonic-pi and this plugin, so I'd be grateful for feedback before cleaning up and merging.

If the utility script has successfully found everything, for instance, it may be advisable to translate the output to straight vimscript instead of importing Ruby code. (I'd originally made that decision in order to leverage complex arrays.) I may also be missing something very plain to a more active user. (And yeah - I hope to get back to being a more active user sooner than later.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants