Having the ability to assign custom names to the buffers would be helpful. Nine things is a lot to keep track of (in human memory) unless you’ve developed a real system or experience around something. If I close down Sonic Pi and don’t get back to it (sadly) for a few days, or even a few hours, I’ve forgotten what is in all the buffers.
Out of curiosity - is there a motivation behind starting with nine buffers specifically? I know they’re all arbitrary but as a new user I’m always having a moment of asking myself which buffer to paste a piece of code into, and then flipping through each of them to assess which is the stalest / least interesting for replacing with. Of course, there’s nothing stopping each user from creating their own conventions (buffer 0 is “scratch”, buffer 1 is “main”, buffer 2 is “drums”…). Being able to label would cut down on some mental tax there.
I think some or all of these additions would help:
Allow for renaming buffers to a user-friendly label
Option to name buffers automatically based on loaded file name
Start with less buffers, ability to add more buffers as needed
Command to Reset all buffers
Default Buffers config - after a reset or new project, layout buffers according to user prefs (i.e. list of named buffers)
Thank you for your consideration and most of all for your great work!
I completely agree with you. Named buffers and their extension, projects (saving and loading whole groups of named buffers) has been on my TODO list for quite a while. I will get round to it I promise.
The motivation behind a number of named buffers dates back to Sonic Pi’s first ever implementation. The original goal was just to build a tool to support a number of lessons, so I first gave it 7 buffers as the first pilot had 7 lessons. I then 0 indexed the buffer numbers at a later date to make it easier to explain indexing. Finally I added a couple more buffers because it simply gave people a little bit more room to play and it was easy to do. It’s definitely high time that this was all changed
Loading / Saving a set of buffers would be brilliant. Already I’m using multiple buffers for each song and loading/saving as individual files e.g. ‘title 0.rb’, ‘title 1.rb’ etc. If just that could be automated it make things much easier and less error prone. That could be implemented with just a couple of new menu items and without having to define some new kind of project structure file.
For me, named buffers aren’t a big thing. The existing ability to put free-form comments at the top of each buffer/file are already fine.
I have run into issues where I want to clear the contents of a buffer, but can’t tell whether it has already been saved. I don’t like the idea of an asterisk indicator when there are unsaved changes to the buffer, because that’s not how live coding works and it would be distracting, but having named buffers would make it easier to see what already exist in my scripts folders, where I could then compare contents and decide if saving is necessary.
I’ve just stumbled upon this seemingly related query whilst perusing the forums
looking for roadmaps, to see what’s in the pipeline, namely for the sonic-pi editor
checking whether any FR’s already raised for label buffers: new, saved, changed scripts (to see what’s saved, and ideally monitor files to identify buffers with modified scripts
Is there a TlDr on this FR? and is there a roadmap? And are FRs reviewed for popularity? Eg those with most likes / upvotes get prioritised?
Also I agree with the point raised by @cubicinfinity , and there’s also the 10-year old test to consider…
asterisk indicator would be distracting
What about adding the config option to opt-in on this, so it’s only there if desired?
feature requests only get implemented if someone implements them - and that’s usually me. Most of my time is typically spent talking about, performing with, promoting and maintaining Sonic Pi. I don’t have a huge amount of time left for working on new features at the moment. I’m also working part time at a university (on related work which will hopefully feed back into new Sonic Pi functionality). If people really want to see new features, I need to be in a position where I can dedicate more of my time on development and less on paid talks, performances, and part-time jobs. The easiest way to help make this happen is to support my work on Patreon: https://patreon.com/samaaron
Also, if I switched to a paid model for the software and that was successful then I could hire a team to continuously work on new features - but that’s not something I’m considering at this point. It’s an important part of my philosophy that Sonic Pi stays free and open source. The consequence of this is slower development.
What about adding the config option to opt-in on this, so it’s only there if desired?