overtone.libs.handlers

[Sam Aaron]

Hey everyone,

I just extracted the event handler lib from overtone into a new library cunningly called handlers. It's available here:

http://github.com/overtone/overtone.libs.handlers

I've modified Overtone to use it too. I pulled it out for my monome library, and you might find it useful for other things that require the ability to handle events both synchronously and asynchronously.

Sam

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

[James Petry]

That's a great idea, Sam. I've been experimenting with those handlers and jinput so I'll swap over to the new dependency now. Many thanks. 

[Iain Wood]

Hi Sam,

I just upgraded my copy of overtone from github overtone/overtone master and now I get an error when i try to use overtone.live

user> (use 'overtone.live)

Could not locate overtone/libs/handlers__init.class or
overtone/libs/handlers.clj on classpath:
[Thrown class java.io.FileNotFoundException]

I did a cake deps in my overtone directory and I can see libs.handlers-0.1.1.jar in overtone/lib. What might I have missed?

Iain

[Sam Aaron]

That's odd.

You won't find the handlers in overtone/lib any more, rather in the lib directory of your project root. Could you send me a listing of that dir?

Sam

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

[Iain Wood]

Sam,

My problem is almost certainly because I updated the source tree but not the version of overtone in the project.clj file. However I am still having problems. Now when I (use 'overtone.live) from the repl I get this:

No such var: at-at/print-schedule
[Thrown class java.lang.RuntimeException]

This is the listing of my project's lib dir:

riff: ls lib
at-at-1.0.0.jar libs.handlers-0.1.1.jar
byte-spec-0.3.1.jar midi-clj-0.3.0.jar
clj-glob-1.0.0.jar miglayout-3.7.3.1.jar
clojure-1.3.0.jar miglayout-3.7.4.jar
commons-net-3.0.1.jar osc-clj-0.7.1.jar
core.incubator-0.1.0.jar overtone-0.7.0-20120329.023005-8.jar
core.match-0.2.0-alpha6.jar scsynth-jna-0.1.2-20100502.112537-1.jar
data.json-0.1.2.jar seesaw-1.4.0.jar
deps.clj swingx-action-1.6.3.jar
forms-1.2.1.jar swingx-autocomplete-1.6.3.jar
j18n-1.0.0.jar swingx-common-1.6.3.jar
java-osc-cvs-20100502.112537-4.jar swingx-core-1.6.3.jar
jmdns-3.2.1.jar swingx-painters-1.6.3.jar
jna-3.2.4.jar swingx-plaf-1.6.3.jar
riff:

Iain

[James Petry]

On Thursday, March 29, 2012 4:17:08 PM UTC+1, Iain wrote:

My problem is almost certainly because I updated the source tree but not the version of overtone in the project.clj file. However I am still having problems. Now when I (use 'overtone.live) from the repl I get this:

No such var: at-at/print-schedule
  [Thrown class java.lang.RuntimeException]

overtone-0.7.0-20120329.023005-8.jar

I had this problem briefly, but the fix was in overtone-0.7.0-20120327.004212-7.jar which is older than you have. 

[James Petry]

In using this library, I'm putting a vector in as an event-name at the moment, and may be able to simplify that down to a Java object soon. It works great!

Is there any reason now or anticipated in the future for me not to do this?

[Sam Aaron]

Hi James,

I've been thinking a lot about events and handlers and the like of
late. I recently extracted the handlers library from Overtone so that
I could use it in my monome library. However, I've since really
rethought the way that handlers/events might work in Overtone in
general. These thoughts may or may not trickle down into the handlers
lib, but if they did, they might introduce some incompatibilities with
the way you're using things - so it's definitely good to have this
conversation now! :-)

One of the things that I'd like to see in Overtone is a move towards
unifying all of the event handling that happens. Currently there's
already a unification between incoming OSC messages from the server
and "system" events in that they are both piped into the event system.
Events currently take the form of either a string or a keyword -
although as you've discovered, any object can be used as the event
name.

I'd like to move towards having more things use this event system. So,
therefore monome or launchpad button presses would create Overtone
events, arbitrary OSC servers would pipe incoming OSC messages as
events, and MIDI controllers would also pipe incoming MIDI events as
Overtone events.

This would therefore have consequences to how we describe events and
how we handle them:

* Events 'names' should probably map onto OSC-like strings. This means
that they can be namespaced with / i.e. foo/bar or
overtone/midi/nanoKONTROL2 etc. It also makes mapping incoming OSC
messages trivial.
* Handlers should be able to register interest for an event subtree.
For example, it might be useful to register interest with /* (i.e. all
events) or /overtone/midi/* (i.e. all MIDI events).

Dealing with the first consequence could easily be done in a way that
is compatible with your usage of the library. However, it's not
immediately obvious to me how we might allow for the second
consequence in a compatible manner.

Do you have any thoughts?

Sam

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

[James Petry]

Hi Sam,

> I'd like to move towards having more things use this event system. So,

> therefore monome or launchpad button presses would create Overtone

> events, arbitrary OSC servers would pipe incoming OSC messages as

> events, and MIDI controllers would also pipe incoming MIDI events as

> Overtone events.

Yes, unifying at this level makes a huge amount of sense.

As a concrete goal, I was wondering about hooking up several gadgets

at once and this would simplify that. I could muster TouchOSC on a phone,

a gamepad, a joystick, a USB MIDI DJ controller and a MIDI-OUT keyboard.

> This would therefore have consequences to how we describe events and

> how we handle them:

> 

> * Events 'names' should probably map onto OSC-like strings. This means

> that they can be namespaced with / i.e. foo/bar or

> overtone/midi/nanoKONTROL2 etc. It also makes mapping incoming OSC

> messages trivial.

> * Handlers should be able to register interest for an event subtree.

> For example, it might be useful to register interest with /* (i.e. all

> events) or /overtone/midi/* (i.e. all MIDI events).

So, specifying paths to nodes and selecting nodesets in an events tree?

That reminds me of XPath. Which is great, I've done a lot of work

with XSLT/XPath.

However, it is still a text-based representation of a structured 

item and I wonder if clojure can express this more usefully? In a small

way, that's why I moved to using a vector as an event-name.

Showing my inexperience with clojure here, is there already something

in the area of XPath/tree-handling/zippers that could be useful?

[Sam Aaron]

Hi James

On 5 April 2012 09:28, James Petry <gavila...@gmail.com> wrote:
>
> However, it is still a text-based representation of a structured
> item and I wonder if clojure can express this more usefully? In a small
> way, that's why I moved to using a vector as an event-name.

I totally agree with you. Jeff and I were chatting about this
yesterday and he also suggested preferring Clojure data structures
over strings. So, we were to use vectors of keywords for event names -
would that conflict with your usage?

Sam

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

[James]

Sam,

Hi.

On 6 April 2012 14:17, Sam Aaron <sama...@gmail.com> wrote:
>> However, it is still a text-based representation of a structured
>> item and I wonder if clojure can express this more usefully?
>

> I totally agree with you. Jeff and I were chatting about this
> yesterday and he also suggested preferring Clojure data structures
> over strings. So, we were to use vectors of keywords for event names -
> would that conflict with your usage?

My usage is easy to change, no worries :-)

I have a function that takes a Controller object and
a Component object from JInput and returns the event name.

The first version returned an OSC-like string, currently it just puts
them both in vector.

As JInput seems consist in returning the same object for each
component, I have been
pondering eliminating the Controller from being tracked.

It makes more sense to keep it in there though for building a
tree-type event space across
all the different device types.

[Jeff Rose]

Yeah, I think a vector of keywords would be ideal. That way we can use core.match to do tree based event handling, while binding to child elements.

-Jeff

On Saturday, April 7, 2012 at 3:45 PM, James wrote:

> Sam,
>
> Hi.

[James Petry]

Hi Sam,

While I revive and update the jinput stuff, I've been looking at overtone.libs.handlers and overtone.libs.event.

It looks like the actual code in  [overtone/libs.handlers "0.2.0"] is newer than the github project. Have I missed 

a fork or branch?

Best Wishes,

James

[Sam Aaron]

Hi James,

I'm not sure what's different. The only thing I could find is that I forgot to commit the change in project.clj which removed -SNAPSHOT from the version. That's pushed now.

Let me know if I can help any further,

Sam

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

[James Petry]

On Thursday, June 28, 2012 10:18:17 AM UTC+1, Sam Aaron wrote:

I'm not sure what's different. The only thing I could find is that I forgot to commit the change in project.clj which removed -SNAPSHOT from the version. That's pushed now.

Thanks, Sam. I can now see add-handler! and the emh functions in github.

Excellent!

James