Is there a way to enumerate which module is connected?

Is there a way to determine via macro which mouse module is currently connected? I have some macros that affect the speeds of both the trackpoint and the trackball, but I’d like to be able to give them separate variables so I can for example insert the trackpoint which is at baseSpeed 3 and then insert the trackball which is at baseSpeed 4, and be able to adjust the value for the currently attached module.

Is this possible, or do I need to use a single set of variables and modify both modules speeds simultaneously?

Indeed not possible at the moment, sorry!

1 Like

The speeds of different modules can be adjusted separately, and their values usually differ, so I don’t understand your use case. Feel free to elaborate further.

The usecase is having bindings that adjust speed of the currently connected module.

1 Like

This is correct. I wanted to have separate var stored speeds for the trackball and trackpoint as I switch between them. I’ve settled on just sharing the speed var between them rather than setting up a separate set of shortcuts to both modules separately.

To elaborate a bit more, the var I’m adjusting is a speed multiplier, so I can quickly dial up or down the sensitivity of the module

@Zetaphor Please elaborate on how you would exactly implement your macros with ifModuleConnected and/or ifNotModuleConnected.

Here’s an example of what I was hoping to accomplish:

ifModuleConnected trackball {
   setVar trackballSpeedMultiplier ($trackballSpeedMultiplier + 1.0)
   setVar trackballCurrentSpeed ($trackballSpeed * $trackballSpeedMultiplier)
   set module.trackball.speed $trackballCurrentSpeed
   setLedTxt 0 "M$trackballSpeedMultiplier"
}
ifModuleConnected trackpoint {
   setVar trackpointSpeedMultiplier ($trackpointSpeedMultiplier + 1.0)
   setVar trackpointCurrentSpeed ($trackpointSpeed * $trackpointSpeedMultiplier)
   set module.trackpoint.speed $trackpointCurrentSpeed
   setLedTxt 0 "M$trackpointSpeedMultiplier"
}

I switch between modules and would like to manage their speeds and speed multipliers independently. Currently I’m using a “trackdevice” variable for both since they can’t be distinguished.

Other than the setLedTxt the if statements make no difference?
Unless you have just written the above incorrectly

Likely, I was just trying to convey the intention. I just modified my existing macro and threw some if statements around it to demonstrate what I was looking for from a potential ifModuleConnected conditional

Oh wait, I didn’t check the link and didn’t realize those conditional actually exist :sweat_smile:

@Zetaphor ifModuleConnected and ifModuleNotConnected only exist in the referenced pull request, which I have yet to merge. I’m hesitant to merge this PR because it adds further macro commands, and I doubt their usefulness.

I asked how you’d use these commands because I don’t see a good use case yet. The module speed settings are module-specific, so it’s already possible to set them separately without branching based on the connected module. The provided code would work without branching except for the argument of setLedTxt, which isn’t a strong use case.

Please let me know if I’m missing something.

1 Like

Well, using that macro with removed branching would mess up the unconnected module’s settings, wouldn’t it?

I wouldn’t put it that way. I’d say that without branching, all the featured variables were updated and not messed up, which shouldn’t be a problem usability-wise. I still can’t see why the new commands are useful.

I wouldn’t put it that way. I’d say that without branching, all the featured variables were updated and not messed up

:person_facepalming:

@kareltucek If you have something constructive to say, please say it.

I genuinely can’t see the value of the new conditions. In this specific example, updating all the mentioned variables does no harm, as module speed settings are module-specific, and I don’t see a good use case.

Sorry.

I am afraid I don’t. I just don’t see how “updating” a value from a desired value to an undesired value falls under “doing no harm”.

My point is that the undesired updates affect then-irrelevant variables that get updated again with relevant values when needed.

The only use case that I can think of is changing some of the key assignments if the key cluster module is not connected, because without it you are missing some keys. In that case maybe you want some of your keyboard layout to be different.

My point is that the undesired updates affect then-irrelevant variables that get updated again with relevant values when needed.

This is totally absurd.

usecases

It can also be used to remap the two-finger-tap of the touchpad.

I am not the OP however I can now see the reasoning.

I have three RHS modules. I swap between them on a regular basis (I do in both cases here).

Let’s say I am using the trackball and it is dialled in for my use that day. I swap to the trackpoint and I find it’s just a little fast for me as today I am working off one monitor only. I change it using the macro and the keys it is bound to. Then I swap back to the trackball. Without the if statement I have borked my settings for trackball and have to dial back in.

Perhaps a little contrived, but still a use case i can see being important to someone. I just didn’t “get it” earlier when I questioned it.

1 Like