Cloudmix session: Difference between revisions
Line 11: | Line 11: | ||
Taking inspiration from "platform studies", a MIT book series, which includes the book [https://hub.xpub.nl/bootleglibrary/read/572/pdf Racing the Beam], a study of the Atari Video Computer System written by Nick Monfort and Ian Bogost (2009). This is a quote from their ''Afterword on Platform Studies'': | Taking inspiration from "platform studies", a MIT book series, which includes the book [https://hub.xpub.nl/bootleglibrary/read/572/pdf Racing the Beam], a study of the Atari Video Computer System written by Nick Monfort and Ian Bogost (2009). This is a quote from their ''Afterword on Platform Studies'': | ||
A computational platform is not an alien machine, but a cultural artifact that is shaped by values and forces and which expresses views about the world, ranging from “games are typically played by two players who may be of different ages and skill levels” to “the wireless service provider, not the owner of the phone, determines what programs may be run.” | <blockquote>A computational platform is not an alien machine, but a cultural artifact that is shaped by values and forces and which expresses views about the world, ranging from “games are typically played by two players who may be of different ages and skill levels” to “the wireless service provider, not the owner of the phone, determines what programs may be run.”</blockquote> | ||
And in the ''Series Foreword'': | And in the ''Series Foreword'': |
Latest revision as of 10:26, 4 November 2024
Tuesday 15 October 2024
Session: cloudmix, cloud-mixing, remixing-mixcloud... prototypes for exploring Mixcloud
After last session, in which we worked with Graphviz to explore how nodes and edges could be used to make scripts from our own experiences of collectivity...
Today we will focus on collectivity in a different way, by looking at computational platforms, to see how they operate as collective environments based on computational rules, cultural values and many decisions. Our study object: Mixcloud, an audio sharing platform.
We will take an explorative prototyping approach to study Mixcloud, the idea is to make a range of different web pages in response to/in conversation with Mixcloud as a platform.
Taking inspiration from "platform studies", a MIT book series, which includes the book Racing the Beam, a study of the Atari Video Computer System written by Nick Monfort and Ian Bogost (2009). This is a quote from their Afterword on Platform Studies:
A computational platform is not an alien machine, but a cultural artifact that is shaped by values and forces and which expresses views about the world, ranging from “games are typically played by two players who may be of different ages and skill levels” to “the wireless service provider, not the owner of the phone, determines what programs may be run.”
And in the Series Foreword:
[platform studies is] the investigation of underlying computing systems and how they enable, constrain, shape, and support the creative work that is done on them.
Translating this to Mixcloud, we can wonder how Mixcloud as a platform affects how people think about audio sharing. How does Mixcloud shape materials? Both the audio and the metadata around it? What kind of interactions does Mixcloud allow, which one not? And why?
When we look at Mixcloud, we could make observations like...
audio is only to be played as a standalone file, not in layers"
Let's try together: https://pad.xpub.nl/p/cloudmix
- How does Mixcloud shape the practice of audio sharing?
- And what does it not do?
In preparation of this class, i bumped into an interesting restriction of the Mixcloud API.
An API is a typical interface that platforms provide, an application (A) programming (P) interface (I), which makes it possible to interact with a platform through code... It's a very structured environment, which means that you can only have access to specific information and materials... for $reasons.
When trying the Mixcloud API, i bumped into the following message: https://www.mixcloud.com/developers/#audio-streams, saying that it is not possible to access the audio streams through the API... which, well, is eh, pretty restrictive for an audio sharing platform.
But! If we want to prototype with the audio materials, we can work around it :), with tools such as yt-dlp, curl/wget or the browser's console.
Because once we have the audio files, we can use a whole range of other tools like ffmpeg, HTML, CSS, Javascript, WebVTT, media fragments, Vosk ... to make all sorts of things. We can edit the audio files, display them differently, transcribe them, annotate them, make supercuts, ..., ..., ... and imagine other modes for audio sharing!
Can we make prototypes "in response to" Mixcloud, prototypes for imagining other modes for audio sharing? Prototypes to amplify the possibilities and/or limitations of this platform?
Or in other words... prototypes as platform studies?
Prepared materials
The following are possible starting points that i prepared.
They all use the command line and interact with the Radio WORM account on Mixloud.
stream segments
https://hub.xpub.nl/cerealbox/~manetta/cloudmix/stream-segments/
a prototype based on Mixcloud's 10 sec stream segments
using the command line to generate web pages
yt-dlp
https://hub.xpub.nl/cerealbox/~manetta/cloudmix/yt-dlp/
downloading Mixcloud streams as audio files plus metadata in JSON format
a prototype with Javascript to see how you can create alternative web pages with these downloaded files
api
https://hub.xpub.nl/cerealbox/~manetta/cloudmix/api/
retreiving metadata in JSON format from the Mixcloud API
(no prototype in this folder yet, see yt-dlp folder for an example how to import and use a .json file in a web page)
[EXTRA]
vosk
https://hub.xpub.nl/cerealbox/~manetta/cloudmix/vosk/
a few prototypes to see how transcription can play a role in listening/performing/sharing audio
annotate
https://hub.xpub.nl/cerealbox/~manetta/cloudmix/annotate/
a not finished prototype to explore what annotation could add to audio sharing
A few useful things
pipelines
The Unix shell works with a logic of so-called pipelines, that allow you to chain programs together. An example of a pipeline is this one:
$ echo hello | figlet
The output of a program is called STDOUT. You can connect STDOUT with the STDIN of the next program. You do this with a pipe, which is the vertical bar character "|".
By default, the STDOUT is written to your terminal. If you want to write STDOUT to a file, you can use the ">" character, for example in this way:
$ echo hello | figlet > hello.txt
Now check if this file is created and see what is inside, with $ cat:
$ cat hello.txt
JSON
JSON is a file format for storing and transporting data. JSON stands for JavaScript Object Notation. JSON works with a logic based on keys that are connected to values, like this: { "key" : "value" }.
- keys can be strings "hello", or numbers
- values can be strings, numbers, lists [] or dictionaries {}
An example of data formatted in JSON is:
{ "name" : "XPUB1", "students" : 17, "classes" : ["prototyping", "methods", "SI"] }
Many API's use JSON to send the information you asked for to you. You make an API call and it returns data in JSON.
curl
These are two tool you can use to handle network requests, for example to download files, or make API requests.
$ curl https://xpub.nl
Returns the HTML of the XPUB website to your current folder. ;--)
You can use also it to download files.
For instance, to make a copy of the prepared bash scripts:
$ cd public_html $ mkdir explorations $ cd explorations $ curl https://hub.xpub.nl/~manetta/cloudmix/api.sh > download.sh