Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OnRotateCallback stops emitting new values after a 360º rotation #18

Open
cursive opened this issue Oct 1, 2021 · 15 comments
Open

OnRotateCallback stops emitting new values after a 360º rotation #18

cursive opened this issue Oct 1, 2021 · 15 comments

Comments

@cursive
Copy link

cursive commented Oct 1, 2021

'rotate' event @rotation: 1.00 @buttonPressed: false
Rotating the dial 360º outputs numbers between 0.000 and 1.000 and then stops, is there a way to unlock this limit and get values below 0.000 and above 0.000
@cursive cursive changed the title rotate() stops emitting new values after a 360º rotation OnRotateCallback stops emitting new values after a 360º rotation Oct 1, 2021
@happycodelucky
Copy link
Owner

happycodelucky commented Oct 1, 2021 via email

@cursive
Copy link
Author

cursive commented Oct 3, 2021

Thanks Paul,
By connecting it as an HID do you mean using at simply for volune/playback?

Ultimately I’d like it to emulate alphanumeric keyboard strokes for a JavaScript web-app, or use this library to send events to the web-app over sockets and in either case i’d need the continuous scroll events

I’ve emailed teenage engineering to ask if this is a limitation of how the device emits events but haven’t yet heard back

@jsiverskog
Copy link

hey,
you can configure the ortho remote to work in "relative" mode, that should solve this. my recommendation is that you do that every time after connecting.

for the current available version this is the feature set:

OR1 SYSEX SPEC
strt | TE       OR1 | cmd  addr values | end
-----|--------------|------------------|----
F0   | 00 20 76 08  | xx   xx   xx ... | F7

cmd
00      write
01      read

addr    setting                            default     note
00      midi channel                       0
01      midi cc                            1
02      midi cc abs (0 or 1)               1           set to 1 to enable absolute mode
03      midi note                          60
04      midi velocity                      100

values
write   list of values for consecutive addresses after addr
read    number of consecutive addresses to read after addr (0 = read all)
        - response msg can be used to write those values back

EXAMPLES
F0 00 20 76 08 00 01 0e F7     set send cc 14
F0 00 20 76 08 01 00 00 F7     read all```

@rickardrosen
Copy link

rickardrosen commented Feb 15, 2022 •
edited
Loading

I'm looking to do this as well!

I'm controlling a digipot and need to either sync a value, or have the remote just send events and not care about end positions.
However, when pairing the Ortho remote as a HID device I receive no events at all.

What would the best way to send the above command to the remote? Using this lib would it be through midiCharacteristics.write?

(Any idea why no HID events are received, when pairing and discovery works without a hitch, would be appreciated.)

@jsiverskog
Copy link

@rickardrosen my guess is that your os takes care of the hid events, and they probably won't be relayed into your app as you expect.

midi is probably the way to go. unfortunately i don't know enough about this library to tell you how to use it with midi.

@happycodelucky
Copy link
Owner

It looks like I'm lagging here. @jsiverskog provided some useful info that would help refactor the library to support a relative mode. I just don't have the cycles at the moment to dive back in and update this, but I should update it on a free day.

@rickardrosen you should be able to use midiCharacteristic.write to set the above SYSEX command to change to relative. However I cannot be sure what the library will do in terms of eventing back. See onMidiDataIONotify, set a breakpoint in there after connecting.

I'll carve out some time in the next coming weeks to give this package a refresh.

@rickardrosen
Copy link

rickardrosen commented Feb 20, 2022 •
edited
Loading

@jsiverskog - So I've added the ortho as a hid device, dmsg looks fine, and bluetoothctl shows device connected and trusted.
cat on the raw HID device shows no events, and python or node hid lib can connect the device, but no events are received - is this due to some hardware setting or configuration? (seems @happycodelucky indicate success as a HID device above?)

If midi is the only way to go due to hardware, do you have any information of writing a wheel position back to the remote? I seem to recall an issue where this was discussed (edit: ah yes the only other open issue =)).

@jsiverskog
Copy link

jsiverskog commented Feb 21, 2022 •
edited
Loading

@rickardrosen : that sounds weird. you should definitely get hid events unless you have disabled hid on the ortho remote - which is a feature that should not be available in stock firmware.

  • have you updated the firmware?
  • does btmon report any events?

@rickardrosen
Copy link

No firmware update - wasn't aware that was possible as an end user.

Interestingly enough btmon shows events! I wonder why these are not visible from the /dev/hidraw0, that my system claims is the ortho remote... Any ideas much appreciated!

Regarding writing of the relative value - I could probably use gattto set it, but you recommend setting it on each connect, so this is just stored volatile, @jsiverskog?

@jsiverskog
Copy link

@rickardrosen

No firmware update - wasn't aware that was possible as an end user.

well, we don't have a smooth way of doing it now, so it's not super public. available on request.

Interestingly enough btmon shows events! I wonder why these are not visible from the /dev/hidraw0, that my system claims is the ortho remote... Any ideas much appreciated!

i believe there are a number of things that needs to be correctly set up in order for events to end up in one of those dev 'files'. have you built bluez yourself?

Regarding writing of the relative value - I could probably use gattto set it, but you recommend setting it on each connect, so this is just stored volatile, @jsiverskog?

all settings except for disabling hid (which is a 'new' feature) is runtime only and is reset when repairing.

@happycodelucky
Copy link
Owner

@rickardrosen I created a gist with some code (100% untested/unrun - stripped private code). https://gist.github.com/happycodelucky/a9a165f9a799ddc826d2996bedb2d598

I'm looking at the changes to support relative rotation, but I'm having to remember BLE Midi all over again.

@happycodelucky
Copy link
Owner

happycodelucky commented Mar 17, 2022 •
edited
Loading

@rickardrosen Thanks for the information you provided for setting relative mode.

I’m having a bit of trouble enabling the relative mode or changing the value, be it adapting this package, or using a BLE tool on macOS (BlueSee).

I'm writing to the BLE MIDI Service (03B80E5A-EDE8-4B33-A751-6CE34EC4C700) characteristic 7772E5DB-3868-4112-A1A9-F2669D106BF3. The SysEx messages (page 6) in https://www.hangar42.nl/wp-content/uploads/2017/10/BLE-MIDI-spec.pdf describes the packet

Header:        0x80
Timestamp Low: 0x80
Start SysEx:   0xF0
Data:          0x00 0x20 0x76 0x08 0x00 0x00 0x01 0x00 0x3C 0x00
Timestamp Low: 0x80
End SysEx:     0xF7

For the breakdown of the data bytes:

TE-OR1:            0x00 0x20 0x76 0x08
CMD (write):       0x00
CHANNEL:           0x00
CC:                0x01
CC-ABS:            0x00
NOTE (modulation): 0x3C
VELOCITY:          0x00

In combinations - I’ve tried without the header + timestamps. I’ve tried using absolute (where the note & velocity would matter). I’ve tried without the note & velocity when using relative mode.

No dice.

Looks like I’m running v2.2.0 of the firmware in case this is an issue with needing an update.

@jsiverskog
Copy link

jsiverskog commented Mar 17, 2022 •
edited
Loading

hey,
please try this to enable relative mode:

0x80 # ble midi header
0x80 # ble midi timestamp
0xf0 # sysex start
0x00 # midi id
0x20 # midi id
0x76 # midi id
0x02 # ortho remote id
0x00 # write
0x02 # start address (=abs/rel)
0x00 # value (=relative)
0x80 # timestamp
0x7f # sysex end

it seems like the ortho remote id has been changed over time, so for units running old firmware 0x02 should be used, and 0x08 should be used for newer firmwares (but 0x02 is still supported however).

i'm sorry for giving you the wrong id previously.

@happycodelucky
Copy link
Owner

happycodelucky commented Mar 17, 2022 via email

@jsiverskog
Copy link

@happycodelucky : it is possible to get the firmware version from the advertising data, or by using the device information service.

however, as i said, you can simply use 0x02 which works for all versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@happycodelucky @cursive @jsiverskog @rickardrosen