Extending Sonic Pi would be nice and is certainly on the TODO list.
However, we already have a pretty powerful approach which is just to define a bunch of functions and throw them into a file which you can load. OK, they’re not namespaced, but Emacs has managed for a good few years with this approach just fine, so it’s not a massive blocker.
Currently my effort is 100% focussed on improving boot stability/compatibility and raising enough money to keep going.
I also don’t think that classes and objects are the right fit for Sonic Pi’s abstractions. Happy to be convinced otherwise, but currently I think namespaced functions are likely the way forward. There’s also the more interesting angle of considering how timelines of diffs (i.e. live code changes) should be managed. Objects and classes are timeless and Sonic Pi is all about time
I’m always coming across developers who want systems to be re-engineered to fit their favourite and beautiful paradigm. Also developers who want everything to be fully documented but then…ahem…are reluctant to read it and even more reluctant to document it themselves C’mon you know it’s true.
It’s always difficult to argue against OO because it is everywhere, but honestly I’ve seen some howlers over the years. It’s not the magic bullet.
Would having OO in SPi allow me to make music that I can’t do with existing system? No. However, there are some real practical issues around running it that I would much rather see addressed first. With limited resource, you’ve got to decide where to put the effort.
I’ve come up against some issues around the “is it or isn’t it Ruby?” question too. Never mind.
On the educational side - there’s loads of resources for children to learn about OO. But how many to learn about threads? If you want a high-concept thing they won’t get anywhere else, have a look at that.
For at least Ruby, this is at least true. However, the time that you’re referring to is extremely hard to manage and coordinate. The creation, destruction and lifetimes of a single object are not the same for each execution of a given program on every device. This is before you try and consider multiple objects.
One of the key goals of Sonic Pi is deterministic execution. This means that the same code should always produce the same sounds - regardless of when it was executed and on which machine.
In my opinion we need to be working with time-series immutable data (which also includes functions) with the creation of new information always being atomic from a world perspective. Old values should still be available for as long as necessary. Take a look at time series data stores or something like Datomic to see where we’re headed here
Right on! As I understand it, a lot of the Internet runs on projects that started life or continue as one-person or small team projects. It’s about individual vision. Some of the design choices can look unorthodox if you imagine starting from scratch. But that’s not how these things get developed. The Internet itself is the classic example - a right royal rag bag. (not saying SPi is a rag bag btw )
@Buce/@pete:
It’s not quite as simple as “Create your classes in SuperCollider” unfortunately.
The screenshot that Pete is showing here is the tooltip description of one of Sonic Pi’s preference settings, a checkbox labelled ‘Enable external synths/FX’. This setting turns on or off the ability to use ‘custom’ or ‘external’ synths and fx built for Sonic Pi that are not bundled with the program. (So, with this checked ‘on’, we can do something like this:
There is one important thing to note about what Pete is saying. Yes, you can create custom synths and fx in SuperCollider, because they are eventually compiled into binary files that are executed directly on SuperCollider’s sound engine, scsynth.
However, for other SuperCollider code such as that used for control flow, organisation etc, this type of code is not run on SuperCollider’s sound engine/server, but rather interpreted by their language run-time, sclang. Sonic Pi currently has no interface with sclang.
Adding such an interface to the SuperCollider language run-time into Sonic Pi would definitely open up a bunch of capabilities. For certain use cases, we are definitely interested in this - however, it again comes down to a question of priorities vs resources.
Well, two things that immediately come to mind are that it would allow us to 1) define and compile new SuperCollider synths directly from Sonic Pi, and 2) streamline handling of synth metadata (such as opt validation limits etc) by storing these details directly in the SynthDefs themselves.
The ‘syntax definition’ is what you see in the Help documentation, in the ‘Lang’ area.
and
Using custom classes is not possible using the officially supported Sonic Pi syntax. Such a thing is potentially doable using vanilla Ruby syntax, which Sonic Pi’s API is built on, but there is no guarantee that if it works, it would continue to work in future versions.
I have never read, used or learned Ruby, but I have skimmed the Ruby introductory tutorial. Having gone through it I understand that constructs like hash and 10.times are pure Ruby. As is also
MAIN = self
class ExtSynth
def play
MAIN.midi :C1, sustain: 4, port: "moog_matriarch_36", channel: 1
end
end
extSynth = ExtSynth.new()
However, using the class construct is discouraged but other constructs are extensively used in the documentation. Where can I read where the exact border between SP and Ruby is? E.g. when I saw 10.times the first time, I wondered what else can I do to 10 in SP. But I could not find any easy way to find that in the documentation. Going to the Ruby documentation, I saw that I could tease it with actions like .pred, .next, to_s, .even and a lot more. Some of them I tested in SP, and they work fine, others not. Likewise, what actions may a list carry out? To find out I had to go to Ruby again. E.g. I can successfully do a .push in SP. But I cannot find neither .push nor .each in the SP lang documentation, other than in examples and the tutorials (at least .each).
I want to write gists and personal files with often used code that survive the future of SP. But I experience that it is very difficult to find out for sure whether I am on safe ground or not.
C’mon you know it’s true.
)
