Vitrinekast'ed annotated reader/Principles for Designing Computer Music Controllers

From XPUB & Lens-Based wiki
Revision as of 16:22, 28 May 2024 by Vitrinekast (talk | contribs) (Created page with " {| class="wikitable |+ Properties |- ! Type | reading |- ! Author | Perry Cook |- ! Year | 2001 |- ! Date read | 11/05/2024 |- ! Source | https://soundlab.cs.princeton.edu/publications/prc_chi2001.pdf?ref=dont-call-it-world-music.com |- ! Tags | annotated_reader, |} This paper mentions various creative midi controllers. Re-enforces the idea of <span style="background-color: yellow;">KISS</span>, or my personal lazy developer syndrome. Hacking by design creat...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Properties
Type reading
Author Perry Cook
Year 2001
Date read 11/05/2024
Source https://soundlab.cs.princeton.edu/publications/prc_chi2001.pdf?ref=dont-call-it-world-music.com
Tags annotated_reader,

This paper mentions various creative midi controllers. Re-enforces the idea of KISS, or my personal lazy developer syndrome. Hacking by design creates playability.

Statement in this paper: “Programmability is a curse”. Why? (MIDI) devices that contain various elements of programmability (the mapping/reconfiguring of buttons/interactions), creates a sea of possibilities, leaving the player waste time by , and i quote, writing papers and experimenting, instead of actually making art projects or compositions. This is very much my own problem, and why i do not enjoy using programming languages such as super collider or tidal cycles. When anything is possible, nothing is special, and I don’t spend enough time exploring what is actually already there.

This file was generated using pandoc: pandoc --from markdown --to mediawiki -o file.mediawiki {file}.md --template=/default.mediawiki