How about a Sonic Monome?


#1

This is possibly/probably not an original thought, but it seems to me that a ‘Sonic Monome’ might offer a lot of potential

https://monome.org/

I notice the Monome is scriptable -

https://monome.org/docs/grid-studies/python/

that is, you can attach scripts to different buttons.

Seems to me we could have an (optional) grid interface to SP, with the ability to attach live_loop functions to each button, maybe via some kind of edit action. Since each button has a bound live_loop, they could all be synchronised.

Mixing different live_loops would become a lot easier, and potentially replace all the different ad hoc ways people are currently using to mix their different creations. What percentage of people’s SP code today is actually mixing code versus sound creation code ? It feels like there is some kind of ‘common mixing abstraction’ here waiting to get out.

Could be extremely powerful now SP has MIDI baked in.

Thoughts @samaaron ?


#2

Haha!

I bought one of the very first monomes when they came out. It was the monome that got me into computer music in the first place.

I am actually working right now on a grid interface for Sonic Pi (I briefly mentioned this in my Patreon update) and will make it work perfectly with the monome (and other grid devices such as the Novation Launchpad).

monome embraced OSC from the start, so Sonic Pi can already talk to them natively. However there’s definitely some advantages to be had with having a nice Sonic Pi API and also having a GUI version so people don’t need to buy external hardware to play.

Watch this space!


#3

Is a really nice idea. Looking forward to it. Are u planning to bind live_loop to buttons as I imagined or something different ? I think this could be a real game- changer for SP.


#4

Could you expand what you mean by “binding live_loop to buttons”? Perhaps with some code examples?


#5

Oh crikey I dunno.

I was looking at the Monome Python stuff and it seemed as if you could bind individual functions to individual buttons. I was thinking about that in the SP context and the natural ‘unit’ to bind to a Monome button seemed to be an SP live_loop function. So maybe you are faced with a grid of buttons in the UI; you want to bind a function to one; you somehow click to edit the button (instead of pressing it to execute), and maybe the button expands into a small editing window (for that button only). You add a snippet of code, click return and the edit window disappears to be replaced by the button again. That button is now ‘bound’ to a particular live_loop. Do this for multiple buttons and you have multiple live_loops bound to different buttons. Button state (on/off) determines whether a particular live_loop is being played at any point, just the way a Monome would work. Since all the bound code is live_loops, presumably it can all be synchronised.

Incidentally this ‘click to edit’ functionality is very similar to how the IPython Notebook (Project Jupyter) works. Obv the context is very different (data science vs music) but the method of interaction is very similar - a collection of linked units (cells in this case, not buttons) which expand to be ‘edited’ when clicked, and return to ‘execution’ model when done. Is also not dis- similar to how an Excel grid works. And love it or hate it, everyone is familiar with Excel :slight_smile:

This may not be feasible at all, just my 2c @samaaron


#6

I think you should already be able to achieve this using a sync at the top of each live_loop.

The only issue is that we don’t yet have any pattern matching on the OSC arguments, so you’d have to add some logic to say if the x value is 3 and y is 5 then do something specific.


#7

You mean if I have a Monome (I don’t) ?

thinks

Tempted to buy one now :slight_smile:


#8

Sure, but a monome just sends OSC messages - so you can emulate a monome by calling cue :slight_smile:


#9

I think we’re talking about approximately the same idea but your thoughts are likely much more advanced. What’s the ETA on the SP grid interface ? Looking forward -


#10

I’m hoping to get a BETA release with a grid interface within the next month or so which I’ll share with Patreon supporters :slight_smile:


#11

Here’s a very early glimpse:


#12

Like it. But why relegate it to a small lower RHS window ? Why not have it as a tab to the main scripting window ? More buttons!


#13

It’s a very early glimpse - not even a finished prototype. Many things are likely to change including the chance it won’t make it into a future release at all :slight_smile:


#14

@juzbo is there any chance you could share a drawing or two of how you imagine a grid interface to look and feel :slight_smile:


#15

If it had it’s own tab, you couldn’t use it very easily when live-coding?

You’d have to select the tab, then trigger the effect (by hand or mouse),
then switch back to your coding tab… or do you envisage binding effect-keys
to the function keys or something?

Also… 64 (8x8) should be plenty? LESS buttons (=bigger buttons)!!

How about 6x6, or even 4x4… which would still give 16 triggerable events.

Its really just a nice little add-on to SPi, a different way of performing…
but the focus should still remain on the code?

Eli…


#16

light-bulb-moment

Why not make the button grid user-definable…

Lets specify a 4x 4 grid…

'Make me a button at location 2,3 in the grid. Its title should be: ‘Snare’, and it should inject the cue Do_Snare, it should be a 1-shot button… not an on-off toggle… or conversely you could put a small block of code into the button instead of a cue, to be run when the button is pressed…

make_button 2 3,title: Snare, toggle: 0/1, cue: Do_Snare, block: {small block of code}, on_colour: white, off_colour: pink

If the button accepted code, you could put something like:

{if effect < 10 then; effect+=1; } to make an effects control etc…

If make_button was allowed in buffers, you could change the button text/colour on the fly to indicate the
current effect… or the next one if pressed…

make_hori_bar: … a 2-wide or 4-wide version of make_button…

make_vert_bar… a vertical 2-slot or 4-slot version of make_button…

Put it at the start of a buffer to initialise it before the tune runs, and also make it
unique to that song/track/buffer… but have a default pad in .ini or whatever starts SPi
these days.

Yeah… I’m pipe-dreamin… Sam would have to do the hard work. :slight_smile:

Eli…


#17

On the topic of launchpads:

I have an Akai MPK Mini at home, with a few buttons that can be used as a launchpad.
I’ve been able to use it as a drumpad: https://github.com/korfuri/tasty-pies/blob/master/tech/poc_midi_drumpad.txt

And in a somewhat more advanced way: https://github.com/korfuri/tasty-pies/blob/master/tech/poc_midi_drumtrack.txt which enables/disables select tracks or instruments.

I also wrote a few notes at https://github.com/korfuri/tasty-pies/blob/master/articles/Android_Drum_Pad_Sonic_Pi.md on using a free Android app as my drumpad.


#18

@samaaron this is a dreadful cop- out but I don’t feel any ideas I have are fully formed enough at this stage. I have ideas based on how the IPython Notebook works but not sure they are workable in this context, also it seems you have thought about it a lot as SP already has Monome support. Suggest u implement v1.0 and maybe I can provide some feedback. Sorry can’t really be more helpful on this one


#19

Sam, are you bringing the good old MLRV style sampling back into Sonic-Pi … ?


#20

MLRV is definitely one of the monome apps I’m looking to be able to easily replicate :slight_smile: