Internal Sequencer + Screencast

[Sam Aaron]

Hey there,

I've been playing around moving sequencer logic into SuperCollider rather in Clojure (which is the typical place for it). This has a couple of key advantages:

* The metronome rate is trivially modulated
* The metronome can be used as a control signal to arbitrary synths

I've committed an example here:

https://github.com/overtone/overtone/blob/6273f5dde8e632d416ce4a5f9270eae294919d0a/src/overtone/examples/timing/internal_sequencer.clj

Also, I've uploaded a screencast of me briefly explaining the example and messing around with it:

https://vimeo.com/47578617

Let me know what you think,

Sam

---
http://sam.aaron.name

[Iain Wood]

That's beautiful Sam!
I will maybe comment on the code when I have had chance to scrutinise it, meanwhile the sound you are getting is great.

Iain

[Sam Aaron]

On 15 Aug 2012, at 13:11, Iain Wood <ia...@soulflyer.co.uk> wrote:

> That's beautiful Sam!

Thanks :-)

> I will maybe comment on the code when I have had chance to scrutinise it, meanwhile the sound you are getting is great.

Please do. I wrote this up as an example in order to let people get it running and play with it on their own - and we can use it to further our understanding of these things together :-)

Sam

---
http://sam.aaron.name

[Iain Wood]

On 15 Aug 2012, at 19:30, Sam Aaron wrote:

I will maybe comment on the code when I have had chance to scrutinise it, meanwhile the sound you are getting is great.

Please do. I wrote this up as an example in order to let people get it running and play with it on their own - and we can use it to further our understanding of these things together :-)

I'm thinking his makes the current metronome function pretty much redundant. It should also make implementing a metronome that is aware of bars a lot simpler. I'm both sad and pleased about that. My version of metronome (https://github.com/soulflyer/overtone/tree/recover) is working with the current version of overtone now and just needs testing a bit more before its ready for a pull request. I'm inclined to skip that and get started straight away on another version using this new technique. What pleases me is I believe it will be a much neater and more elegant solution. 

Iain

[Sam Aaron]

On 15 Aug 2012, at 18:02, Iain Wood <ia...@soulflyer.co.uk> wrote:

>
> I'm thinking his makes the current metronome function pretty much redundant. It should also make implementing a metronome that is aware of bars a lot simpler. I'm both sad and pleased about that. My version of metronome (https://github.com/soulflyer/overtone/tree/recover) is working with the current version of overtone now and just needs testing a bit more before its ready for a pull request. I'm inclined to skip that and get started straight away on another version using this new technique. What pleases me is I believe it will be a much neater and more elegant solution.

This is my hunch too - not to knock the excellent work that's gone into (and continues to go into) the metronome.

I think the internal sequencer approach represents a very interesting direction - one which I'm planning on heading down. I wouldn't want to discourage others from hacking with the current metronome though - I think it's still very valuable work.

Sam

---
http://sam.aaron.name

[Kevin Neaton]

I'm also very excited about using synth based clocks/metronomes. In a group hacking situation, this could allow a number of Overtone clients connected to the same scsynth server to access the same metronome and actually play in time together. As much as I enjoy hacking on my own, I'd like to see more support for multiple Overtone clients hacking on the same scsynth server down the road. Having a synth based metronome would be a good step in that direction :)

Kevin

[Sam Aaron]

On 16 Aug 2012, at 02:17, Kevin Neaton <nea...@gmail.com> wrote:

> I'm also very excited about using synth based clocks/metronomes. In a group hacking situation, this could allow a number of Overtone clients connected to the same scsynth server to access the same metronome and actually play in time together. As much as I enjoy hacking on my own, I'd like to see more support for multiple Overtone clients hacking on the same scsynth server down the road. Having a synth based metronome would be a good step in that direction :)

At the moment, it's totally possible for multiple users to connect to the same JVM process and use that to collaborate. This allows you to use the traditional metronome as well as this new approach as well as sharing the event stream and coordinate through other Clojure structures.

I'm not entirely convinced that having multiple Overtone clients connected to the same scsynth server buys you, over multiple users connected to the same Overtone process. However, I wouldn't want to stop people experimenting! What would need to happen would be for someone to create a coordinated, distributed id allocation mechanism perhaps using something like Avout - so that multiple clients don't try and bash on the same ids.

Sam

---
http://sam.aaron.name

[Chris Jenkins]

Hi,

At the moment, it's totally possible for multiple users to connect to the same JVM process and use that to collaborate. This allows you to use the traditional metronome as well as this new approach as well as sharing the event stream and coordinate through other Clojure structures.

That's what we did in the Clojure Dojo at Forward last night. Jen did a slime-connect to my swank server and played samples while I played around with the dubstep bass. It was surprisingly awesome :-) I need to write up what we did but it was pretty simple to get working once we got past a few hiccups.

Cheers,

Chris

[Sam Aaron]

On 16 Aug 2012, at 10:17, Chris Jenkins <cdpje...@gmail.com> wrote:

> I need to write up what we did but it was pretty simple to get working once we got past a few hiccups.
>

Awesome - I look forward to the write-up :-)

Sam

---
http://sam.aaron.name

[Kevin Neaton]

What would need to happen would be for someone to create a coordinated, distributed id allocation mechanism perhaps using something like Avout - so that multiple clients don't try and bash on the same ids.

My thoughts exactly.

I'm not entirely convinced that having multiple Overtone clients connected to the same scsynth server buys you, over multiple users connected to the same Overtone process.

Connecting to a shared Overtone process have some advantages... 

• It's really easy to do with swank/slime-connect.
• Only one person needs to have Overtone installed.
• You can share a single namespace and manipulate shared state in Clojure.

However, sharing a swank server has some security problems. Every client that connects has the full power of the JVM, so they can download/upload files, delete files, run a shell command, etc. That's a lot of power to give someone and there is no authentication required to connect. We'll need a better way to do this at some point.

Connecting to a shared scsynth would have some advantages too...

• Secure... it's just osc.
• Multiple points of failure. If one JVM dies, the show can still go on.
• Each client can use their own version of Overtone or even run a customized version.
• Possibly other scsynth clients in other languages could be used together?
• Secure enough to be used over the internet?

However, I wouldn't want to stop people experimenting!

At some point I hope to experiment with this, but for now I just wanted to put the idea out there.

--Kevin

[Sam Aaron]

Bringing the thread back to the original discussion...

who out there has tried playing around with the new internal sequencer example and made some noise with it? It would be great to get some experience reports...

Sam

---
http://sam.aaron.name

[Bruce Durling]

Sam,

On Thu, Aug 16, 2012 at 3:00 PM, Sam Aaron <sama...@gmail.com> wrote:
> Bringing the thread back to the original discussion...
>
> who out there has tried playing around with the new internal sequencer example and made some noise with it? It would be great to get some experience reports...

I had a go last night at the London Clojure Dojo (our new midmonth dojo)

It was so simple to get something together that allowed me to perform
and tweak my performance. I still feel that there are loads of things
I don't understand, but even the example allowed me to be a 5 minute
rock star in the "here's a guitar and three chords - now form a band"
kind of way.

Great fun. Thanks!

cheers,
Bruce
--
@otfrom | CTO & co-founder @MastodonC | mastodonc.com

[Sam Aaron]

On 16 Aug 2012, at 15:04, Bruce Durling <b...@otfrom.com> wrote:

> It was so simple to get something together that allowed me to perform
> and tweak my performance. I still feel that there are loads of things
> I don't understand, but even the example allowed me to be a 5 minute
> rock star in the "here's a guitar and three chords - now form a band"
> kind of way.

That's the Clojurepunk way! :-)

Awesome stuff!

Sam

---
http://sam.aaron.name

[Iain Wood]

On 16 Aug 2012, at 21:00, Sam Aaron wrote:

> Bringing the thread back to the original discussion...
>
> who out there has tried playing around with the new internal sequencer example and made some noise with it? It would be great to get some experience reports...
>
> Sam
>

I had a play with the code you used for your screencast and made some cool noises, but not had time to extend on it yet

Iain

[Roger Allen]

Hi Sam,

I tried it out with 0.7.1 and the beats seem very far off.  Do I have to build Overtone from the latest git source to get this running?  Or is there something wrong on my end? 

I just followed your link at the top & loading it into clojure, when I enabled the "empty palatte to play with", it was just "buzzing" for lack of a better term.  Simplifying it to 

(do

  (buffer-write! buf-0 [1 0 0 0 0 0 0 0])  ;; kick

  (buffer-write! buf-1 [0 0 0 0 0 0 0 0])  ;; click

  (buffer-write! buf-2 [0 0 0 0 0 0 0 0])  ;; boom

  (buffer-write! buf-3 [0 0 0 0 0 0 0 0])) ;; subby

and adjusting the rate waaay down

(ctl r-trg :rate 1)

I hear the kick at 1 beat per second which is very different than the video.

I will say this is a great way to show off Overtone.  10 minute videos with accompanying well-documented code rocks!

--Roger

[Roger Allen]

The answer appears to be, yes, you need 0.8.0-SNAPSHOT.  Finally took some time to figure out the lein checkouts feature & things sound like Sam's demo.  

Thanks again for doing this!

--Roger

[Sam Birkhead]

I started something of over at https://github.com/samBiotic/zosc for osc routing and scheduling

Planning unicast with mdns discovery and forward synchronization of hardware clocks

Hack away.

[Sam Aaron]

On 16 Aug 2012, at 16:55, Roger Allen <ral...@gmail.com> wrote:

> The answer appears to be, yes, you need 0.8.0-SNAPSHOT. Finally took some time to figure out the lein checkouts feature & things sound like Sam's demo.
>

Actually, you need the latest checkout from Github for it to work exactly as it should. The 0.8.0-SNAPSHOT it a little behind. I used to use cake to deploy new snapshots to Clojars, but it seems to have stopped working with Mountain Lion. I'll push another jar when I've given myself the time to figure out how to do it with lein.

> Thanks again for doing this!

You're very welcome - thanks for spending the time to look into it :-)

Sam

---
http://sam.aaron.name

[Roger Allen]

Sorry for yet-another-tangent, but it is tough to know how to refer to the 0.8.0-SNAPSHOT that you build yourself & the 0.8.0-SNAPSHOT that you download via lein.  I can't help but think that if there was some naming difference, it might be more clear.  Apparently, since it makes a difference, I must've gotten my local build to work properly--but who knows, maybe the 0.8.0-SNAPSHOT is actually being downloaded via lein and accidentally working...  

In any event, trying out the mysterious "lein checkouts" feature has been on my to-do list for a while and this finally gave me the motivation to give it a go.

--Roger