# VPIXX hardware class?

**URL:** <https://discourse.psychopy.org/t/vpixx-hardware-class/3621>\
**Category:** Development\
**Tags:** vpixx\
**Created:** [December 14, 2017, 1:50pm UTC](https://discourse.psychopy.org/t/vpixx-hardware-class/3621 "2017-12-14T13:50:34Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![jon](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.psychopy.org/jon/32/22_2.png) [@jon](https://discourse.psychopy.org/u/jon)\
**Post date:** [January 24, 2018, 4:25pm UTC](https://discourse.psychopy.org/t/vpixx-hardware-class/3621/4 "2018-01-24T16:25:36Z")

</div>

> Looking through the API, there are a few deprecated methods. For example, the visual.Window class contains a deprecated bitsMode, who’s entry now says
> 
> DEPRECATED in 1.80.02. Use BitsSharp class from pycrsltd instead.
> 
> However, I can’t see the pycrsltd library being loaded anywhere.

So, yes the way this works had to change to make it possible to make it more possible to support other hardware. That means that, rather than the window, itself, needing to know about all the boxes that might interact with it, Window just does its own thing but allows _hooks_ (methods) to be overridden by other objects. For instance, with

```auto
win = Window( ... )
bits = BitsSharp(win, ... )

```

the idea is that bits goes and changes the Window so that it will operate correctly with this device. In the init of BitsSharp. it takes the Window method `_prepareFBOrender` and replaces it with its own (so that it can render the framebuffer using Mono++ mode etc) and replaces win.gammaRamp with a linear ramp so that it can take over the gamma ramp control itself. Does that make sense?

So the Window no longer knows about CRS, it’s that CRS changes the necessary parts of the Window.

> [@tomwallis](#):
>
> That seems simple, but I expect it would then be difficult to pass this to PsychoPy’s Window class in a way that it would understand (e.g. LUT and gamma tables correct, correct passing of bits in special modes). I haven’t checked this yet (not in the lab right now) but I should have more info tomorrow.

You sort of don’t pass either object anything from the other.

I expect that you’d most naturally create a ViewPixx class in PsychoPy that is a subclass of the one they provide (just as the BitsSharp class is a sub-class of SerialDevice) and where some methods need overriding so that they also trigger some action on the visual.Window as needed.

You’ll need to use settings from the ViewPixx to set things in the Window, and vice-versa. e.g. the choice of what shader program you apply when rendering the FBO into the actual back buffer will depend on what mode the ViewPixx is set to. So you could override the function `setVideoMode()` like this:

```auto
    def setVideoMode(self, videoMode):
        super(self).setVideoMode(videoMode) # set the mode on the ViewPix
        
        # then also set up the Window to use this mode (changed FBO shader)

```

Conversely some methods (like `setBacklightIntensity `) won’t need overriding because the window doesn’t need to behave differently

> A question here: how should I include a dependency to pypixxlib within PsychoPy? Obviously we don’t want this to be required for all users, but rather we would like the system to check for it if the VPIXX hardware is used. How should I implement that in an import statement?

Your device will be in psychopy/hardware/pypixx and pypixxlib will just be imported if the user does

```auto
from psychopy.hardware import pypixx

```

---

_[View the full topic](https://discourse.psychopy.org/t/vpixx-hardware-class/3621)._