I love using Sonic Pi. Thank you very much for this awesome tool.
What I would really like is if the current thing that is playing right now was highlighted in the editor visually. It’s not being selected or anything it just has a different background color to show it is active. This would be a version of live debug as well.
I know this might get sticky when you’re highlighting code that is currently being edited or has been deleted but I trust the ingenuity that has got the project this far will prevail.
This would also help the tool to be even more beginner friendly and would bring it into line with many other types of visual editors that highlight the current content such as Blender, etc.
Yes, I understand that is the intended purpose of the log window but it’s really not that user friendly. Useful for debugging, true. I suppose with practice someone could master this for live performances.
The wall of text from a terminal is kind of a turnoff for a lot people when they think of coding. Text highlighting would make it a lot easier for beginners and experts alike.
It makes sense that this doesn’t really exist with other code editors as the code runs too fast so in the case of Sonic Pi it seems we have a unique opportunity to teach another aspect of coding: the step by step sequence of the code as it fires.
I think this could be quite confusing. If you have say 4 or 5 live_loops all running together, then each of them would have active code executing at the same time. Do you highlight them all?
I can see it might be of some use for a simple program with say one live_loop. However technically it would be difficult to implement as normally the buffer window in the gui and the ruby code do not communicate while a program is running once the run button is pushed unless the program stops and an error message is indicated. return info is displayed in the log file which is just added to sequentially. It would require major changes and I think would impinge on performance.
IIRC there was talk once upon a time about exploring having a currently executing line indicator, like an arrow in the sidebar or similar, as opposed to highlighting a line or a whole block etc. It was never fully discussed or realised however.
Edit: See eg. https://github.com/samaaron/sonic-pi/pull/554
@ethancrawford Yes this is the general idea. Whether an indicator or the line gets colored differently it’s telling you what part of the code is executing right now. It’s like a rolling breakpoint.
@robin.newman I don’t know if it would be too expensive or not. Maybe it can be turned on optionally. I don’t think it’s that difficult conceptually. The log function could be boosted to include the file and line number, then just feed that info back into the editor on the fly and strip it out for the log display. I’m not a Ruby expert but this would be relatively simple in Elixir. If the log was used you’d have a slight delay but better than nothing.
this is an idea we’ve been toying with for many years now but never really made it into any release.
In general I’m very interested in any new feature that communicates the execution of Sonic Pi visibly in addition to both the sounds and the logs.
However, this specific idea is an excellent example of something that’s easy to consider but much harder to execute. For example, you say that the log function could be boosted to include the file and line number. Is this the file and line number of the code that triggered the behaviour? What if the buffer was edited since then? What if the file and line number are of a user defined function which has since been deleted from the code, or is in a different buffer?
All these issues arise from the fact that the code running in memory is not of the same form as the code in syntax and there’s no hard bidirectional relationship that allows for this feature to be easily implemented.
If we were to move to something like Scratch where the syntax is visual to start with and have have the visual syntax be the actual data structure that the interpreter worked through, then this difference between syntax and executable program would be reduced.
Another option would be to have immutable versions of the code at the time the run button was pressed and have that be illuminated visually. However, we’re now talking about a considerable departure from the current GUI design. Not that I’m against this - but we’re really rather constrained on resources with me being the only dedicated “full-time” developer and most of that time is spent searching for and working for additional funds and helping the community. What little development time I do have is predominantly spent on ensuring Sonic Pi works on all platforms, fixing bugs etc. I hardly get any time to consider and work on new features at the moment.
So, all that said, if you fancy having a stab at an experimental implementation - I’m sure everyone here would cheer you on enthusiastically and we can see what might or might not work and figure out if a reliable, helpful feature can be shipped!
@samaaron Yes, agree on all points. First of all, thank you so much for this tool. It is wonderful.
I was thinking you may have the ‘executing window’ and the ‘editing window’ to solve the hot edit problem. This may even be more useful for debugging. For example, initially I had difficulty with the idea that it wasn’t enough that a live_loop is commented out, it has to be redefined, so it’s contents need commented out in order for the change to take effect.
This executing window would just be turned on or off and potentially floating like the others in the editor.
Also, because it’s not being edited, it presents other possibilities for display, like the text could be smaller, etc. It’s just display so it’s much simpler. You could even just run it out of a server and view it in a browser. Hmm… seems like a good use case for Elixir and LiveView.
i am sometimes surprised to see people who want always more and more features… slow down faster
maybe we have to learn to take a software as it is and use it with its defaults and its good points.
i dont know if you @GenericJam you code ? sometimes people don’t realize the work to get a feature done.
This is for tidal though - it’s a tiny bit easier for them due to functional pattern-focused design of the language. But even then, there are still visual glitches when the code changes.
Just looking at it, I think all of the potential inconsistencies are not a problem. Most of the time most of the code stays where it is. And when you need this feature the most, you can make sure to not change your code.
Of course, that still does not make this easy to implement.
Agreed - this is cool and Alex has done a lovely job. I believe Gibber also has some similar kind of visualisation mechanism.
As I mentioned earlier, I’m definitely in favour of features that expose the underlying execution semantics visually. I just don’t currently have the bandwidth to work on it right now
Not to step on anyone’s toes… I honestly dont see any worth or
point to this. SP as it stands is a more than acceptable editor.
Half the problem with software in the world is all the extra, non-
essential ‘whistles-and-bells’ that get included and which the
user has no need of.
Microst Office, esp. Word is a classic example. The vast majority
of its users never use its mail-merge function, but it is still included
in the core programme.
I’ve been missing a highlight current feature more and more, and now searching before I posted turns up this thread. I would find this feature highly desirable for all the reasons the OP said, and if the feature could be toggled, then the people who say they find no use in it wouldn’t be bothered. I also want to add how cool it would look to a live coding audience: while the log is impressively techno-geeky (as well as a necessary debugging tool), indicators of where we are would engage the audience somewhat beyond the neat visual of the logging blitz; I’m thinking of a follow the bouncing ball-type deal.
The discussion above indicates the programming task is more of a bear than it first appears. I would say that if the line numbers on the left (or some sort of area in the left margin) could highlight and un-highlight, that would go a long way toward being helpful while developing music code and also cool for an audience to follow and be mesmerized by. If there are ambiguities as to what constitutes the exact current location, then short circuit development by settling on a best choice, and who cares if this indicator is inexact or even flat out wrong in limited situations? It could get refined a bit over time via user feedback, or users could get used to its quirks, etc. In any case, I would say add reasonable indicators for all live loops simultaneously, or else much of the feature’s utility is lost. Still, if I were forced to designate just one loop as the loop-to-be-indicated, I’d use that all the time, too.
