Week 12: RESTful Project Part 2

This week we flushed out server-side programming for two RESTful project devices along with skeletons of their front ends.

Both devices are similar in that their clients update according to changes in data stored in a JSON object in the back end (and for this assignment, those changes are intended to be made with physical controllers made by other groups). For this we used P5’s loadJSON method (although I suppose httpGet() would work, too) at regular intervals to retrieve the data. I learned that this is called polling. Wondering what other methods we should consider (especially since this is not a socket server)?

For our Robo-Karaoke, see here.

For Alden and Beverly’s Super Cool VJ Machine, see here.

Week 11: RESTful Project Part 1

Ridwan and I thought it would be fun to make an audience-controlled karaoke machine, with controls for selecting a song video, playing and pausing that video, changing the playback rate, and giving compliments to the karaoke performer.

After some fits and starts, I’m starting to get the hang of how to create a web app with HTTP requests and routes. Talking it through in class, with peers on the floor, and with ITP Resident Alejandro (see his project from last year) clarified my thinking about how to approach this assignment. Coincidentally, in helping a student with their P5 data assignment this week, I found the GIPHY API documentation (see especially the section, Technical Documentation/Specifications) to be a useful example of a clearly-communicated RESTful API.

An API describes a system to access data from a web service. Often we see this data formatted in the HTML pages of the website, but often too, we can retrieve this data formatted in JSON. And REST is a framework or style for retrieving and manipulating that data.

Whether you are asking for or updating existing data, all actions are called a request. There are four common types of requests:

  1. GET for retrieving data from the server and/or for updating a resource (because values for doing so may be included in the URL, the request params)

  2. POST for asking the server to update or create a resource using the JSON-formatted data enclosed in its message (the request body)

  3. PUT for asking the server to accept and update or create a resources using the data enclosed in its message

  4. DELETE for asking the server to delete data

From HTTP Request Methods: “The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.”

Other resources I used this week:
The Definitive Node.js Handbook
Express Documentation
Shiffman’s Introduction to Node & Express

Our device gives the audience control over the song selection and playback of a karaoke video on a browser window that can be projected onto a screen. It is intended for die-hard karaoke fans in a room with people with whom they feel safe and ready for a good laugh. It is best-suited for use well into the group’s party.

We envision either a physical controller or a digital interface on mobile devices. Either option, however, impacts the game mechanics. With a physical controller, the audience shares or vies for control of it. With a digital interface, each audience member accesses the controller from their own phone and blindly competes with their fellow audience members to influence karaoke video playback.

As the audience decides the level of difficulty for the singer(s), the controller includes the option to send a random compliment to the screen to cheer them on.

Jason and Roxanne will build the controller. Ridwan and I will build the server and video player.

I built out part of the server for our device here.


See Song List
GET /songs
"songs": [
"Song Title by Artist",
"Song Title by Artist",
"Song Title by Artist",
"Song Title by Artist",
"Song Title by Artist"

Select Song for Playback
GET /select/:songid
songid: choose from range of 0-4 to match the index of the song in list
returns: songid
notes: this sets playing to true and playback rate to 1

Play/Pause Depending on Current State
GET /playing/
returns: false or true

Set Playback Rate
GET /rate/:value
returns: value of video playback rate

Display a Random Compliment
GET /compliment
returns: current compliment

Current System Status
GET /state
'songID': ‘value as string’,
'currentSong': ‘string’,
'isPlaying': bool,
'playbackRate': ‘value as string’,
'currentCompliment': ‘string’


Screen Shot 2018-11-19 at 1.33.45 AM.png



Week 10: Computing Concrete Poetry

I love programming concrete poetry! My first week’s project was a tip-off, but it was reaffirmed when I saw the work of Alyson Provax and Anatol Knotek this week. My original idea for this week’s sketch was to layer lines of words to build up images of the human form as infinite meanings seem possible from the combination of the two. But making slight alterations to this small snippet of code below produced so many variations, that I quickly realized much more time was needed to build myself a reference library of “brush strokes.” 

let word = 'obsessed';

function setup() {
   for (let i = 0; i < 400; i += 20) {
    let startX = windowWidth * 0.3;
    let startY = windowHeight * 0.2;
    let div = createDiv(words);
    div.position(startX, startY + i);
    div.size(200, 200);
    div.style('font-family', 'monospace');
    div.style('font-size', '32px');
    div.style('letter-spacing', '0.1' + i/4 + 'em');
    div.style('transform', 'rotate(0' - i + 'deg)');

Not a surprise then that I got lost in a rabbit hole of iterations. I know there are many more parameters to add to the above (color, font family, skewed transformations), but changes to any one of the current ones completely alters the output: number of letters, number of loop iterations, div size, div position, font size, letter spacing, the starting degree of rotation, and the transform origin. It’s super fun but also maddening at times to figure out how to work deliberately. So I played and created few iterations for this week’s prompt but look forward to revisiting this again. 

Homage to Alyson Provax:

Getting closer to brush strokes here:

Just can’t get this out of my mind for some reason:

Play with the code here:
All the Time