The on() method takes a color type, which is an HSV color, so a separate hsv method is not needed.
hub.light.on(Color.GREEN)
hub.light.on(Color(120))
hub.light.on(Color(h=120, s=100, 50))
Now it just displays a Matrix/2D list. We can omit manipulations like clear=False. Composing can be done by simply adding two matrices instead.
We also drop the compressed format. Instead we could have a helper function that gives you a
matrix based on a list of integers in the now-deleted format.
Specify on and off time for consistency with future blink method.
Adding some off time helps reading text with subsequent charachters that are the same. For example, now "Hello" reads H e l l o instead of Helo.
Also drop wait argument for now because it is not currently implemented and may never be.
This adds the method equivalent to the recent addition of a single
color light. The only difference is that now a color is returned instead
of a single brightness. The provided color or HSV tuple will be stored
as RGB samples internally, as is already done for pbio light patterns.
In the simplest blinking form this could be:
hub.light.pattern(lambda t: Color.RED if t >= 1000 else None, 2000)
Or a fading, one-color sine:
def fade(time):
v = sin(time/2000/pi)*50+50
h = 360
s = 100
return (h, s, v)
hub.light.pattern(fade, 1000)
This makes it much easier to have fine grained control
over colors and cycle through them easily (0--360).
This also makes it consistent with sensor APIs. Now you
can measure the color and plug it into this method.
We can make this change because none of
the implementations use this yet.
If we feel we miss out by dropping the RGB, it would be more fitting
to instead expose R, G, and B attributes which point to instances of
the Light class. However, this is using more memory for something that
isn't very useful.
We could also just provide generic color converters between rgb, hsv,
and perhaps hex html color strings, not tied to any particular light or
sensor.
Currently, Pybricks has system patterns for builtin lights.
This adds a user method to set such a pattern.
For example, an indefinite sine pattern could be specified by
def fade(time):
return sin(time/2000/pi)*50+50
hub.light.pattern(fade, 1000)
or a blinking pattern using
def blink(time):
if time >= 1000:
return 100
else:
return 0
hub.light.pattern(blink, 2000)
or briefly:
hub.light.pattern(lambda t: 100 if t >= 1000 else 0, 2000)
This combines the best of simplicity and efficiency: The user doesn't
have to calculate and provide an expensive list of floating points, but
provide a clean and adaptable method instead.
By sampling, we maintain a fixed length pattern which we can preallocate
for the hub lights, and the samples are calculated only once and the
callable may be garbage collected if given as lambda. Also, any
exceptions will be caught immediately during the one-off evaluation.
Usually, images are static, so they can be computed in advance instead of during runtime. This makes scripts smaller and much more memory efficient.
For example, now you can say:
HOUSE = 4685823
hub.grid.image(HOUSE)
since 4685823 =
```
0 0 1 0 0
0 1 1 1 0
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
```
We could also choose the binary format to allow for more generic screen sizes. If we allow a bit more space (2 words instead of 1), we could do 1 byte per row to allow screens up to 8x8. Right now, though, we choose 1 word < 31 bits which is a bit more efficient in MicroPython.
We can easily list numerous example in the docs or provide a simple visual calculator.
There is still a matrix method that takes a 2D matrix of intensities for full control during runtime, which is what the image() method was doing initially. This commit renames the old draft to matrix().
Intellisense in VS Code (both jedi and ms python language server) picks
up all imported names and suggests them with equal priority for
code completion. By adding a leading underscore, intellisense lists
these with a lower priority, so they don't get in the way.
Also rename from builtins to _common while we are touching this to
better reflect the intention of the module (it contains types shared
by multiple modules, not builtin types like int).
Because this module describes devices that can be built into a hub or other device.
Since this design is now explicitly shown in
the docs as well, we don't need to hide this
module in the package.
This makes the user code easier to read:
brick.buttons()
brick.buttons.pressed()
It also opens up possibility to add features in the future such as:
brick.buttons.released() # return which buttons are not pressed
brick.buttons.clicked() # return which buttons were clicked since we last checked
This follows the same style as the new light API: some devices have specific instances of a KeyPad class.
A good example that nicely demonstrates the concept is the LPF2 RemoteControl, which has instances of a ColorLight and a KeyPad. It's added in this commit.
Same result as in 92e3735d63, but now achieved by patching the Sphinx configuration instead of patching the API.
Now it doesn't break the API for the purpose of checking and autocomplete, etc.
This is an experimental method for adding lights to some sensors.
And add workaround to make it show up correctly in the docs.
Also some doc8 formatting
Laurens Valk
David Lechner