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
116
117
118
119
120
121
/*!
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.
```no_run
use launchy::{CanvasMessage, Color, Canvas as _, MsgPollingWrapper as _};
let (mut canvas, input_poller) = launchy::s::Canvas::guess_polling()?;
for msg in input_poller.iter() {
match msg {
CanvasMessage::Press { .. } => canvas[msg.pad()] = Color::WHITE,
CanvasMessage::Release { .. } => canvas[msg.pad()] = Color::BLACK,
}
canvas.flush()?;
}
# Ok::<(), launchy::MidiError>(())
```
The above `match` statement could also be written in a more concise way:
```no_run
# use launchy::Color;
# let (canvas, msg): (launchy::MockCanvas, launchy::CanvasMessage) = unimplemented!();
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
```no_run
use launchy::{OutputDevice as _};
use launchy::s::{Color, 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,
});
# Ok::<(), launchy::MidiError>(())
```
*/
pub use *;
pub use *;
pub use *;
pub use launchpad_s as s;
pub use launchpad_mini as mini;
pub use launchpad_mk2 as mk2;
pub use launchpad_mini_mk3 as mini_mk3;
pub use launchpad_midi_1 as midi1;
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";