First steps

This session needs nothing but Signal Lab: everything goes to 127.0.0.1, this computer, so no device, network or firewall rule is involved. You will:

1. send an OSC message and watch it arrive;
2. see the same message in the Inspector;
3. save it to the library and send it again from anywhere;
4. start an emulated HTTP API and ask it something;
5. run an experiment against that API, read why it fails, fix it and add a check.

If you have not installed Signal Lab yet, see Installing and updating. Not sure where something is in the window? See The window.

Send an OSC message and watch it arrive

First, something to receive the message: the OSC screen's monitor.

1. Open OSC in the sidebar.
2. Under Monitor, set Bind address to 127.0.0.1:9000, so the monitor listens on this computer only.
3. Press Listen. The button becomes Stop, the console says the monitor is listening, and the monitor appears as a job in the bottom panel's strip.

Now the message, from the sender beside it:

4. Under Sender, leave Target host:port at 127.0.0.1:9000, the port the monitor listens on.
5. Leave OSC address at /hello/avatar/1 and the one float argument under Arguments at 1.0 — or type an address and values of your own.
6. Press Send, or Enter in the target or address field.

A line appears in the monitor's table: the Time it arrived, From (127.0.0.1 and the port it was sent from), the Address and the Args. Under the sender, a line confirms what was sent and its size in bytes; send again and it counts the repeats.

A notice about the firewall?

On Windows, starting the monitor may bring up a notice under the header about Windows Firewall. It is about messages from other machines; traffic on 127.0.0.1 is never filtered. Press Not now for now — The firewall notice explains when to allow it.

See it in the Inspector

The Inspector records every frame every tool sends and receives — but only while capture is on.

1. In the bottom panel, open the Inspector tab.
2. Press Arm capture. The tab's dot lights up.
3. Back in the sender, press Send once more.

Two rows appear, newest first: the message as sent (→) and as the monitor received it (←), each with its protocol, the other end's address, its size and a summary. Click one: Frame detail shows which tool sent or received it and on which addresses, the message Decoded, and the Bytes it was made of.

Press Disarm capture when you are done; while capture is off it costs nothing. More in Inspector.

Save it as a signal and send it again

A message you will want again belongs in the signal library.

1. On the OSC screen, press Save… under the sender.
2. In Save to the library, set Name to First message and Folder to Tutorial — a new folder is made as you save into it.
3. Press Save.

The sender is now tied to that signal: the button says Saved, and a chip beside it shows where the signal lives. Change the argument and the chip notes the change; Save (Ctrl+S) would update the signal.

Now send it again, three ways:

• From the library. Click the chip: Signals opens with the signal selected in the Tutorial folder (or open Signals and click it there). Press Send, or Ctrl+Enter; a double-click on it in the list sends it too.
• From anywhere. On any screen, press Ctrl+K, type first, and press Enter.
• From an experiment. When you add a node, the menu lists your signals under Saved signals, ready to become a step that sends one.

Each time, the monitor shows the message arrive and the console names the signal. A signal sends exactly what its screen would have sent. More in Signals.

When you are done with OSC, press Stop on the monitor.

Ask an emulated API

Signal Lab ships with five emulators, all on 127.0.0.1. One of them, the Demo API, is an HTTP API on 127.0.0.1:8080 with these routes:

Request	Answer
GET /health	200 with {"status":"ok","time":"…"} — the current time
GET /users/:id	200 with the user of that id, such as {"id":"42","name":"User 42"}
POST /users	201 with a Location header and the new id
GET /slow	200 after 1.5 seconds
any method, /flaky	503, 503, then 200 from the third request on
anything else	404

1. Open Emulators. The Library lists the five; select Demo API.
2. Press Start. It now answers on 127.0.0.1:8080 and runs as a job.
3. Open HTTP. The method is GET; set the URL to http://127.0.0.1:8080/health.
4. Press Send, or Enter in the URL.

Under Response you see the Status 200, the Latency, the Size, the response headers and the JSON body. Send http://127.0.0.1:8080/flaky three times: two 503 answers, then 200 — the way a service that recovers looks to a client that retries.

Back on Emulators, the Live panel counts every request, and Received lists each one with the Rule that answered it and the Reply. Leave the Demo API running for the next part. More in Emulators.

Run an experiment

An experiment is a flow of steps you can run again and again. The one Signal Lab opens with the first time — the HTTP check template — sends a request to http://127.0.0.1:8080/ and checks that the answer is 200.

Open the template

1. Open Experiments.
2. If the canvas does not show four nodes — Start, HTTP request, HTTP status, End — press ☰ at the left of the toolbar (Experiments), pick HTTP check in the list of templates, and press Open experiment. Opening replaces the experiment on the canvas; Ctrl+Z brings the previous one back.

Click a node to see its settings in Properties on the right. Experiments save themselves as you edit.

Run it and read why it fails

3. Press Run experiment.

The Run timeline opens under the canvas, one row per step as it starts (Running) and again as it ends: the time, the node, and how it went. This run fails:

• Start passes and names the run's seed.
• HTTP request passes: the request went out and an answer came back, HTTP 404.
• HTTP status fails: it expected 200 and received 404.

The Demo API has no route for /, so it answered 404 — and the check caught it. The line at the top of the timeline says Failed and why. Click a row to select its node on the canvas.

The request itself failed?

If the HTTP request step fails with a refused connection, nothing is listening on 127.0.0.1:8080: start the Demo API on Emulators and run again.

Fix the request

4. Click the HTTP request node.
5. In Properties, change URL to http://127.0.0.1:8080/health.
6. Press Run experiment.

This time every step passes: HTTP status says Condition satisfied, End says Complete, and the timeline's title says Passed.

Add a check

A status of 200 says the service answered; it does not say what it answered. Check the body too:

7. Click the HTTP status node.
8. In Properties, press Add next — or press A with the canvas focused. A menu of nodes opens with a search field.
9. Type assert_body and press Enter. A Response text node is added between HTTP status and End, already wired, with its Contains text field ready for typing.
10. Type "status":"ok".
11. Press Run experiment.

The new step passes. Change the text to something the body does not contain and run again to see it fail with the reason.

What a run leaves behind

• A report. When a run ends, Report saved appears in the timeline's title; hover it to see the file. A run that ends, passed or failed, writes one into the runs folder of your data folder, with the values it used and every step. In a browser it is a download link.
• A seed. The title also shows the run's seed with Pin: random values in a run follow its seed, and pinning it repeats them exactly.

More in Runs and reports.

Clean up

Press Stop all in the header: it stops the Demo API and anything else still running. Your signal, the experiment and its reports stay in your data folder.

Where next

• Concepts: the ideas behind screens, signals, jobs, emulators and experiments.
• Experiments: the editor in full, and every kind of node in Nodes.
• OSC, HTTP and the other protocols' pages, when you point Signal Lab at real gear.
• The command line: run the same experiment from a terminal or a pipeline.