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.
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.
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.
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
This may not be feasible at all, just my 2c @samaaron
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.
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 -
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
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?
'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…
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.
@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
