Space Navigator PE Driver Development Thread

[cherrybomb]

First off I apologize for not posting sooner, I just returned from a weekend in Santa Barbara with my g/f.

It appears that this release is stable. I've not had anything crash thus far except when using the deprecated XML parameter for mouse emulation from the last alpha build. I'm quite impressed with this... if we could get the context switching I think it'd be great. Anyone have any other experiences with it or input they'd like to share?

Not a problem, thanks for the update.

Should have told me you were heading to SB, I live there.

I'll work on getting context switching in there very soon, it should be a fairly simple thing to do. How do you feel about the mechanism I described a few posts ago? Using Window Messages for context switching?

The alternative is that it has to be some action of either a button or axis, or that it attempts to switch contexts based on the active window, which I'd prefer not to do.

[intervex]

Cherry,
Didn't know you were from the area, I woulda mentioned it had I known... We picked a great weekend to head up there though, the weather was fantastic. We had a great time!

Anywho, on to the project at hand... Seeing as RR Skinners/Users already use window messages, and it works reliably, I see no reason to deviate from that... reading your earlier post however I notice you would provide for a sequential access to contexts where you would switch 1-2-3-4-etc... Is there a way to parse the XML file to get an array of assigned context names, and then translate the assigned names into available window messages? so if you did something like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<snConfig>
  <contexts>
    <context-Default>
      [CONTROL SET 1]
    </context-Default>
    <context-Guidance>
      [CONTROL SET 2]
    </context-Guidance>
    <context-Music>
      [CONTROL SET 3]
    </context-Music>
  </contexts>

You would get available window messages of Default, Guidance, and Music?

There has to be a way of random access contexts as opposed to the linear approach... I don't know how difficult it would be to implement something like that however.

Also, does RR have built-in support for the sending of window messages to other applications? or simply receiving them? If it does, this would make quick work of retrofitting any existing skin with SN context commands...

[cherrybomb]

Cherry,
Didn't know you were from the area, I woulda mentioned it had I known... We picked a great weekend to head up there though, the weather was fantastic. We had a great time!

Anywho, on to the project at hand... Seeing as RR Skinners/Users already use window messages, and it works reliably, I see no reason to deviate from that... reading your earlier post however I notice you would provide for a sequential access to contexts where you would switch 1-2-3-4-etc... Is there a way to parse the XML file to get an array of assigned context names, and then translate the assigned names into available window messages? so if you did something like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<snConfig>
  <contexts>
    <context-Default>
      [CONTROL SET 1]
    </context-Default>
    <context-Guidance>
      [CONTROL SET 2]
    </context-Guidance>
    <context-Music>
      [CONTROL SET 3]
    </context-Music>
  </contexts>

You would get available window messages of Default, Guidance, and Music?

There has to be a way of random access contexts as opposed to the linear approach... I don't know how difficult it would be to implement something like that however.

Also, does RR have built-in support for the sending of window messages to other applications? or simply receiving them? If it does, this would make quick work of retrofitting any existing skin with SN context commands...

Yeah, I had actually reconsidered that after posting. I'll be implementing it such that you can pick any context by sending an appropriate window message.

As for RR being able to send window messages, I assume it can be done, though I haven't confirmed it. I'll look into it before commiting. If necessary maybe a plugin or something would be called for.

Seems like using window messages to pick a particular context is acceptable to everyone that's read this thus far. I'll start working on it when I get a few spare moments. :-)

[cherrybomb]

Yup, confirmed, RR can send window messages, the skin command is "SENDMSG". :-)

[sama]

Hello hello!

cherrybomb, I've finally pulled my thumbs out and have coded the gestures processor, as promised. Code is attached

It's in Java, so it will require a little converting to C++, but it should be very straight forward as it's mostly core code. There's a little work needed on managing some lists, since I rely on the garbage collector to take care of adding and removing to it (in Java, a little heap is setup and performance is so good, that you can rely on it... but hey, that's Java )

I've mega-commented the code, so it should be readable hopefuly. But grab me on AIM as always, when you like. Here's a quick description of what's what:

Motions and TimeFrames are of type Gesture.

Motions are when the threshold is hit, and not an actual value.

A TimeFrame is the delay between motions. A static variance figure exists in here, which is how much leeway to give when checking to see if the delay by the user matches the defined delay. It's basically the precision element.

Macros are a sequence of gestures, and they look something like this: {PAN_X_POS, 200ms, PAN_X_NEG}

When a motion's threshold is detected, then the newGesture method in GestureProcessor should be called with the axis's id and its direction (all available in an enum in the Motion class). The motion is immediately stored in a gesture list along with the time between the last gesture and the current one.

Then the processGestures method is called by the above method when it finishes. This will iterate over all the defined macros, and see if any of them match the sequence gestures in the current gestures list. And since the search is done backwards, it's a little optimised. I could add some more hashing in there, but that will complicaet things and I dont' think it will make that much of a difference.

When a match is found, an event is raised with that macro's id.

Macros can be defined by calling the addMacro in the GestureProcessor. It should be easy to implement a record function using the above methods. In fact, it pretty much already does that. All we'd have to do is add a method that grabs the gesture list, and saves it when the user is in record mode. But this is only useful if we have some config tool.

[intervex]

Sama, welcome back, hope your trip went well. The gesture processor sounds great, should be a good addition to this project. Cherry, that's fantastic re: the window messages, let me know when you've had some time to play around with it...

[intervex]

I have another idea for this project... since it's already set-up to send window messages and such, how hard would it be or would it even be possible, to have the SN program receive the

SENDMSG;SpaceNavigator;CONTEXT-MUSIC

from RR, and the SN program spit back something like

SETLABEL;!SNContext;Music

This would close the loop and provide confirmation that the intended action was taken and we could also then have a little status indicator/readout or some such thing that would show us within RR what context we're in?

(I apologize in advance if I use an incorrect window messages in my example, I'm trying to make sense of the available commands to demonstrate my idea)

[cherrybomb]

I have another idea for this project... since it's already set-up to send window messages and such, how hard would it be or would it even be possible, to have the SN program receive the

SENDMSG;SpaceNavigator;CONTEXT-MUSIC

from RR, and the SN program spit back something like

SETLABEL;!SNContext;Music

This would close the loop and provide confirmation that the intended action was taken and we could also then have a little status indicator/readout or some such thing that would show us within RR what context we're in?

(I apologize in advance if I use an incorrect window messages in my example, I'm trying to make sense of the available commands to demonstrate my idea)

It's absolutely a possibility, and something I've considered doing. This would take care of the need for some onscreen display of the context, since it would be shown right in RR.

I'll keep it in mind while developing the context switching stuff. :-)

[intervex]

Yeah, that's what I was thinking, plus it keeps the SN program more as a plug-in or extension like you were talking about, it enables skinners and such to display the context wherever/however they want.

[intervex]

Hey Ryan, just checking in to see if there's been any progress on the context switching? Seems like this thread died rather quickly....