midi-handle-events versus on-event

[Mikkel Gravgaard]

I cannot seem to get (midi-handle-events some-device '#some-fn) to work. (It worked fine in 0.7.0 on Lion, but doesn't on MtLion).

According to https://groups.google.com/forum/?fromgroups#!topic/overtone/d0x91fJg06I%5B1-25%5D I should use on-event instead, which kinda works. 

But I cannot find out how to specify the event-type. Currently, it seems to be triggered on every event, including those that I send out with midi-note-on, which causes an infinite loop. How do I get it to only trigger on some specific device?

[Sam Aaron]

Hi Mikkel,

On 14 Aug 2012, at 12:50, Mikkel Gravgaard <mik...@gmail.com> wrote:

> I cannot seem to get (midi-handle-events some-device '#some-fn) to work. (It worked fine in 0.7.0 on Lion, but doesn't on MtLion).
>
> According to https://groups.google.com/forum/?fromgroups#!topic/overtone/d0x91fJg06I%5B1-25%5D I should use on-event instead, which kinda works.

What, specifically, do you mean by "kinda works"? :-) Also, is it fair to assume that you're working with the latest version of 0.8-dev from Github?

You're correct though, using the event system is now the preferred way of handling MIDI.

>
> But I cannot find out how to specify the event-type. Currently, it seems to be triggered on every event, including those that I send out with midi-note-on, which causes an infinite loop. How do I get it to only trigger on some specific device?

What are you trying to achieve? If you let us know, then we can probably help you more effectively.

In the meantime, in order to see which events are being fired, you can turn on event debugging:

(event-debug-on)

Then hit your keyboard, observe the events, then when you've found the correct event-key, turn off debugging with:

(event-debug-off)

Another approach, is to ask the event system to record the keys its sees over a short period of time. This can be achieved with:

(event-monitor-timer)

Which, by default, records the event keys it sees in the next 5 seconds. So bash away at one of the keyboard keys...

Then, when the timer has finished, you can observe the keys it saw with:

(event-monitor-keys)

With my Korg NanoKEY2 I see the following event-keys: (You should rebase to the latest master to see the same as this)

([:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-off]
(:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-off 49)
[:midi :note-off]
[:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-on]
(:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-on 49)
[:midi :note-on])

So, assuming the following super simple synth exists:

(definst beep [note 40] (* (env-gen (perc 0.1 0.1) :action FREE) (sin-osc (midicps note))))

(on-event
[:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-on]
(fn [msg]
(beep (:note msg)))
::play-beep)

Should allow you to play the beeps with the keyboard...

Sam

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

[Mikkel Gravgaard]

Hi Sam and others,

I got it to work now by specifying the device in the event-type, ie:

(on-event [:midi-device "Novation" "Port 1" "SL MkII Port 1" :note-on]
(do-something [e])
::my-event-handler)

I already tried debugging the events but had a hard time deciding what
should go in the event-type. Your example helped a lot :-)

What I am trying to achieve is to simply redirect a note-on from one
device to another. What I /think/ happened before is that my
event-handler was triggered by my own re-sending of the midi-event,
which in turn caused a loop of events. By filtering on the device, I
should be able to correctly trigger the event only when I hammer away
on the keyboard.

Last time I hacked on Overtone, I was actually running on a snapshot
of 0.7.0. It seems the midi-handle-events problem I had, was
introduced with the final 0.7.0 and is still a problem with 0.7.1. The
midi-handle-events function still works for me with 0.6.0.

Thanks again for the quick answer. I might be back :-)

-Mikkel

[Sam Aaron]

On 14 Aug 2012, at 13:43, Mikkel Gravgaard <mik...@gmail.com> wrote:

> I got it to work now by specifying the device in the event-type, ie:
>
> (on-event [:midi-device "Novation" "Port 1" "SL MkII Port 1" :note-on]
> (do-something [e])
> ::my-event-handler)

Great, glad you got it working :-)

>
> I already tried debugging the events but had a hard time deciding what
> should go in the event-type. Your example helped a lot :-)

Super. The event-key is simply a unique key for a given event whereby unique is defined in terms of the JVM equality semantics - i.e. you can use any JVM object as a key. We're moving towards vectors of keywords because they're nice and readable.

> What I am trying to achieve is to simply redirect a note-on from one
> device to another. What I /think/ happened before is that my
> event-handler was triggered by my own re-sending of the midi-event,
> which in turn caused a loop of events. By filtering on the device, I
> should be able to correctly trigger the event only when I hammer away
> on the keyboard.

Interesting - I'd love to see what you finally end up with.

> Last time I hacked on Overtone, I was actually running on a snapshot
> of 0.7.0. It seems the midi-handle-events problem I had, was
> introduced with the final 0.7.0 and is still a problem with 0.7.1. The
> midi-handle-events function still works for me with 0.6.0.
>

If you let me know what worked with 0.6.0, what you expected to happen, and then a description of what happens with the latest Overtone and why that's incorrect, I can look into fixing it...

Sam

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

[Mikkel Gravgaard]

Btw. here's a log from the (event-debug-on). For me, it wasn't obvious what should go into the event-type, since the three strings defining the device in the second event are not quoted. Additionally, there are two events shown for each note-on. I'm not sure why?

my-namespace> (event-debug-on)

event:  [:midi :note-on]   ({:status :note-on, :note 52, :timestamp 514482155292, :velocity 49, :data1 52, :msg #<FastShortMessage com.sun.media.sound.FastShortMessage@1f549dc1>, :device {:transmitter #<MidiInTransmitter com.sun.media.sound.MidiInDevice$MidiInTransmitter@1ddb404e>, :name Port 1, :description SL MkII Port 1, :vendor Novation, :version Unknown version, :sources 2147483647, :sinks 0, :info #<MidiInDeviceInfo Port 1>, :device #<MidiInDevice com.sun.media.sound.MidiInDevice@7a29a59a>}, :channel 0, :command :note-on, :data2 49}) 

event:  [:midi-device Novation Port 1 SL MkII Port 1 :note-on]   ({:status :note-on, :note 52, :timestamp 514482155292, :velocity 49, :data1 52, :msg #<FastShortMessage com.sun.media.sound.FastShortMessage@1f549dc1>, :device {:transmitter #<MidiInTransmitter com.sun.media.sound.MidiInDevice$MidiInTransmitter@1ddb404e>, :name Port 1, :description SL MkII Port 1, :vendor Novation, :version Unknown version, :sources 2147483647, :sinks 0, :info #<MidiInDeviceInfo Port 1>, :device #<MidiInDevice com.sun.media.sound.MidiInDevice@7a29a59a>}, :channel 0, :command :note-on, :data2 49}) 

[Sam Aaron]

On 14 Aug 2012, at 13:50, Mikkel Gravgaard <mik...@gmail.com> wrote:

> Btw. here's a log from the (event-debug-on). For me, it wasn't obvious what should go into the event-type, since the three strings defining the device in the second event are not quoted.

They're not quoted because they're printed out with pprint which doesn't play nicely with these things. This is why I suggested to use the event monitor system instead:

---

Another approach, is to ask the event system to record the keys its sees over a short period of time. This can be achieved with:

(event-monitor-timer)

Which, by default, records the event keys it sees in the next 5 seconds. So bash away at one of the keyboard keys...

Then, when the timer has finished, you can observe the keys it saw with:

(event-monitor-keys)

With my Korg NanoKEY2 I see the following event-keys: (You should rebase to the latest master to see the same as this)

([:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-off]
(:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-off 49)
[:midi :note-off]
[:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-on]
(:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-on 49)
[:midi :note-on])

---

I was hoping that this would be clearer as to what should be included as the key.

> Additionally, there are two events shown for each note-on. I'm not sure why?

Actually, there are three events for each note-on with the latest version on Github. This makes it easy to attach handlers for

* generic midi events
- i.e. [:midi note-on]
* device specific midi events
- i.e. [:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-on]
* device and note/controller specific midi events
- i.e. [:midi-device "KORG INC." "KEYBOARD" "nanoKEY2 KEYBOARD" :note-on 49]

This really is just a pair of crutches until we have efficient pattern matching in the event system.