It would appear icex2 and I worked on vigem support for iidxio at the same time.
Advantages of icex2's impl: has a spotlight sequencer, might be cleaner
Advantages of mine: compatibility with LR2, more options for TT input handling
Thanks to zyp, this turntable button input implementation draws from their Arcin firmware adjustments for LR2. Also thanks to Xyen, for vigem-sdvxio on which this was based.
In GitLab by @GRIM.657 on Dec 18, 2020, 01:55
_Merges master -> master_
It would appear icex2 and I worked on vigem support for iidxio at the same time.
Advantages of icex2's impl: has a spotlight sequencer, might be cleaner
Advantages of mine: compatibility with LR2, more options for TT input handling
Thanks to zyp, this turntable button input implementation draws from their Arcin firmware adjustments for LR2. Also thanks to Xyen, for vigem-sdvxio on which this was based.
I had originally held off on including vigem-iidxio since in testing it didn't work with infinitas. Have you tested this with it?
In GitLab by @xyen on Dec 18, 2020, 07:56
I had originally held off on including vigem-iidxio since in testing it didn't work with infinitas. Have you tested this with it?
I did, unfortunately I do not believe it's possible with the ViGEmBus driver alone. I tried emulating both X360 and DS4 controllers, and could not get either to register. I also tried using a utility to map the vigem pads to a virtual keyboard, which Infinitas also did not pick up.
Side note, I should probably be more specific about LR2 compatibility. LR2 can not use the D-Pad buttons of the Xinput controller, at all. The turntables and all other functions must be mapped to the face and shoulder buttons. This is why I am using three separate vigem controllers, and not mapping anything to the D-Pad. Making the TT buttons behave in a way that's actually usable for scratch sections in-game is finicky but Zyp did a great job on the Arcin and I'm borrowing from them, I also exposed some of the constants used in the logic as config options so players can fine-tune their own setups.
In GitLab by @GRIM.657 on Dec 18, 2020, 10:41
I did, unfortunately I do not believe it's possible with the ViGEmBus driver alone. I tried emulating both X360 and DS4 controllers, and could not get either to register. I also tried using a utility to map the vigem pads to a virtual keyboard, which Infinitas also did not pick up.
Side note, I should probably be more specific about LR2 compatibility. LR2 can not use the D-Pad buttons of the Xinput controller, at all. The turntables and all other functions must be mapped to the face and shoulder buttons. This is why I am using three separate vigem controllers, and not mapping anything to the D-Pad. Making the TT buttons behave in a way that's actually usable for scratch sections in-game is finicky but Zyp did a great job on the Arcin and I'm borrowing from them, I also exposed some of the constants used in the logic as config options so players can fine-tune their own setups.
In that case, I suggest closing this out, and implementing vJoy instead. Which would allow us to emulate dinput instead, which should work.
In GitLab by @xyen on Dec 18, 2020, 12:29
In that case, I suggest closing this out, and implementing vJoy instead. Which would allow us to emulate dinput instead, which should work.
@xyen does it make sense having two solutions, vigem and vjoy for iidxio then?
@GRIM.657 Great to see that you also looked into this but sorry for the unfortunate clash here. I would propose moving the vigem stuff from my current MR !66 to a dedicated one and merge it with whatever makes sense from yours, e.g. compatibility with LR2, more options for TT input handling. Then take reviewing changes for this together from there. I would take care of driving that.
@xyen does it make sense having two solutions, vigem and vjoy for iidxio then?
@GRIM.657 Great to see that you also looked into this but sorry for the unfortunate clash here. I would propose moving the vigem stuff from my current MR !66 to a dedicated one and merge it with whatever makes sense from yours, e.g. compatibility with LR2, more options for TT input handling. Then take reviewing changes for this together from there. I would take care of driving that.
Comparing this implementation to mine from !68, this is one of the features mine is lacking. Do you mind explaining why people need that? What's the problem that is solved with the debouncing and the threshold below?
Comparing this implementation to mine from !68, this is one of the features mine is lacking. Do you mind explaining why people need that? What's the problem that is solved with the debouncing and the threshold below?
You mentioned something about LR2 not liking the d-pad in another comment. Does that mean that this button mapping is tested with LR2 and confirmed working?
You mentioned something about LR2 not liking the d-pad in another comment. Does that mean that this button mapping is tested with LR2 and confirmed working?
Yes, I'm using the "L/R thumb stick pressed", which show up as buttons 9 and 10 in Windows. For each player, keys 1-7 should show up as buttons 1-7, start is button 8, TT is 9 and 10. Because only 10 buttons are available per player, I'm using a third vigem controller for shared inputs like VEFX, Effect Test, Service, Coin.
I intended to use the D-Pad when I originally wrote the code, but had to pivot after testing with LR2. Thus the "dpad" variable names. I'm happy to clean this up if you'd like.
In GitLab by @GRIM.657 on Dec 18, 2020, 19:34
Commented on [src/main/vigem-iidxio/main.c line 180](https://github.com/djhackersdev/bemanitools/compare/9a5dc503f4161888f40256565bcc573359e7498e..5f5e517c48d25b5e4eb7814870a9b1e09fb6b042#diff-a079b684e4d62af4eeaaaab5759562ecR180)
Yes, I'm using the "L/R thumb stick pressed", which show up as buttons 9 and 10 in Windows. For each player, keys 1-7 should show up as buttons 1-7, start is button 8, TT is 9 and 10. Because only 10 buttons are available per player, I'm using a third vigem controller for shared inputs like VEFX, Effect Test, Service, Coin.
I intended to use the D-Pad when I originally wrote the code, but had to pivot after testing with LR2. Thus the "dpad" variable names. I'm happy to clean this up if you'd like.
A. There is some minimum amount of movement necessary to activate the turntable (more than just 1 tick)
B. The turntable input will remain solid for some time, instead of flickering.
Debounce is the amount of time the TT button will remain held after no ticks are registered, which is between (debounce * threshold * 2ms) and 2 * (debounce * threshold * 2ms), which is the "tt_dpad_maximum".
This is necessary because at 500hz or 1000hz, with only 8bits of accuracy for TT position, many cycles pass where the turntable delta is 0 even if the user is turning it constantly. We want the input to be solid and not flickering while the user is spinning the TT, so this takes care of that. This logic is mostly lifted from Arcin firmware (https://cgit.jvnv.net/arcin/tree/arcin/main.cpp?h=conf line 433)
Threshold is the number of ticks the TT must move in an amount of time (debounce * 2ms) to register an input.
IIDX has similar threshold code as this, i.e., that TT must move X ticks within Y frames to count as an input. This is why turning the table very slowly in IIDX has no effect. This code is to emulate that behavior.
Notes
The debounce variable thus affects both how wide the window is to register TT movement, and how long the button will remain pressed after TT input has stopped.
The 2ms values I'm using above are from Sleep(2) in the main loop.
In GitLab by @GRIM.657 on Dec 18, 2020, 20:09
Commented on [src/main/vigem-iidxio/main.c line 121](https://github.com/djhackersdev/bemanitools/compare/9a5dc503f4161888f40256565bcc573359e7498e..1fc13155be99ceeb2f49b7598ef76f3c3026f0a0#diff-a079b684e4d62af4eeaaaab5759562ecR121)
For the user it is ideal if:
A. There is some minimum amount of movement necessary to activate the turntable (more than just 1 tick)
B. The turntable input will remain solid for some time, instead of flickering.
**Debounce** is the amount of time the TT button will remain held after no ticks are registered, which is between `(debounce * threshold * 2ms)` and `2 * (debounce * threshold * 2ms)`, which is the "tt_dpad_maximum".
This is necessary because at 500hz or 1000hz, with only 8bits of accuracy for TT position, many cycles pass where the turntable delta is 0 even if the user is turning it constantly. We want the input to be solid and not flickering while the user is spinning the TT, so this takes care of that. This logic is mostly lifted from Arcin firmware (https://cgit.jvnv.net/arcin/tree/arcin/main.cpp?h=conf line 433)
**Threshold** is the number of ticks the TT must move in an amount of time `(debounce * 2ms)` to register an input.
IIDX has similar threshold code as this, i.e., that TT must move X ticks within Y frames to count as an input. This is why turning the table very slowly in IIDX has no effect. This code is to emulate that behavior.
Notes
The `debounce` variable thus affects _both_ how wide the window is to register TT movement, and how long the button will remain pressed after TT input has stopped.
The `2ms` values I'm using above are from `Sleep(2)` in the main loop.
In GitLab by @GRIM.657 on Dec 23, 2020, 03:58
added 1 commit
<ul><li>b3279865 - vigem-iidxio: cleanpup</li></ul>
[Compare with previous version](/djhackers/bemanitools/-/merge_requests/67/diffs?diff_id=1402&start_sha=1fc13155be99ceeb2f49b7598ef76f3c3026f0a0)
In GitLab by @GRIM.657 on Dec 23, 2020, 03:58
Commented on [src/main/vigem-iidxio/main.c line 121](https://github.com/djhackersdev/bemanitools/compare/9a5dc503f4161888f40256565bcc573359e7498e..1fc13155be99ceeb2f49b7598ef76f3c3026f0a0#diff-a079b684e4d62af4eeaaaab5759562ecR121)
changed this line in [version 2 of the diff](/djhackers/bemanitools/-/merge_requests/67/diffs?diff_id=1402&start_sha=1fc13155be99ceeb2f49b7598ef76f3c3026f0a0#4169244c26539177a2d6beeef98b081e6163ef5c_121_121)
In GitLab by @GRIM.657 on Dec 23, 2020, 04:06
added 1 commit
<ul><li>5f5e517c - vigem-iidxio: fix missed find/replace</li></ul>
[Compare with previous version](/djhackers/bemanitools/-/merge_requests/67/diffs?diff_id=1403&start_sha=b32798652781343cc74d5653fee97c509ae3b801)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In GitLab by @GRIM.657 on Dec 18, 2020, 01:55
Merges master -> master
It would appear icex2 and I worked on vigem support for iidxio at the same time.
Advantages of icex2's impl: has a spotlight sequencer, might be cleaner
Advantages of mine: compatibility with LR2, more options for TT input handling
Thanks to zyp, this turntable button input implementation draws from their Arcin firmware adjustments for LR2. Also thanks to Xyen, for vigem-sdvxio on which this was based.
In GitLab by @xyen on Dec 18, 2020, 07:56
I had originally held off on including vigem-iidxio since in testing it didn't work with infinitas. Have you tested this with it?
In GitLab by @GRIM.657 on Dec 18, 2020, 10:41
I did, unfortunately I do not believe it's possible with the ViGEmBus driver alone. I tried emulating both X360 and DS4 controllers, and could not get either to register. I also tried using a utility to map the vigem pads to a virtual keyboard, which Infinitas also did not pick up.
Side note, I should probably be more specific about LR2 compatibility. LR2 can not use the D-Pad buttons of the Xinput controller, at all. The turntables and all other functions must be mapped to the face and shoulder buttons. This is why I am using three separate vigem controllers, and not mapping anything to the D-Pad. Making the TT buttons behave in a way that's actually usable for scratch sections in-game is finicky but Zyp did a great job on the Arcin and I'm borrowing from them, I also exposed some of the constants used in the logic as config options so players can fine-tune their own setups.
In GitLab by @xyen on Dec 18, 2020, 12:29
In that case, I suggest closing this out, and implementing vJoy instead. Which would allow us to emulate dinput instead, which should work.
@xyen does it make sense having two solutions, vigem and vjoy for iidxio then?
@GRIM.657 Great to see that you also looked into this but sorry for the unfortunate clash here. I would propose moving the vigem stuff from my current MR !66 to a dedicated one and merge it with whatever makes sense from yours, e.g. compatibility with LR2, more options for TT input handling. Then take reviewing changes for this together from there. I would take care of driving that.
Dedicated ViGEm iidxio client MR for my changes: https://dev.s-ul.eu/djhackers/bemanitools/-/merge_requests/68
Comparing this implementation to mine from !68, this is one of the features mine is lacking. Do you mind explaining why people need that? What's the problem that is solved with the debouncing and the threshold below?
You mentioned something about LR2 not liking the d-pad in another comment. Does that mean that this button mapping is tested with LR2 and confirmed working?
In GitLab by @GRIM.657 on Dec 18, 2020, 19:34
Commented on src/main/vigem-iidxio/main.c line 180
Yes, I'm using the "L/R thumb stick pressed", which show up as buttons 9 and 10 in Windows. For each player, keys 1-7 should show up as buttons 1-7, start is button 8, TT is 9 and 10. Because only 10 buttons are available per player, I'm using a third vigem controller for shared inputs like VEFX, Effect Test, Service, Coin.
I intended to use the D-Pad when I originally wrote the code, but had to pivot after testing with LR2. Thus the "dpad" variable names. I'm happy to clean this up if you'd like.
All good, no need to change this here as I am already porting the few missing bits from your MR to mine.
In GitLab by @GRIM.657 on Dec 18, 2020, 20:09
Commented on src/main/vigem-iidxio/main.c line 121
For the user it is ideal if:
A. There is some minimum amount of movement necessary to activate the turntable (more than just 1 tick)
B. The turntable input will remain solid for some time, instead of flickering.
Debounce is the amount of time the TT button will remain held after no ticks are registered, which is between
(debounce * threshold * 2ms)and2 * (debounce * threshold * 2ms), which is the "tt_dpad_maximum".This is necessary because at 500hz or 1000hz, with only 8bits of accuracy for TT position, many cycles pass where the turntable delta is 0 even if the user is turning it constantly. We want the input to be solid and not flickering while the user is spinning the TT, so this takes care of that. This logic is mostly lifted from Arcin firmware (https://cgit.jvnv.net/arcin/tree/arcin/main.cpp?h=conf line 433)
Threshold is the number of ticks the TT must move in an amount of time
(debounce * 2ms)to register an input.IIDX has similar threshold code as this, i.e., that TT must move X ticks within Y frames to count as an input. This is why turning the table very slowly in IIDX has no effect. This code is to emulate that behavior.
Notes
The
debouncevariable thus affects both how wide the window is to register TT movement, and how long the button will remain pressed after TT input has stopped.The
2msvalues I'm using above are fromSleep(2)in the main loop.In GitLab by @GRIM.657 on Dec 23, 2020, 03:58
added 1 commit
Compare with previous version
In GitLab by @GRIM.657 on Dec 23, 2020, 03:58
Commented on src/main/vigem-iidxio/main.c line 121
changed this line in version 2 of the diff
In GitLab by @GRIM.657 on Dec 23, 2020, 04:06
added 1 commit
Compare with previous version