LED Encoder feedback?

[hydrogxn]

Curious at what point in the script is best for LED encoder feedback?

I'm experiencing something where on the BCR when I update the LED via valueObserver on a CursorRemoteControlsPage.getParameter(i).value()... It seems to slow down the BCR 2000.

Would it be better to only update via Flush? having difficulty here too. My other thought is just to dedicate a button to repopulate the LEDs on the BCR when needed. or perhaps on different events occur like device changes or things like this.

I also tried doing an unoptimized version of this during flush but

On my other script for a midifighter twister, updating with valueObserver doesn't seem to slow down the remote control for whatever reason.

Any suggestions here for optimization?

[Tj Shredder]

Check for a feedback loop...

[hydrogxn]

Had a reply all typed out for this...

Yeah i suspect the script is receiving the data from the controller and setting the knob one frame, then in another frame its sending that value back to the controller. And at somepoint between this i've already advanced the knob but it goes back to the frame that was sent to the controller. It doesn't feel like feedback in this case just latent/timing.

I see in one of Thomas's scripts he puts a timer on cc events and then resolves them during flush. I'm gonna try that to get everything in sync.

I also hooked up to the new Hardware Surface API but it doesn't seem to do bi-directional feedback for LEDs. If bitwig implemented this it would make this much simpler... Some method to add port, channel and cc for feedback at the minimum. although i have seen some interfaces use strange cc values to indicate the encoder ring i.e.(behringer xtouchmini).

[test822]

sup dude. as an owner of not one, but two BCR2000's and who is dissapointed with bitwig's lack of native support for LED encoder feedback (ableton does it, come on man), I'm glad to see you working on this.

but before you bust your butt, a dude named Thomas Helzle already may have made scripts that do what you're looking for.

here's the first version

https://drive.google.com/file/d/1av4oIr ... zHv0r/view

you can select it by dropping it into your bitwig user scripts folder, adding a new controller and the "brand" will be "TomsScripts".

he made updated versions of that script, you can download them below, but I haven't tested them out yet. I think the one you'll want to use is "TomsMultiBiController"

https://github.com/Knochenschall/Toms_Bitwig_Scripts

I'm not sure if those are the newest versions of the scripts. the dude has an account on here, you can try to PM him for more info, and to shoot him a thanks.

memberlist.php?mode=viewprofile&u=19546 ... 33a5ab6e41

[hydrogxn]

Got it! I was testing this a couple months ago and the MultiBiController didn't seem to have this problem. Although, I would need to investigate again... From their script it seems they check to see if the stored variable is different than the one that is sent and if its different it updates the LED. which would prevent the extra update to the controller causing it to slow itself down. Also interesting to see some older version script .

I'm on to some different controllers, midifighter twister and hope to post the scripts when they are finished.

[moss]

Got it! I was testing this a couple months ago and the MultiBiController didn't seem to have this problem. Although, I would need to investigate again... From their script it seems they check to see if the stored variable is different than the one that is sent and if its different it updates the LED. which would prevent the extra update to the controller causing it to slow itself down. Also interesting to see some older version script .

I'm on to some different controllers, midifighter twister and hope to post the scripts when they are finished.

Send updates in the flush() function. But this is called about 30-60ms, so this floods many of the simple controller chips. Therefore always cached the values and send only if necessary. But also check, if the controller needs frequent updates to not go black or start funny animations.

[hydrogxn]

Send updates in the flush() function. But this is called about 30-60ms, so this floods many of the simple controller chips. Therefore always cached the values and send only if necessary. But also check, if the controller needs frequent updates to not go black or start funny animations.

that is helpful thanks moss! you rule

[Kirkwood West]

Back to implementing the hardware api into my control scripts and am wondering if there is a way to create a bindable object...

It seems like once the AbsoluteHardwareKnob is created for a target cc it is no longer sent through the handle midi. Thats awesome for mapping things directly to established bitwig objects.

But for for a small utility part of my script, i need access to the midi to set colors on the midi fighter. So i was going to unbind them from their objects and just receive the midi as usual but that doesn't work. hmmm... So i'm thinking is it possible to create my own SettableRangedValue and use it with the binding?

[Kirkwood West]

I'm seeing now that I can mark my HardwareKnob as markInterested and retreive the values this way... which is fine since this is really only flush() non performative stuff.

Code: Select all

  
AbsoluteHardwareKnob hardware_knob = hardware_surface.createAbsoluteHardwareKnob("TWISTER_0");
hardware_knob.setAdjustValueMatcher(hardware.inputPort.createAbsoluteCCValueMatcher(Channel, CC));
hardware_knob.value().markInterested();

Then in flush something like

Code: Select all

hardare_knob.value().get()

[Kirkwood West]

Still sort of stuck on this one.
It works for the most part until i want to compare the state of the knobs to what I have in memory. When I send out the values of the knobs via midi to update the LEDs it works great... but now the values of the hardware knob are out of sync of the values of the LEDs because no where to the hardware_knobs get updated. So when I compare again to see what has changed... well it goes back to the hardware knob value.

I'm thinking of work arounds for this and will come up with something but certainly a setter on the hardware_knob.value() would do the trick. Unfortunatly that is not part of the api.