Struct launchy::InputDeviceHandlerPolling

pub struct InputDeviceHandlerPolling<Message> { /* private fields */ }

A handler for a Launchpad input connection that can be polled for new messages. The actual polling methods are implemented inside MsgPollingWrapper. Look there for documentation on how to poll messages.

Trait Implementations

impl<Message> MsgPollingWrapper for InputDeviceHandlerPolling<Message>

type Message = Message

The type of message that is yielded

fn receiver(&self) -> &Receiver<Self::Message>

Returns a std::sync::mpsc::Receiver that yields messages, where the type of messages is described by the associated Self::Message type

fn recv(&self) -> Self::Message

Wait for a message to arrive, and return that. For a non-block variant, see Self::try_recv.

fn try_recv(&self) -> Option<Self::Message>

If there is a pending message, return that. Otherwise, return None.

fn recv_timeout(&self, timeout: Duration) -> Option<Self::Message>

Receives a single message. If no message arrives within the timespan specified by timeout, None is returned.

fn iter(&self) -> Iter<'_, Self::Message>

Returns an iterator over all arriving messages. The iterator will only return when the MIDI connection has been dropped.

fn iter_pending(&self) -> TryIter<'_, Self::Message>

Returns an iterator over the currently pending messages. As soon as all pending messages have been iterated over, the iterator will return.

fn iter_for(&self, duration: Duration) -> IterFor<'_, Self::Message>

Returns an iterator that yields all arriving messages for a specified amount of time. After the specified duration has passed, the iterator will stop and not yield any more messages.

fn iter_for_millis(&self, millis: u64) -> IterFor<'_, Self::Message>

Returns an iterator that yields all arriving messages for a specified amount of time. After the specified duration has passed, the iterator will stop and not yield any more messages.

fn drain(&self) -> usize

Drain of any pending messages. This is useful on Launchpad startup - the Launchpad has the weird property that any button inputs while disconnected queue up and will all be released at the same time as soon as someone connects to it. In most cases you don’t want to deal with those stale messages though - in those cases, call drain() after establishing the connection.