1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
// I know explicitly returning at the end of functions is not idiomatic, but I prefer it personally.
// Also, I use tabs everywhere and I don't agree with clippy's reasoning against tabs in doc
// comments, so I will keep using tabs in doc comments
/*!
An interfacing library for your Novation Launchpads, providing both low-level access as well as
powerful high-level abstractions.
# High-level access through the Canvas API
High-level access is possible through the [Canvas] API. The [`Canvas`] trait simply represents a grid of
LEDs that can be written to, and consequently flushed to the actual hardware. A number of high-level
utilities make the Canvas API a pleasure to use.
```rust
use launchy::{CanvasMessage, Color};
let (mut canvas, input_poller) = launchy::s::Canvas::guess_polling()?;
for msg in input_poller.iter() {
match msg {
CanvasMessage::Press { pad } => canvas[pad] = Color::WHITE,
CanvasMessage::Release { pad } => canvas[pad] = Color::BLACK,
}
canvas.flush()?;
}
```
The above `match` statement could also be written in a more concise way:
```rust
canvas[msg.pad()] = if msg.is_press() { Color::WHITE } else { Color::BLACK };
```
# Low-level access
Low-level access is provided via the `Input` and `Output` structs. Care has been taken to ensure
that this library has 100% coverage of the Launchpads' functionality: all documented Launchpad
features are accessible in Launchy's low-level API.
This means you get the real deal: rapid LED updates, double buffering capabilities, device and
firmware information.
Furthermore, we know that a low-level API is not the
place for hidden abstractions - and that's why every function in Launchy's low-level APIs
corresponds to exactly one MIDI message (unless noted otherwise in the documentation). That way, the
user has fine control over the data that's actually being sent.
## Using double-buffering to produce a continuous red flash
```rust
use launchy::Color;
use launchy::s::{DoubleBuffering, DoubleBufferingBehavior, Buffer};
let mut output = launchy::s::Output::guess()?;
// Start editing buffer A
output.control_double_buffering(DoubleBuffering {
copy: false,
flash: false,
edited_buffer: Buffer::A,
displayed_buffer: Buffer::B,
});
// Light all buttons red, using the rapid update feature - just 40 midi messages
for _ in 0..40 {
output.set_button_rapid(
Color::RED, DoubleBufferingBehavior::None,
Color::RED, DoubleBufferingBehavior::None,
)
}
// Now buffer A is completely red and B is empty. Let's leverage the Launchpad S flash
// feature to continually flash between both buffers, producing a red flash:
output.control_double_buffering(DoubleBuffering {
copy: false,
flash: true, // this is the important bit
edited_buffer: Buffer::A,
displayed_buffer: Buffer::A,
});
```
*/
pub use *;
pub use *;
pub use *;
pub use launchpad_s as s;
pub use launchpad_mk2 as mk2;
pub use launch_control as control;
/// The MIDI API of the classic Launch Control and the Launch Control XL is identical
pub use launch_control as launch_control_xl;
pub use launch_control as control_xl;
/// Identifier used for e.g. the midi port names etc.
const APPLICATION_NAME: &str = "Launchy";