Announcement

Collapse
No announcement yet.

Temporary profile change while button down? (i.e. Shift mode)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Temporary profile change while button down? (i.e. Shift mode)

    Hello. Is there a way to program a button to behave similarly to a keyboard modifier (meta) key; that is, to remap to a different profile while the button is held down, and restore the original profile on release? Basically, I'm looking to create modes/submodes.

    I'm not using OSCulator for music production, I'm using it to support a more natural style of reading, note-taking and composition, using DevonThink, PDFpen and Dragon Dictate. My previous experience with customizing input devices comes from HazardScript in flight simulators etc. [ http://web.archive.org/web/200612020.../HazardScript/ ] See also [ http://web.archive.org/web/200510180...xdpprofile.asp ]. As you'll see, I'm used to thinking in terms of key-frobs and button states.

    My current aim to get my Wiimote working like a handheld dictation controller, controlling the functionality of Dragon Dictate (so that I don't have to use its awkward voice commands or resort to the keyboard and mouse) as well as supporting the scrolling/highlighting/annotating I do with a Wacom pad. My problem is that I've run out of buttons on the wiimote. The obvious solution is to use the B button (trigger) as a "shift" key.

    Is this possible? I'm used to working with events like this (from the XDProfile site):

    The PROGRAM_MODES section lists each mode and the frobbables or axis that have script or chain assignments. Each mode you identify is marked by a "[modename]" tag, where modename is any original alphanumeric name that does not include any of [](){}<>#=^, including (space). There is a special mode identifier with the name DEFAULT. The DEFAULT mode is the mode that is loaded into the X-36/45 when the profile is loaded. All other modes must be loaded using a script containing the appropriate LOADMODE_ event as described in the SCRIPTLIST section above. Note that each mode of your profile should have at least one script with a LOADMODE_ event to allow you to transfer to another mode.After identifying a mode, you identify frobbable and axis assignments using the syntax "frobbable = scriptname" or "axis = chainname", where frobbable is any one of the pre-defined frobbables listed in table 3 below, scriptname is any one of the script names identified in the SCRIPTLIST section, axis is any one of the pre-defined axis names listed in table 4 below, and chainname is any one of the chain names identified in the AXIS_CHAINS section.

    The difference between the above and OSCulator (from what I can see) is that in this old scripting language, button press and release were two different hardware events. (The language called them 'frobbables.') So in Mode_1-a, ButtonB(press) would load Mode_1-b. And then in Mode_1-b, ButtonB(release) would load Mode_1-a. I see that OSCulator supports profile switching by event, but I don't see how to create one that would change profiles on B-button-press, and then revert on B-button-release.
    Last edited by AchillesActual; 05-05-2012, 07:14 PM.

  • #2
    OK—Split appears to provide this functionality, presenting different event fields for (lo) and (hi). I presume there's no problem with leaving one blank. Will test.

    EDIT: this does not work. (lo) and (hi) are not tiggered for the "B" button on the wiimote. All I see is the base "0" event being triggered.

    Any help? Surely there is a routine method for this.
    Last edited by AchillesActual; 05-05-2012, 05:51 PM.

    Comment


    • #3
      From what I can see, the preset change event won't support "standard trigger" behavior (manual, page 65), so this can't be done in a normal event. Is there any hope for doing this via "Split" as described above? The base mode would have no action for the low state, and would load the submode on triggering the high state. The submode would have no action for the high state and would trigger the return to the base mode upon return to low-state. Easy enough in theory, but the hi and lo lights never show activity if I split the button.

      Might this be because I have key repeat turned on?
      Last edited by AchillesActual; 05-05-2012, 06:10 PM.

      Comment


      • #4
        Having looked around a few old threads, I thought I might be able to do this in one profile, using enable toggles. However, while this lets me switch back and forth between modes (i.e. button map "pages") within one profile (if the states are set correctly on load) via a B button press, it doesn't let me switch the enabled set 0 or 0>0 while B is down. Here's what I currently have:
        Screen shot 2012-05-05 at 8.50.26 AM.png
        What I'm trying to do is have the Button[0>0] events shown below enabled and the Button[0] events disabled only while B is down, and then have it revert to the [0] events enabled and the [0>0] events disabled when B is released.
        Screen shot 2012-05-05 at 9.05.45 AM.png

        While I see both green and yellow activity indicators, if I try and do this via "Split" instead of "Duplicate", I get no response at all. Is this a Wiimote-specific issue? Perhaps I should have posted in the subforum.

        Searching that subforum led me to this page: http://www.osculator.net/doc/manual:..._toggle_enable

        but I don't see any latched enable in the UI in 2.11.2.2....

        Was latching removed? If so, I want it back, please!
        Last edited by AchillesActual; 05-05-2012, 07:33 PM.

        Comment


        • #5
          HAHAHAHAHA. OK, I got it--but it sure isn't obvious. In fact, it's a bit hideous. I needed to "demux" the button, then duplicate it, and kludge the latching by toggling each submode on/off at press/release. So toggle enable twice for each button (one per submode), under both demux states.
          Last edited by AchillesActual; 05-05-2012, 08:27 PM.

          Comment


          • #6
            So the above approach looked good--but then led to some strange locking and key repeating even with routing turned off (until quitting/killing OSCulator), as well as what might have been profile corruption, in which OSCulator didn't want to allow blank entries and kept moving events up from the nested demux to the top level, etc.

            So I gave up on doing it all within one profile and reverted to profile switching using a demuxed button. That works very nicely for this purpose, although more elaborate latching within a profile using the method I described could still run into whatever I encountered. (Not sure if it was really a bug, or just issues from working with a corrupted profile.) Here's the setup:

            Base state/profile:
            Screen shot 2012-05-05 at 11.55.09 AM.png

            Shifted state:
            Screen shot 2012-05-05 at 11.56.07 AM.png

            Sometimes it will get stuck shifted, but tapping B will unstick it and revert it to the base state. I'm using the built in LED profile # indicator to make it visible if it gets stuck.
            Last edited by AchillesActual; 05-05-2012, 10:04 PM.

            Comment


            • #7
              Hi,

              I am sorry I haven had the time to answer your questions earlier. I was busy this afternoon rolling the latest update (2.12-RC1) and now I away from my computer.

              From what I have understood I think what you need is the "Enable Combine" event. The purpose of it is to prevent firing the event of a message from another message. The difference with "Enable" is that the controlled message is reset when it is disabled and triggered when enabled. This allows you to combine buttons of a Wiimote for example with events that have a on/off state (keycodes, combos, notes).

              I'll have a more in-depth look when I am back home tomorrow morning.

              Best,
              Cam

              Comment


              • #8
                OK, so after examining your last post I believe what you did was in the right direction.
                My previous suggestion also applies, but this solution is more easy to deal with.
                For clarity I have attached an example that sends key A when button A is pressed in one preset, and when the B button is held down in the other preset.

                The problem you encountered is due to how OSCulator reacts to Preset change. In version 2.12-RC1 (posted today, here) behaves differently : when a preset is changed it will turn off key related events if they are pressed. This works for Keycode or Key Combo events. A MIDI Note however is not turned off, because it may be desirable to keep it one while doing something else in another preset, in which case the "Enable Combine" event is more suited.

                I would suggest you try again with version 2.12-RC1 and see if you have this problem again.


                Best,
                Cam
                Attached Files

                Comment

                Working...
                X