Module queue 

Request pacing (docs/03): the pedal handles one SysEx request at a time, so requests and writes are queued and each waits for its reply or ack before the next is sent, like the official app. Live CCs/PCs carry no reply and need no queue.

RequestQueue is the pure state machine (no I/O, time passed in) that device drives; use it directly to talk to the pedal over your own MIDI transport:

use std::time::{Duration, Instant};
use open_stomp::queue::{RequestQueue, handshake};
use open_stomp::Msg;

let mut q = RequestQueue::new(Duration::from_secs(1));
q.start_sync(handshake());
// loop: send what the queue releases ...
while let Some(req) = q.pop() {
    // out.send(req.bytes())?;
    q.sent(req, Instant::now());
}
// ... and feed it every complete message from the pedal
let reply = [0xF0, 0x00, 0x21, 0x7A, 0x10, 0x56, 0x31, 0xF7];
assert!(q.on_message(&Msg::parse(&reply)).is_some());
assert_eq!(q.progress(), (1, handshake().len()));

Structs

Done

How an in-flight request ended.

Request

One queued outgoing message.

RequestQueue

Queue of SysEx requests and writes with at most one in flight.

Enums

Expect

What answers a request.

Functions

follow_up

Follow-up reads after pedal-side changes that carry no data themselves: a preset saved on the pedal (re-read it and the edit buffer) and the tuner toggled (read its state).

handshake

The official app’s startup reads (docs/03), all read-only. Presets come before the edit buffer so the active preset can be identified by matching the edit buffer against them (see DeviceState).