User:Francesco

Hello this is a log of things from kamo or Francesco. This is a wiki version of my Documentation Workout on the Soupboat. This is an automatic log. Design WIP

SI16 Vernacular Language Processing

Text Traversing

• Which texts will you traverse? will you make a “quote landscape” from the different texts brought today or stay with one single text?
• Identify patterns / gather observations / draw the relations between the words/paragraphs/sounds
• What are markers of orientation you would like to set for this text?
• Where should the reader turn?
• What are the rhythms in the text and how can they be amplified/interrupted/multiplied?
• Make a score or a diagram or a script to be performed out loud

Process

What if we could use some excerpts from all of what we are reading now as lifeboats in a sea of text? An attempt to play around with the continous permutations between contents and contexts.

Slow Processing

• if NLTK is a form of mapping language, vltk is a form of mapping language from a particular vantage point
• pick a text or a collection of texts from the pad from last week or the one of this week
• choose a linguistic pattern to apply over the text, for example: all verbs, every third word of a sentence, the 50 most used words, collocations you observe, words with multiple meanings, x of y, question marks etc. the processing can be both manual or automatic.
• what is the output?

Weaved with Jian and Emma

Reader Prototyping

• take suggested methods, use something we already used already - work on it, elaborate, don’t exclude what we’ve been doing with Manetta, Michael and Cristina go in smaller groups/individually and make a prototype - network of texts,
• something visual, reworking of something and what it can be a sensible way to explain to people
• come together at 15:30? and we share what we’ve done - talk about how can we stitch it together to make a reader

Aggregating different things ~ output: chat form

Levels

• 🏸 1 touch the inputs
• 🏸 2 overlap/merge them a bit
• 🏸 3 mesh them completely

Process

• 🏏 take an academic text and turn it into a chat - translating into vernacular;
• 🏏 simplify the text
• 🏏 break it into chats
• 🏏 illustrate some bits

Starting from a difficult but relatable text: our multi voiced pad of the day.
Parsed here: Spreadsheet ghost

Rules to manipulate text:

• 🏑 table of contents - shorts contents - tag them
• 🏑 turn into chat bubbles
• 🏑 illustrate a few

Rules of text simplification (as ⛳️ objective ⛳️ as possible):

• 🏓 simple sentences
• 🏓 on point
• 🏓 short paragraphs and short chapter
• 🏓 title on each paragraph
• 🏓 text could become image caption/illustrate chapters/graphs?
• 🏓 page number
• 🏓 navigation (table of contents)

Demo offline:

<video src="/soupboat/~kamo/static/video/chat_reader.mp4" autoplay loop> </video>

Video Transcribing

SI16 - with Cristina and Manetta

In groups of 2-3:

1. Decide a video to transcribe (max 10 min)
2. If you can’t decide on one, take 3-5 minutes to think about a subject of everyday knowledge that is particular to a location/group. Record yourself telling the story
3. Transcribe individually either the video or your own recording
4. Compare the transcriptions

fun with Kimberley + Carmen

Karaoke as a mean of republishing

The idea is easy: take some songs, take some texts, and merge them through the logic of karaoke. For our first issue we want to work with Simon Weil’s diaries as text material and Franco Battiato’s songs as musical starting point.

Using a popular and performative device such as karaoke we want to join different voices. Not only the ones from the people singing, but also from all the different authors that participate in this event: the writer of texts, the composer of musical bases and the musicians that will perform them. This project started as a joke and eventually growed because we saw a lot of potential in it.

File:/soupboat/~kamo/static/img/k-pub/karaoke recipe.png

caption karaoke recipe

Christmas Update

Ok we got the room of the little Room for Sound at WdkA: nice. So here is a list of things we need and a list of things to do:

TODO:

• text from simone weil
  • select excerpts
  • excerpts to lyrics
• audio from franco battiato
  • select songs
  • find or write midi files
  • sound design
  • performance mode
• visual
  • finish setup record mode (excerpts → lyrics)
  • setup playback mode
  • design
  • development
• performance
  • call musicians
  • space setup
  • technical setup
  • comunication
  • documentation
  • pubblication
• residency
  • daily contents to be published on their radio (readings, log, musical experiemnts…)

workflow for 1 song:

1. select text excerpts
2. select song
3. song to midi
   1. if there is already a midi: cleanup: split and join tracks meaningfully
   2. if not: song transcription
4. karaoke recording
   1. input: midi song, text excerpts
   2. process: performative conversion, excerpt to lyrics tool
   3. output: karaoke midi song with text track
5. karaoke performance
   1. input: karaoke midi song
   2. output: karaoke text, karaoke midi
      1. midi → text, display the text for singin along
      2. midi → audio, for live playing and real time sound design of the song
      3. midi → visual, for live visual effects

people we need:

• musician (at least 1 to start with) (micalis? gambas? others?)
• visual (open call? or we can do it on our own for this)
• event logic & logistic (chae? gersande? etc? if anyone wants to take care of the setup it would be super cool)
• documentation (pinto? carmen? etc?)

How could computer read concrete & visual poetry? How does computer navigate through text objects in which layout and graphical elements play a fundamental role?

With this tool you can upload an image and then annotate it spatially. In doing so you generate a transcription of the image that keeps track of the order of your annotations (and so the visual path you take when reading the image), as well as their position and size.

Neither the image nor the labels nor the transcription will be uploaded online. Everything happen in your browser.

a join research with Supi 👹👺

Test for an API-based special issue

• The backend is developed with node.js and express
• Each URL is mapped to a python script. The argument are passed to the script, processed and then returned as JSON
• We start with 2 functions: 1. a find and replace and 2. a shout

(update: hei this is not active anymore! but we really did an API at the end! aha!)

Wait what why an API

File:/soupboat/~kamo/static/img/api bikes.jpg

caption two half bikes attacched with tape and two kids pretty satisfied with their work

This is to show what an API could be in relation to the exercises we usually do during the prototyping class. It is a way to render public a piece of work that usually stays behind several layers of accessibility. The idea of the special issue as an API could be a curated collection of what we are doing since september within a critical context. 🤯

Find and Replace

Find a target string in a text and replace it with the given replacement. The parameters are three.

• text the text in which perform the research
• target the string we are searching for
• replacement the string we want to insert in place of the target

The endpoint is:
https://hub.xpub.nl/soupboat/cat-api/replace?text={text}&target={target}&replacement={replacement}

Overview

The special issue is composed of three main parts: the library, the projects and the launch event. Each one of these has a slightly different nature, and so can access to different kinds of public. Imaging the SI16 as an ecosystem around these three faces permits us to create an organic form of public: someone comes for the event and discovers an API, someone else arrives from the code and is introduced to the critical context around it, each project tho is situated in a specific thematic niche and the interactions with the whole ecosystem could provide fresh air to spin mill.

A systematic approach in the contents’ structure enables us to morph our projects without sacrifice the unique nature of each work. What’s more is that with a clear data structure we can deliver contents in different forms with less effort and less stress.

The following structure is a draft. The order of the elements is not defined nor fixed. Some things are not mandatory, but would be nice and useful to have them if we think to the future life of the SP16 after the launch. The idea is to build something easy to scale, to expand, and to update. Something easy to participate. As an ecosystem some parts are more likely to grow and to evolve, and to provide a good soil as starting point maybe is the best thing we can do?

1. Library

A collection of modules and tools within a context

The library is the main container of the SP16. It provides a list of algorithms and describes the world in which they operate. This world is our source of truth: it is built from all the corpora we will aggregate and use for the projects, as well as other critical contributions, inquiries about the vernacular, and guide to navigate through all the materials. Ultimately a library, or a toolkit, is orientated. Its political stance stands not only in its contents, but also in the way it grants access to them. The relation between authors and public is not based only on power, but here also in trust, and collaboration, and dependency, and mutuality.

Hence the library is part contents, part tools, part documentation, part showcase. These sections could be open and do not have to be perceived as finished. A library is always a work in progress, a work that we are starting now, a work that then someone else can continue.

Beside the contents and their structure, the library also include a showcase section to display all the projects we are working on now. This section strengths the link between the special issue as a publication and the special issue as an event. In order to preserve the original approach of each project an in depth record of each work is provided here. It is perceived as something sprouting from the library. Are the projects and the special issue publication the same thing? Maybe not, but for sure they are deeply related.

File:/soupboat/~kamo/static/img/lib-structure.svg

caption Library

• Title, The name of the library
• Description, An overview of what it does, how and why does it exist
• Context, A collection of materials (researches, essays, excerpts, …) that situate this library in relation with the vernacular
  • Manifesto, Our attitude, our purposes, our plan. It could work as an introduction to the special issue
    • Our plan, A summary of the research in terms of intentions
    • Our attitude, An overview of the different approaches we used
    • Our purposes, What do we want to achieve or encourage
  • Materials - Corpora, Collections of materials used as sources or collected for the projects
    • Corpus, Single corpus of materials used as sources for the projects
      • Title, A title for the corpus
      • Description, An overview of the contents and how they are structured
      • Type, The kind of materials included
      • Structure, A description of the structure of the contents
      • Contents, List of contents
    • …, […other corpus in the list]
  • Research and Development, A collection of contribuitions (researches, essays, excerpts, …) that situate this library in relation with the vernacular
    • SP16 History, Evolution of the SP16 work, devlog, excerpts from the pads, etc
    • List of contribuitions, Collection of essays, excerpts from the texts read in class, piece from the tutors, from us, etc
      • Contribuition, Single contribuition in the list
        • Title, Title of the contribuition
        • Description, Description of the contribution
        • Subject, Theme of the contribution
        • Contents, Contents of the contribuition
        • Credits, Credits and references
      • …, […other contribuitions in the list]
  • Guide, Presentation of the form of the SI16 and its structure, how to read it and navigate it
    • Getting started, First steps into the SP16 as an API
    • What is a documentation, How the documentation is structured
    • Learning how to walk while catwalking, Navigation through the special issue
• Showcase - List of Projects DocumentationsS, howcase of full fledged and meaningful project built within and from the library, list of projects documentations
  • Project Documentation, Documentation of a project
    • Contents, Extended description of the project, including the research, the process and the future possibilities
      • Research, Background of the work, field of intrests, ideas, theory, etc
      • Process, History of the work, process of development, prototyping, etc
      • Outcomes, Results of the research and synthesis of the process
      • Direction, Possibilities for the evolution of the project, new applications, ideas, findings
    • Documentation, Nice showcase of the work
      • Text, Textual description of project and key findings
      • Visual, Visual documentation such as pictures, videos, etc
      • *, Other specifications are unique for each project
    • References, Reference to the corpora or materials used and to the tool involved during the production
      • Materials, Corpora and sources used or created for the project
      • Theory, References for specific theoric notes
      • Codes, Modules, functions and parts of the library involved in the work
  • …, […other projects documentations in the showcase]
• List of Modules, A list of all the different code approaches, or modules, that compose the library
  • Module, A thematic or reasoned group of functions
    • Title, The name of the module
    • Decription, A description of what it does
    • Applications, Examples of applications that use several functions to build complex procedures
    • List of functions, A list of functions
      • Function, A single function in the module
        • Title, The name of the function or algorithm
        • Description, A description of what it does
        • Input, The types of inputs it receives
        • Codes, The procedure it follows
        • Output, The types of outputs it returns
        • Example, Simple and specific examples
      • …, […other functions in the module]
    • …, […other modules in the library]

2. Project

Full fledged and meaningful work built within and from the library

The main feature of having several serious different projects is both that we can explore different shades of the vernacular language processing and that we can access to different kinds of public. It is true that we are in needs for more time now, but at the same time having different projects to work on

File:/soupboat/~kamo/static/img/proj-structure.svg

caption Library

• Title, Title of the project
• Description, Description of the project
• Colophon, Credits and colophon
• Project Object, Concrete outcomes of the project
  • Object, Concrete result of the work
  • *, Specifications are unique for each project
• Project Documentation, Documentation of the project
  • Contents, Extended description of the project, including the research, the process and the future possibilities
    • Research, Background of the work, field of intrests, ideas, theory, etc
    • Process,History of the work, process of development, prototyping, etc
    • Outcomes, Results of the research and synthesis of the process
    • Direction, Possibilities for the evolution of the project, new applications, ideas, findings
  • Documentation,Nice showcase of the work
    • Text, Textual description of project and key findings
    • Visual,Visual documentation such as pictures, videos, etc
    • *, Other specifications are unique for each project
  • References, Reference to the corpora or materials used and to the tool involved during the production
    • Corpora, Corpora and sources used or created for the project
    • Theory/contributions,References for specific theoric notes
    • Codes, Modules, functions and parts of the library involved in the work

3. Launch

@Varia on 17.12.2021

File:/soupboat/~kamo/static/img/launch-structure.svg

caption Library

• Space setup, Display and physical setup of the space
• List of presentations, List of moments in which the different contents of the SP16 are presented to the public
  • Presentation, Moment like performance, presentation, talk, workshop, panel, etc
    • Title, Title of the presentation
    • Description, Description of the presentation
    • Subject, Theme of the contribution
    • Type, Kind of presentation: talk, panel, showcase of a project, performance, etc
    • Contents, Contents and theme of the presentation
  • …, […other presentations in the list]
• List of projects objects, List of physical outcomes from the projects
  • Project Object, Concrete outcomes of the project
    • Object, Concrete result of the work
    • *, Specifications are unique for each project
  • …, […other project object in the list]

A little test for the Special Issue 16 website developed with Nuxt.js for the frontend and Strapi as CMS / backend. Our Python functions can be uploaded in the CMS and then exposed as an API for the public usage.

<video src="/soupboat/~kamo/static/video/test-strapi-python.mp4" autoplay loop> </video> <video src="/soupboat/~kamo/static/video/test-si16-nuxt.mp4" autoplay loop> </video>

Design proposal

A super teamwork with Chae, Emma, Supi + the incredible visual package from the Visual Identity group You can see the final result at Learning How to Walk while Catwalking

File:/soupboat/~kamo/static/img/si16-frontend/Intro.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Home.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/About.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Snippet Research.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Manifesto.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Functions.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Function.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Projects.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Project Documentation.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Showcase.jpg

caption Library

A script that let you add stickers on top of HTML elements. To make it works just add a data-sticker attribute to your element. The content of the sticker will be the value of the attribute.

<div data-sticker='Hello'>World</div>

This script was used for the SI16 - Learning how to walk while cat-walking website. This is a simplified version. In the original one we had to deal with fixed elements (such as the header / nav of the pages) as well as relative ones. So the code there is a bit messier, but this one here it’s simple and clean.

How does it work

The code it’s composed of 3 main functions: one to create the sticker, one to spawn and attach it to an element, and a last one to limit the amount of stickers spawned at once.

propper documentation coming sooon

This project is a multiplayer branch of the Concrete Label tool, developed in the context of the SI16 &&& is a super collaboration with Supi, Jian, Kim, Alex, and Emma. The description is a porting of the documentation that you can find along with the various showcases on the SI16 website.

How do we bring multi-vocality in the work of annotation? The Annotation Compass builds composites from aggregated vernacular impressions, rich of their subjectivity and situatedness. It is the outcome of a three months journey questioning the relationship between vernacular languages and natural language processing tools.

First Experiments

The living-room

File:/soupboat/~kamo/static/img/map description H.jpg

caption Supi’s livingroom

For this experiment, four of us were gathered in a living-room.

• Number of participants: 4
• Location: Supi’s living room
• Aim: Map out each participant’s impressions of the living room.
• Material: The living room’s floor plan, InDesign, computers…..
• Time-frame: 5 minutes
• Instructions: individually annotate the floor plan with impressions of the living room

After removing the floor plan and looking at the subjective annotations of this experiment, we observed that each outcome forms another ‘space’. Each person’s set of annotations brings a unique perspective of the living room , an ‘individual map’. We then layered the individual maps and the compilation resulted in a vernacular picture of the space. This alternative understanding of the space can only be given to a reader through those descriptions.

Still from Michael Snow’s Wavelength

File:Https://pzwiki.wdka.nl/mw-mediadesign/images/3/3e/Selection process 2.png

caption Michael Snow, Wavelength

The same method was applied to the photograph of a room. Each of us used a different set of coloured sticky notes and took 5 minutes to physically annotate the picture on the same surface. The picture was then removed from the background, resulting in a similar outcome as the experiment described above.

From these observations, our interest on subjective annotations that could flow in a common understanding of an image grew. As a tool to collect situated impressions, we elaborated the idea of the Annotation Compass.

On a given surface, such as an image, the tool facilitates the collection of annotations and their coordinates from various users simultaneously. These annotations represent individual knowledges and perspectives in regards to the given surface.

Michael Snow, Wavelength Michael Snow, Wavelength

Instructions

To use this tool, let’s consider the “host” any person interested in gathering annotation on a specific image; and the “guest” any person invited by the host to annotate the image.

Process for the host

1. upload an image
2. add a text to explain the context of the image or to give instructions and helpful advice to the guests
3. send link to guests and invite them to annotate
4. download a json-file or text-file that contains the collected data that was gathered so far
5. try the different functions of SI16 to filter the collected dat

Process for the guest

1. open the link sent by the host
2. read the information attached to the image by the host
3. use the cursor to select a specific area that you want to annotate
4. write and insert your annotation(s)a

The data

The Tool not only archives the annotations, but also additional meta-data that can be helpful to analyze the outcome. The collected data is stored in a “json-file” that comes as a list of labels. In each label, one can find the file name of the annotated image, the coordinates of the annotation, the dimension of the annotation ‘box’, the annotation itself, the index number of the annotation and a user identification:

{
    "image": "filename.jpg",
    "position": {"x": 12, "y": 97},
    "size": {"width": 43, "height": 18},
    "text": "Content of the annotation",
    "timestamp": "Wed, 01 Dec 2021 14:04:00 GMT",
    "userID": 123456789
}

• image: a reference to the filename of the image
• position: x and y coordinates given in percentage, relative to the top left corner of the image
• size: width and height given in percentage, relative to the size of the image
• text: the text content of the label
• timestamp: the moment in which the label was uploaded
• userID: a random generated id to keep track of the autorship of the labels

for the future: at some point could be intresting to something like a components property, in order to make the tool more flexible and open to plugin or integration. Ideally this property is a list of components, and each one can add some kind of info or metadata for specific usecases, without the need to rewrite all the code to make room for that.

The outcome provided by the Annotation Compass is ever-changing: whenever an individual adds an annotation, the data grows.

After applying the tool to different projects we observed that the collected data can offer a reflexion on the so called “objective”: It provides individual perceptions and builds a common experience by including a multiplicity of impressions rather than one objective definition. In conclusion, the Tool can be used to provide alternative ways to define images, images of space, texts, and anything else annotatable.

Possible applications of the tool:

• Ask individuals to annotate the space they are in at the moment.
• Ask individuals to annotate a space from memory.
• Ask individuals to annotate imaginary spaces. (e.g. a space from a dream, a fictional space they know from a novel, a place that exists but they never went …)
• Ask individuals to annotate a space before and after they went for the first time.
• Invite individuals to a space and ask them to annotate it as a performative act that is situated not only in space but also time.
• Ask individuals to annotate a space whenever they want (unlimited access).
• Ask individuals to annotate a public space.
• Ask individuals to annotate a whole city, country, continent …
• Ask individuals to annotate a private space.
• Ask individuals to annotate an indoor space (bedroom, library, central station, theatre …)
• Ask individuals to annotate an outdoor space (park, market place, beach …)
• Ask specific groups to annotate a space (queer, teenagers, people with disabilities, immigrants …)
• Ask individuals to annotate specific things, e.g. emotions, colors, surfaces, light …
• Ask individuals to only use specific glyphs (e.g. ! ? and –) or emojis to annotate the space to include those not confident using words.
• Encourage individuals to use their mother tongue / slang / informal language to annotate a space.
• Ask only one individual to give many annotations of a space over time (daily diary, yearly check-in …)
• Ask individuals to annotate different spaces (e.g. their own living rooms)
• Ask individuals to annotate a space without using a standard map but rather an empty sheet as a starting point.
• Ask individuals to annotate a space without using a standard map but rather an individual map or vernacular map as a starting point.
• Ask individuals to annotate a space without using a standard map but rather a photograph of a space as a starting point.
• Ask individuals to annotate a space in real life (e.g. using sticky notes, writing on plexiglass, interview) and use the tool to insert the data afterwards.
• annotate a photograph (portrait, scene, landscape …)
• annotate a painting
• annotate a text
• annotate a song/sound
• misusing the tool

Familiar and flexible

Each contribuition to the SI16 API was unique. Both the subgroups’ projects and their documentation had different voices, different ways of presenting the contents, and different needs. This specificity required a system that was structured enough to keep together each pace, but remained flexible, in order to let anyone express her own approach to the Special Issue.

With the SI16 being at the same time a set of functions, a playground to experiment with it, and a list of meaningful projects developed within their context, we structured the backend as an interface between the different parts of the work.

The main idea was to define a pipeline that was not so different from the processes and technologies we learned and explored during the first trimester.

Functions

We chose to work with the Jupiter Notebook format we were familiar with, as a way to both collect and document our functions. With a common protocol defined within us and some 🐍 pythonic 🐍 (omg this term is cringe ah ah) good practices, we wrote a Notebook for each function. In each file there was the definition of the function, as well as a propper documentation and some examples on how to use it.

A big part of the backend work was to let anyone structure their own notebook freely, deciding how to present the process and the result of each contribuition without forcing a structure. At the end the Flask application was designed to scan all the notebook folder and extract from it the function, as well as their input and output, and the documentation.

With those information we generated an interactive page for each function in which the user could try and play around with our functions exposed as an API.

Projects

The organic process of SI16 led us to a collection of several interconnected projects. Each one of them had grown around a specific implementation of the functions we developed for the API. Those complex applications were initally developed as standalone Flask app, and they were merged all together at the end. (well, ok, after the end to be honest)

One thing we could do differently next time is to use Flask’s Blueprints as a way to work in a more flexible way. At some point we were really struggling about how to manage the code and the collaboration on it. Now that we have an overview of how Python works, it could be nice to develop our projects in a more modular way. BTW we used the documentation pages as a gateway to the projects, in order to have a common starting point.

Things got a bit complicated when the subgroup I was in started to working on sub-sub-project. And to face that we made the structure open to the possibility to nest projects one into the other, in order to have again flexibility between documentation and interaction on the website, and still a (kinda) structure in the filesystem.

Actually: we were totally new into this, so probably half of the things we did were not just wrong, but illegal. BTW we are still learning so next time it will be better, deal with it.

disclaimer there are some problems with the xpub git so the source code is still not totally public, but we are working on it. There the code is annotated and each function is documented so I will not go more in detail here for now.

Project structure

si16
├── contents
├── notebooks
├── projects
│   ├── and-i-wish-that-your-question-has-been-answered
│   ├── annotation-compass
│   │   └── showcases
│   └── etc-portal
├── si16.py
├── static
│   ├── corpora
│   ├── css
│   ├── event
│   ├── font
│   ├── img
│   ├── js
│   └── uploads
└── templates

• contents contains a list of markdown file for generic pages. For example the route /si16/intro will search and load the contents from the intro.md file in this folder.
• notebooks contains a list of Jupiter Notebook files, one for each function we developed for the API.
• projects contains a list of folder one for each subgroup project. Each one has a documentation.md file with the main contents and process of development.
• showcases is a optional folder in each project for nesting other sub projects in the sub project. Convoluted but useful and flexible.
• si16.py is the main module for the Flask app and the backend duties.
• static contains all the different files that are served statically from the webserver such as images, stylesheets, javascript files, etc.
• templates is a Flask folder that contains the HTML templates for generating the frontend pages.

Ciao ciao

A micro CMS

During the first weeks at XPUB I spent some time trying to figure out how to archive and log the various projects going on. I felt to do it here in the Soupboat, because it’s more flexible and playful than the wiki, that remains of course the source of truth and the future-proof archiving system etc. etc. 👹👺

After the second page though I was already ultra annoyed by the fact of rewriting or copy-pasting the HTML from a page to the other to keep at least a bit of style and structure and add contents manually. I wrote then a bit of code to have a default page and then used a JSON file filled with a list of projects. The script traversed this list and created a table with the basic informations about each one.

The model for a project was something like that:

{
    "title": "Text Weaving",
    "date": "Oct 5, 2021",
    "url": "10-05-2021-weaving/",
    "git": "https://git.xpub.nl/kamo/text_weaving",
    "pad": "https://pad.xpub.nl/p/replacing_cats",
    "links": [
        {
            "url": "",
            "title": "",
        }
    ],
    "categories": [
        "Python",
        "NLTK",
        "Text"
    ]
},

Each proj has a title, a date, an URL to a dedicated page. Then a list of links: the git repository for sharing the source code and the pad, that are the two most common types of link, and then a list of generic other links, each one composed by an URL and a title. There is also a list of categories, in order to give some hints about the project.

The dedicated page for a project could have been something somewhere in the Soupboat, or a subfolder in my personal folder.

The structure of the whole thing was: an index.html page with a cms.js script and a cms.json file. (Such imagination in these filenames). Then a style.css and a global.css for sharing the style with the various projects.

Not really a revolutionary CMS but a starting point. Ah ah

I’m writing this while im migrating everything into a flask based one, that will use more or less the same structure we developed for the SI16! Really happy with it. Good night

Bill Viola opens a loot box

The loot box implies a specific temporal dimension: the one with instant rewarding. When a player opens the loot box she receives immediate feedback. Sometimes it is dressed up with an aesthetic of suspense, but this is just cosmetics and the built-up climax often becomes just something undesired that the user wants (and even pay) to skip.

In order to work with the idea of the loot box without re-enacting its toxic behavior and mechanics it could be interesting to hijack its temporality. By inflating the time between the purchasing and the result, we could create space for dig deeper in this complex and delicate topic.

Loot box
pay ●-->○ get

SI17 Loot Box
pay ●--things could happen here-->○ get

This approach could help us in filling the loot box (tempo) without falling for the same addictive schemes that the industry is implementing for exploiting the players.

Inflating the loot box means that the player could reclaim her own leisure time. If we focus on the temporal fruition of the l~b we can imagine to produce not only an object, but a time slot that the person from the public can reserve for herself. If we define this time slot as leisure time then we could create a sacred and safe space to take a rest and to arrest the acceleration of capital. Something like a checkpoint, speaking from a gaming point of view.

An approach to deal with the temporal aspect in a way that doesn’t feel forced could be to rely on real-yet-slow-time processes for the material production of the special issue. A digital manufacturing production could make a lot of sense in this context. 👀

See the loot—box—sealing—device for a concrete and 3d example

3D printed loot box?

This is an idea that follows some intuitions regarding the temporality of the loot box.

Imagine the loot box being 3D printed, and especially 3D printed on demand when the player want to buy it at Page Not Found or Varia or any other place we are going to distribute our work. 3D printing is a slow process, and in order to create a small piece you need to wait let’s say an hour. When someone want to buy our loot box goes to PNF and ask for it, the 3d printing process begins and during the waiting time the player can access and navigate through the contents of our special issue. These contents are contained inside the temporality of the l~b, but they are not consumed instantaneously.

File:/soupboat/~kamo/static/img/test-4d.jpg

caption 3d sculpted loot boxes

How do we want to deliver these contents? It could be related to the way of production of the physical l~b, for instance each player could contribute and shape the 3d model for the next player during the waiting time, and we can aggregate and collect narrations within and around the tools used in order to do so.

In order to cover the expenses of a similar process part of the SI17 budget could cover the cost for some small 3D printers and printing material. The term of services of our special issue could allocate a certain amount of money from each purchase to self sustain the process (buying new printing material, etc)

File:/soupboat/~kamo/static/img/test-5d.jpg

caption 3d sculpted loot boxes

The loot—box—sealing—device

In the movie The NeverEnding Story based on the novel by Michael Ende, the two main characters are linked together by the Auryn. In the (fictional) real world the Auryn is a sigil on the cover of the (fictional) Neverending Story book that tells the tales of the land of Fantasia. In Fantasia, the Auryn is a magic medalion that the hero wears during his mission.

Auryn from Neverending Story Auryn from Neverending Story

Here the Auryn acts as a seal: by removing it from the cover of the book the magical world of Fantasia begins to leak inside the (fictional) real world. Later on it will be the main character to fall inside the (fictional) book of the Neverending Story.

This plot from Michael Ende resembles what happens when we play a game. Thanks to a weird device like a table game, a console or just a set of shared principles, we are able to flow into the magic circle. In the novel this happens with the main character reading a book, and while it’s true that every cultural object offers a certain degree of immersivity, the kind of agency, interaction and participation in the NeverEnding Story is something that reminds me more the act of playing.

File:/soupboat/~kamo/static/img/seals1.jpg

caption 3d sculpted seals

To elaborate more on the 3D printed loot box: we could have a book and using the 3d printer to seal it with a new 3d sigil every time! In a way it is like sealing the loot box instead of opening it. As in the NeverEnding Story (but this is a recurrent magical trope) we would have a sigil connecting who is reading the book with another player. This connection will be not with a fictional character, but with a real person: the one that bought the previous book. There is something like the reciprocity descripted by Mausse here, but is a reciprocity swimming backstroke: the player receives a gift from a past uknown fellow player, and leaves one for a future unkown one. In this way the reciprocity chain (sounds weird) goes spiral.

File:/soupboat/~kamo/static/img/seals2.jpg

caption 3d sculpted seals

Overview

Here a brief description of the different pieces that compose the loot—box—sealing—device

1. The pubblication is composed of 2 main parts: a base and a superstructure. omg sorry
2. The base is the same for every copy, and it’s where the main contents are. (imagine it like a book)
3. The superstructure is dynamic, it is produced and added to the base when and where the pubblication is purchased by someone. (imagine it like a 3d printed something)
4. The production of the superstructure inflates the temporality of the loot box: our narration can inhabit this timespan.
5. While someone wait for the 3d sigil to be printed we can offer a temporary safe zone: a checkpoint at PNF (or other locations)
6. In this temporary safe zone the player can leave something for the next player by designing the next sigil and
7. In this temporary safe zone the player can be guided through the contents of the pubblication while waiting for the superstructure to be produced
8. When a new copy of the pubblication is bought, a sigil is 3d printed and then uploaded on the website of the SI17 as documentation

1. Physical pubblication (a book? a box? something)

I don’t really know which kind of contents, but since we are reading a lot could be intresting to prepare a critical reader about the loot box issues, collecting different perspectives and heterogeneous voices? Then production mode ok and then we print say 100 copies. Our magical technical book binding team figures out the best way in which we can add some dynamic components or 3D addition to the cover-object-book, but we don’t do that yet. We just leave the pubblications without the 3d cherry on the cake.

2. A custom 3d sculpting software

Note that the process could be also implemented with totally different techniques based on digital manufacturing like wood working with cnc, laser cut, etc endless possibilities, but let’s say we want these exoterical 3d printed sigils.

We can develop a simple 3D sculpting software that even people not used to 3D modeling could use. Something like this SculptGL. This is not super easy to do, but not as hard as an API. We could start from some open source thing and then customize it in the way we need. Blender is written in Python and has a super nice API for programming custom plugins, for example.

Side note totally (not totally) unrelated: plugin republishing? 🤯 Ahah it would be great to publish some excerpts from Simone Weil inside the UI of Blender or Photoshop or whatever. Injecting culture in the cultural industry tools.

3. Some templates for the 3d sigil

• material and practical needs
• SI17 visual identity as a starting point
• SI17 contents as orientation
• SI17 world building as heading

(wip)

4. A 3D Printing device

• A 3D printer
• Some interface to sculpt the next 3d seal (aka 1 pc)
• A nice setup for display everything (checkpoint? treasure chest? loot box?)

(wip)

5. A website

• Info
• Inventory that keep track of the sigils (world building)

(wip)

<video src="/soupboat/~kamo/static/video/lootboxes 3d meme.mp4" autoplay loop> </video> If the public of the classical loot box is made of individuals that are easier to exploit, our SI17 could research on ways to generate relations within the public.

Homogeneous public?

The classical loot box assumes two main things:

• That the public is an homogeneous group of individual users
• That the relation between the loot box and its public should be always the same

The loot box offers a limited amount of agency to the player. There is no quality in the interaction with it. The only way to use and access its content is to open it (and this usually means to pay). From the point of view of the loot box every player is the same, an their abilities or features or uniqueness have no meaning at all. One could say that the loot box is a popular device since is an object with a common interface for everyone, but is this really the case?

The interaction with the loot box has no quality, but for sure it implies some kind of quantity. To access is it required to spend a certain amount of money or time. This quantifiable expense is presented as a flat access scheme with homogeneous outcomes, but it is not. The effects of spending hundred €€€ in Fortnite skins are different for a kid and a streamer, for example. While the streamer on Twitch spends 800€ in a row to gain a thousandfold through sponsorizations and views, the average kid just throws away half of his mother’s monthly income.

The public of the loot box is not homogeneous.

Keeping that in mind, we could rethink the basic way of interaction with the loot box. What if we offer something different from the flat price scheme? What if someone can pay less to access to the contents and someone else must pay more? Could this be a way to inject different qualities in the interaction with the loot box?

2 different types of treasure chest

In RPG games the Mimic is a monster that appears as a treasure chest. When a player tries to interact with it in order to get the contents of the chest, it reveals its true nature and attacks her. The name of the Mimic come from its act of mimesis: this creature is like a predator that disguises itself in order to sneak up on its prey.

A treasure chest in a game can be seen as a temporary safe zone because it interrupts the flow of incoming threats by offering a reward to the player. The Mimic endangers this temporary safe zone, and breaks a kind of contract between the player and the game. The treasure chest is transformed in a risky russian roulette, that inoculates danger in the safe zones of a narration.

I’m tempted to write here that the loot box is something like a meta mimic: an object that promises an in-game reward, but produces a damage to the player. What’s more is that this damage is inflicted in the real world, not to the player but to the person. What’s then the difference between a loot box and a Mimic?

Starting from the Dungeons and Dragons’ Mimic I’d like to explore the evolution and the ecology of the mimic through different games. How do the game designers choose where Mimics spawn? What are the relations between those creatures, the level design, the stress of the player, as well as her expectations and trust in the game world? Are there similarities in the way the Mimics and the loot boxes are presented to the player?

TODO: amazon package but has fangs

Modding narrative

After lunch we will be writing fanfic based on the games you played and analysed this week! Lidia said this.

We played Katamari Damacy this week → We wrote a fan faction about it → We approached the fanfiction with empathyzing with the most inanimate things of the game → So we focused on the prince and the objects of the game → We left the King of all Cosmos in the backgroud, since he talks already a lot in the original game. → Suggested soundtrack for the reading: katamari OST

Fun fictious with Mitsa and Erica

3 intuitions come together

Right now:

1. A loot box within a context as such: a book store
2. A loot box within a temporality
3. A loot box with different kinds of public

Over me 🦶🦶 🥁 🦵🦵 📀—-

Context

A lolt box accellerates and forces the mechanics of an environment. In some games it can speed up some tedious process, in other it offers a specific special instant rewarding. Our loot bbx inhabits a book store, or more in general a cultural space. In which ways can we hack through the normal functioning of such place? At a certain point today I thought: ah, we could fill it with the last page of every books in Page Not Found, just to say something about the presumed shortcuts that the loat box promises to the player. The idea is kinda fun, but then what? So maybe no.

Temporality

A couple of days ago I wrote some notes about the temporality of the loto box. In 1 sentence the idea is: if the lot bx is a mechanism of instant rewarding, we could hijack and inflate its tempo and then fill it with our contents. Instead of opening in 30 seconds, the loot bocs takes one hour. Meanwhile we can deliver our messages.

Today I read Play like a feminist by Shira Chess and guess what: there’s an entire part about the temporality of leisure → 🤯

There is something really important we should keep in mind: we are aiming to a public that is etherogeneous. The intersectional approach that Chess advocates it’s a reminder that we can inflate the temporality of the loot biusch, but not everyone will have access to it. So we need to think at both the limits of this spectrum, and put them in a meaningful relation.

Public

As said: our public could be complex. For sure there will be some ultra publishing nerd that will sip all our soup and will be happy with it, but isn’t 1 of our goals to reach also the world outside XPUB? Chess in her book writes about micro temporality, little timespans carved between work shifts or commutes. She has a point when writes that with smartphones leisure time is more affordable and is detached from the rigid tempo of labour.

Decorator

Combining these three aspects the question is: can we create a relation between who can spend an hour at PNF waiting for the loot bosx and who cannot?

Enter the boot lox as a decorator.

A decorator is something that adorn something else. In Python and object-oriented programming in general is also a name of a design pattern that adds some functionality to other functions. We used it already also with Flask! A oobt olx as a decorator means that we could attach it to other pubblication at PNF. Something like an hermit crab inside other shells or that spiky things that bites the tail of a Slowpoke.

The setup

1. The physical decorator, that is a digital manufactured object produced on demand
2. A catalogue of books that can be decorated
3. A website with a digital loot box

The process

1. As a part of the research we compose a bibliography that is also a statement i.e: away from the cis white west guys gang. This bibliography could be site specific for PNF or the other places we will distribute our SI17. We should choose to sell our pubblication in book stores or spaces that want to host this bibliography in their inventory. In this way we can use our SI17 as a device to reclaim space for marginal and subaltern voices.
2. The decorator inhabits this bibliography. It is presented as a special offer in which you can buy one of the book from the bibliography and receive a decorated version of it. Maybe we can sort out some kind of discount mechanism using part of the budget we have. The point is to favor access.
3. The deal is that the production of the decorator has a certain temporality: if we imagine it as something that is 3D printed or laser cutted or CNC carved on demand, it involves a little waiting time. During this waiting time we can transform the book shop in a library, and offer full access to the titles in our bibliography.
4. In exchange we ask to the reader for some insights, notes or excerpts from the books. Those will be inserted in the inventory of our loot box.
5. This loot box can be accessed online from the website of SI17. It works exaclty as a classic one, except that we offer it for free. The content is a collection of thoughts questioning the issue of our project, in the context around our bibliography and readers. It could be an effective way to offer our research to that kind of public that has no means to access it.
6. To open the online loot box and get one (more or less random?) excerpt, the user is asked to draw a decorator. This could be made with a super simple web interface. The drawing will be the next digital manufactured decorator.
7. In the website of SI17 we can keep track of the decorators as well as the exceprts, in a process of inventory and world building.

Skin care routine

This idea of decorator is somehow similar to the concept of skin (in videogame terms). Here our decorator acts as cosmetic in the same way a fancy hat decorates your sniper in Team Fortress 2.

In the game itself the skin is nothing more than a visual candy. But once you look at the turbulence it puts in motion in the game superstructure, you realize that the kind of power-up it offers is something that acts in the social sphere around the game. (See: peer pressure, emotional commitment, skins gambling, product placement, collectibles)

A loot of lot boxes promise rare skins, and by doing so it lures in players. We could subvert this process by taking the skin out of the box.

Instead of opening it to get a new skin, you design a new skin (the decorator!) to open the loot box.

An exquisite branch

The exquisite corpse is a multiplayer game invented by the surrealists in which the participants compose a drawing or a story together.

Traditionally the game is played on a long piece of paper, and each player draws a part, hiding the drawing to the next person, but leaving some hints. The following fellow continues to draw from there and so on. The result is a weird linear narrative, in which the transition between authors are at the same time smooth and abrupt.

With the xquisite branch I would like to try a digital approach to the game. If the original version is constrained to the single piece of paper and is doomed to be linear, here we can imagine our drawings forking and branching and go in different directions.

The process could be something like:

someone send you a link to continue the drawing and when you are happy with it and upload it you receive a new link to share with others. If you pass the link to just one person the xquisite branch will continue, but if you pass it to several people the drawing will branch, resulting in multiple version with a common starting point.

I would like to try this not only as a multiplayer game, but also as a creative tool. I will ask ser togni if he want to draw some comics with it. But it could also used for branching meetings aha 🤯

TODOs

• add name for credits?
• display name in svg?
• comment the code
• remove new from homepage? or
• add per-new level in the xquisite branches (this makes more sense!)

=== There are 100 lot boxes with 100 different jigsaw puzzles of 100 pieces.*
100 boxes compose the face of aymeric if seen from a precise point of view ===

* (exact quantities to be defined)

The picture on each puzzles is a content related to our experiments, games and researches for the SI17

File:Https://hub.xpub.nl/soupboat/~kamo/static/img/catchy-puzzles.jpg

caption sample of contents for the puzzles

Each puzzle is an A2 sized image displaying the works we did during this trimester, designed in a way that can be interesting for the players to buy it, even for the sake of doing a jigsaw puzzle itself.

f.e. A puzzle could be the rules for an RPG; or the map of a bitsy game with some critical texts about gamification; a generated maze, a fan fiction, the glossary, the list of one sentence games, etc.

In other words, the collection of puzzles will be a sort of inventory of our research framed in the form of jigsaw.

The pieces are scattered through all the loot boxes, in a way that each one contains parts of multiple puzzles.

File:Https://hub.xpub.nl/soupboat/~grgr/static/img/jigmix.png

caption shuffle of the jiigsaw pieces

This could be done in a meaningful way: the idea is not to have total random pieces, but legible fragments from each content.

When players buy the loot box they can compose the puzzle, but the result is a patchwork of different images.

File:Https://hub.xpub.nl/soupboat/~grgr/static/img/patchworks.png

caption in each loot box there is a patchwork of different puzzles

If the puzzles have different images but the same pieces pattern, each loot box can have a complete puzzle, but with mixed pieces. In this way we can avoid the frustration that having an incomplete jigsaw puzzle could cause.

On the website of SI17 the players can upload their fragments, and compose together an online version to complete all the jigsaw puzzles.

File:Https://hub.xpub.nl/soupboat/~kamo/static/img/puzzle-web.jpg

caption demo web interface

We can numerate or identify each piece of the puzzles with a code. This could be done when we generate the pattern of the puzzle with Python 👀. To upload a fragment of puzzle, the player is required to insert the code of the pieces, and maybe take a picture. In this way we can be sure that only who has the fragment can insert it online.

Optional feature: users can upload pictures of their fragments and we could have a collective documentation of the work.

demo upload pictures This is not unpaid work, it’s participation

Nice feature for the website could be that you can see the digital version of the puzzle, but on mouse :hover we could show the pictures from the public. A puzzle of photos of puzzles. This could be challenging but funny to develop.

On the website of SI17 there is a community section for exchanging the fragments and complete the puzzle

File:Https://hub.xpub.nl/soupboat/~kamo/static/img/xchange-puzzle.jpg

caption demo xchange puzzle fragments

The community section with users and exchange etc could be tricky, but we can stay as simple as possible and do it with Flask. The exchange section should exclude by design the speculation on the pieces or money. A fragment for a fragment.

On the website of SI17 the public can access to the experiments, games and researches as well

File:Https://hub.xpub.nl/soupboat/~grgr/static/img/lootbweb.png

caption demo other contents on the website

In this way we can provide access to the contents such as the bitsy games, the karaoke video, the ruleset of our games, the reading list, etc.

Risk / Benefit assessment

PROS + simple to make + accessible because it’s a well known game + a lot of design + not to much code + use what we already have + interesting interaction with the public + performative element ready for the launch + multiple temporalities (individual puzzle, contents, shared puzzles) + world building

CONS: - not an API 👀 - i don’t like puzzles - people mught not appreciate the fact of missing parts of their puzzle, but we’re here to subvert it, and contents will be available online anyways

Bonus: summary workflow

production The process to make the puzzles could be easy as design - print - cut - shuffle - package, nothing more (+ website)

box The loot box could provide a context and the instruction of the game, as well as the link to the website.

Scenario

Mapping the chaotic evil puzzles in the through the different scenari

of the form

scenario 1: The lootbox is a physical box that contains something

Fragments of several puzzles.

of the feature

scenario 7: The items in the loot-box are complementary and it is necessary to connect with other loot-box owners in order to assemble the pieces together.

There is a single player aspect and there is a collaborative aspect. These two components could be mediated by an online platform, such as the online shared puzzles, but could also work offline if people just combine the pieces of their loot boxes.

of the contents

scenario 2: The loot box is a collection of the prototyped games (and researches!) we did so far curated in some kind of form

The jigsaw puzzle is just a form of encryption of our contents. A shared surface in which we can publish really different things such as a fan fiction, a board game, a link to a video karaoke or a videogame, an essay, the characters of a roleplaying game, etc.

scenario 3: The loot box is a collection of mini-games + an ultimate game that has to be performed with other players that purcahsed the LB

There are several layers of playability and access:

1. to solve the fragments (single player jigsaw)
2. to access the contents (games, texts, etc. )
3. to combine the fragments (ultimate multiplayer game, re-distribuition of the loot boxes contents)

scenario 6: The lootbox contains a series of jigsaw puzzles but their pieces are scattered through all the boxes and there is a platform online where you can see the missing tiles.

Nothing to declare.

memos

• play with quantities and distribuition of pieces (1 piece only, large groups, variations, etc)
• play with puzzle pattern: alternative to the mainstream shape of the tiles
• pieces naming system
• And then the aim is to exchange pieces or something and rebuild the original puzzles? (can this be a critical approach?) (does this make sense only if there are as many puzzles as loot boxes?)
• short term puzzles (link to multimedia contents, puzzle shards)
• long term puzzles (hidden messages, 1 word in each puzzles and a secret sentence)
• size and quantity
• The jigsaw puzzles results should be secret? There would be much more mistery. Can we reveal only during the launch, but not on the loot boxes? Maybe is a compromise, but maybe is not necessary. Should we reveal them only in the website meanwhile they are completed? Could be.
  

• Generate Jigsaw Puzzle with python
• How To Laser Cut a Jigsaw Puzzle
• Jigsaw puzzle generator
• Fractlal Jigsaw

Which kind of public do we want to produce?

If the loot box and gamification produce a single player in competition with all the others, I would like to produce a collaborative public. More like a community than a billboard with users ranking. Also I think this is an operation that requires time. Hence the loot box as a shrine: a safe place to build, discover and charge with meanings together.

How do we want our public to engage with our loot box?

I like the idea of different temporalities and the concept of slow processing. Something could be delivered really fast, something could require an entire evening, something could need to wait an entire month.

We should balance the single player / multi player aspect of the loot box. It would be great to have something that one can enjoy both alone and with others. The collaborative aspect of the loot box should be something possible and encouraged, but not mandatory.

What kinds of questions/feelings/thoughts it create ?

• To feel part of a community or fellows in a shared quest.
• To wonder how vast is the inventory of the loot box.
• To question the idea of competition as necessary for gamification
• To raise awareness on different voices on the topic

How the lootbox is going to be presented to our public during our launch event?

The presentation could perform the contents of the loot box.

How will the launch look like?

Nice

How can the lootboxes be activated by the public in a sustainable an independent way after the launch?

With a website

What is our relationship to PnF?

I don’t know

Does the publication relate to PnF? how?

I don’t think so

how and where do we sell the lootbox?

In place that want to host subaltern authors from our reading list.

do we sell in other stores? if yes how are they connected?

We are the connection

Hello this is a test.

This image is in the same folder of the project, not in the static one.

File:Hiroshige.jpg

caption test

and it works!

and now also the md file that generates the page should be accessible.

is this a good idea?