This week we were to review the Cheat Sheet made by Nien & Sebastian. As well as create 1 controller that outputs a signal and 1 visualizer that processes the signal. “You can think of the controller as something with buttons, knobs, etc. and the visualizer will be like a processing sketch which updates based on the signal.”
Inspired by things like this:
Code Examples:
The signal will have 3 components contained in a struct. Note the allowed ranges:
struct Signal { // Range: 0 - 10 var intValue: Int // Range: 0 - 1.0 var floatValue: Float // True or False var toggleValue: Bool }
The Main Tester code will look somethings like this:
import SwiftUIstruct Signal { // Range: 0 - 10 var intValue: Int // Range: 0 - 1.0 var floatValue: Float // True or False var toggleValue: Bool }struct ContentView: View { @State var signal = Signal(intValue: 0, floatValue: 0, toggleValue: false) var body: some View { VStack { NiensController(signal: $signal) Spacer() NiensVisualizer(signal: signal) } .frame(height: 700) } }
Deliverables:
Before the start of next class, please Slack Sebastian and I directly with your 2 files and any required assets. We will take everyone’s controller and visualizer and wire it up to a master app allowing us to mix and match everyone’s components.
A controller file with your name. e.g. NiensController.swift
struct NiensController: View { @Binding var signal: Signal var body: some View { // // Add your buttons, knobs, etc. here. // Update signal appropriately. // Text("Controller") } }
A visualizer file with your name. e.g. NiensVisualizer.swift
struct NiensVisualizer: View { var signal: Signal var body: some View { // // Create visuals/animations here. // Text("Visualizer") } }
- Views should be no larger than 400×400
- If your views require image/audio/video assets, please send those along as well.
- Be creative with your design. Think about how standard buttons and sliders can be mapped in fun and novel ways.
- Consider using a timer and/or randomizer to modulate the signal over time.
- You may or may not require some internal @State for your component views based on their complexity.