Loading Ruby gems for use within a Sonic Pi buffer

I’m trying to figure out how to load a Ruby gem for use within a Sonic Pi buffer. Has anyone tried doing this?

I found this related thread from 2015: https://groups.google.com/forum/#!msg/sonic-pi/QgX82sXcHqY/wNpxGLhggmUJ

I’m interested to hear your thoughts on that discussion. Here are mine: I get that Sonic Pi != Ruby, but I love that I can use plain old Ruby objects in Sonic Pi and it’d be really cool to know how to package them up and share them. Ruby gems come to mind.

One of the projects I’m working on uses a genetic algorithm to “evolve” music. I published a gem for working with genetic algorithms and have been using it alongside the sonic-pi-cli Ruby gem. I’m getting some pretty cool results and would like to be able to load “population” objects from the gem within a Sonic Pi buffer and live code with them.

If there’s no support for loading Ruby gems into the Sonic Pi buffer environment, I suppose I can put all my code in one file and require it - I’m pretty sure this would work. Then to share, I guess i could create a rake task to do it, so for anyone to use it they’d have to do something like the following:

gem install evolvable; rake compile_sonic_pi_file

but ideally I could skip the rake command and just do something like this in the Sonic Pi buffer:

require ‘path/to/gem’

Apologies - but using generic Ruby gems isn’t supported and likely never will.

I have quite strong plans already to move away from Ruby for a future version of Sonic Pi (although keeping things as similar as possible to how they currently are).

2 Likes

Ah, okay. I won’t waste any time on this then! It’s probably an unusual use case, I was just thinking it’d be pretty cool to live code with some of the custom abstractions I’m working on. My main project is just using Ruby objects to basically compose Sonic Pi code, so not having this support won’t pose any problems for that. I’m also currently going through the tutorial and having a ton of fun with it. Sonic Pi is awesome, thanks!

1 Like

Can you enumerate what you consider the pros and cons of ruby are and what alternatives you are considering? Are you considering a new language or an alternative existing language?

1 Like

How about gems specifically written to be used in sonic-pi? I have a Novation Launchpad X that I’ve been able to get initial support for a step sequencer. The code is getting a little messy, so I’m hoping to package up some of it as a gem with some refactoring.

1 Like

Hello.

I understand why Ruby Gem can’t be used, but possible to add MessagePack gem in future release. It looks available on many languages. I can see MultiJson, but it’s slow (Ruby-based Benchmark of MessagePack vs. JSON vs. Yajl vs. Protobuffers vs. MultiJson vs. Marshal vs. YAML vs. BSON · GitHub). I don’t know if good practice, I use JSON in OSC message from Python and if MessagePack is faster than JSON, maybe I can reduce delay between received OSC message and action to do.

@athlon64 what kind of delays are you noticing?

For now, none, I don’t use big JSON because my project begins (pattern/step sequencer part done, control FXs/options to do and I hope to control them by OSC messages with JSON, short time to unserialize if high BPM for example).
But, I wonder if you can put MultiJSON, it’s maybe possible to add MessagePack. When I see unserialize performances, I imagine it can help unserialize on Rpi if somebody wanna use a large JSON (to bench). MessagePack is available on many languages, it lets choice for developers.
And theses two formats are not proper to Ruby, so, when you could change, theses formats can be kept.

If it’s a big task to add this gem, I understand. Just see my message like a suggestion to have different format to communicate.

(Sorry for English level :sweat_smile:, I hope it’s clear)

If there’s no current latency issue, then I don’t think there’s a problem.

In general, I’m against adding new code into the codebase unless it really is necessary. All new code becomes a maintenance burden which takes lots of time and energy - so we really should be removing code wherever possible rather than adding it.

I see. I continue my project and if I have some problems, I will come back then.

I don’t know how you added MultiJSON, I though it’s just a dependency without a lot of code behind.

Thanks you for fast reply

1 Like

so we really should be removing code
wherever possible rather than adding it.

AMEN …