The third iteration of OOC could be two-parts workshop: in the first moment participants co-design a VR environment with a custom multiplayer 3D editor. The second half is a dance workshop with a choreographer that guides and explores with the participants the virtual reality they created altogether. The VR headset is passed hand by hand as a catalyst, transformed from a single-user device to a wandering and plural experience.
* terraforming - sebastian lague [https://www.youtube.com/watch?v=vTMEdHcKgM4](https://www.youtube.com/watch?v=vTMEdHcKgM4), for volumes modelling
* my inner wolf - studio moniker [https://studiomoniker.com/projects/myinnerwolf](https://studiomoniker.com/projects/myinnerwolf), for the multiplayer work with images and textures
- what does it mean: to make sense together? to accept the limits of our own individual description and join others to have a better view (renegotiation of complexity?)
Our technological environment is made of abstract architectures built of hardware, software and networks. These abstract architectures organize information, resources, bodies, time; in fact they organize our life. Yet, they can be really obscure and difficult to grasp, even to imagine.
Within VR we can transform these abstract architecture into virtual ones: spaces that are modelled on the nature, behaviour, and power relations around specifc technologies. Places that constraint the movements of our body and at the same time can be explored with the same physical knowledge and awareness.
This iteration of OOC is a performance with the temporality of a two-parts workshop: in the first moment participants model together the virtual environment with a custom VR editor, that let them create the space in 1:1 scale.
The second half is a performative workshop with a choreographer that guides and explores with the participants the virtual reality they created altogether. The VR headset is passed hand by hand as a way to tune in and out the virtual space, transformed from a single-user device to a wandering and plural experience.
Since an abstract architecture is composed of several entities interacting together, the dramaturgical structure con be written following them. The narration of the modeling workshop as well as the performative excercises from the warming up to the final improvisation can be modeled on the elements of the architecture.
To make an example: the first OOC was modeled on a group chat. The connected participants were represented as *clients *placed in a big circular space, *the server*. Within the server, the performer acted as the *al*gorithm, taking messages from one user to the other.
* a two-parts workshop: in the first moment participants co-design a VR environment with a custom multiplayer 3D editor. The second half is a dance workshop with a choreographer that guides and explores with the participants the virtual reality they created altogether. The VR headset is passed hand by hand as a catalyst, transformed from a single-user device to a wandering and plural experience.
* it has a particular temporality: it is not intense as a performance and the pace can be adjusted to keep everyone engaged.
* it follows the idea of lecture performance, steering toward more horizontal and collaborative way of making meaning
* it provides facilitation
* cannot be done the same day as the presentation, at least a couple of days before (less time for reharsal)
* There is the VR editor tool and the facilitation of the workshop is recorded as a text (maybe audio?), participants con follow it through and create the evironment while participating. the text is written with the choreographer / performer. it's a mix between the two moments of the workshop. the performer is following the same script.
- The emergence of algorithmic solidarity: unveiling mutual aid practices and resistance among Chinese delivery workers, [read](https://journals.sagepub.com/doi/full/10.1177/1329878X221074793)
- Your order, their labor: An exploration of algorithms and laboring on food delivery platforms in China, DOI:10.1080/17544750.2019.1583676
- The algorithmic imaginary: exploring the ordinary affects of Facebook algorithms, DOI:10.1080/1369118X.2016.1154086
- Algorithms as culture: Some tactics for the ethnography of algorithmic systems - [read](https://journals.sagepub.com/doi/10.1177/2053951717738104)
- Redlining the Adjacent Possible: Youth and Communities of Color
Face the (Not) New Future of (Not) Work [read](https://static1.squarespace.com/static/53c7166ee4b0e7db2be69480/t/5682b8071c12101f97a8b4df/1451407367281/Redlining+the+Adjacent+Possible\_DS4SI.pdf)
Our technological environment is made of abstract architectures built of hardware, software and networks. These abstract architectures organize information, resources, bodies, time; in fact they organize our life. Yet, they can be really obscure and difficult to grasp, even to imagine.
Being in space is something everyone has in common, an accessible language. Space is a shared interface. We can use it as a tool to gain awareness and knowledge about complex systems.
Within VR we can transform these abstract architecture into virtual ones: spaces that are modelled on the nature, behaviour, and power relations around specifc technologies. Places that constraint the movements of our body and at the same time can be explored with the same physical knowledge and awareness. (like what we did for the chat)
Starting from one specific architecture (probably the food delivery digital platforms typical of gig economy that moves riders around) we model and map it together with the public. Since an abstract architecture is composed of several entities interacting together, a strong dramaturgical structure con be written following the elements of the architecture.
a performance with the temporality of a two-parts workshop: in the first moment participants model together the virtual environment with a custom VR editor, that let them create the space in 1:1 scale.
Then a performative workshop with a choreographer / performer that guides and explores with the participants the virtual reality they created altogether. The VR headset is passed hand by hand as a way to tune in and out the virtual space, transformed from a single-user device to a wandering and plural experience.
The VR editor is used as an installation. Other than the normal functionalities to model the environment it contains a timeline with the structure of the workshop recorded as audio. The performer activate the installation following the script. The text is written with the choreographer / performer. it's a mix between the two moments of the workshop version descripted before. After the performance, participants (up to three at the same time) can follow the audio it and being guided in the creation of the environment.
Both options can be activated multiple times, with different results. The resulting 3D environments can be archived on a dedicated space (like a showcase website) in order to document, (communicate, and $ell the project again for further iterations)
The building block is the Stage. Each stage is a description of what's happening at the edge of the performance: what the screen is displaying, what's inside the VR, what's happening on users' smartphone.
1. when someone access the website a random ID is generated and stored in the local storage of the device, in this way even if the user leaves the browser or refresh the page we can retrieve the same ID from the storage and keep track of who is who without spawning new user every time there is a reconnection (that with ws happens a lot!)
2. maybe the user could choose an username? it really depends on the kind of interaction we want to develop. also i waas thinking to ending credits with the participation of and then the list of users
3. when connecting and choosing and username, the client sends it to the server that sends it to vvvv, that stores the users in a dictionary with their ID. Every interaction from the user will be sent to the server and then vvvv with this ID, in this way interactions can be organized and optimized, as well linked to the appropriate user.
even if we can take out excerpts from the essay we wrote, this reading setup is totally different. here our texts need to be formulated like a call to action, or a provocation to trigger the interaction.
In order to distinguish between different types of message I decided to serialize every text as a JSON string with a field named *type*. When a message event is fired the server goes and look at the type of the message and then acts consequently. Every message triggers a different reaction aka it calls a different function.
In the previous versions the check on the message type was a loong chain of if statements, but that didn't feel right, so I searched a bit how to manage it in a better way.
In the server (node.js) i created an object that uses as keys the type of the message and as value the function associated. [javascript switch object](https://www.30secondsofcode.org/articles/s/javascript-switch-object)
For vvvv I asked some suggestion in the vvvv forum and ended up using a simple factory pattern that uses a common interface IMessage and then use it to process the incoming message based on the type. [replacing long if chain](https://discourse.vvvv.org/t/replacing-loong-if-chain/20707/3)
In order to deal with the state of the application (each message operate in a different way and on different things) I created a Context class that holds the global state of the performance such as the websocket clients, and the connected users. The IMessage interface take this context as well as the incoming message and so it can operate on the patch.
Yesterday together with Richard we setup the two screens to show what's happening inside the VR for the public. Initially they were mounted next to each other, in vertical.
With Iulia we thought how to place them. Instead of keeping them together probably it would be better to use them at the edge of the interactive zone. Even if the screen surface seems smaller, it's a creative constraint \& it creates more the space of the performance.
the username should be central in the visualization of the interaction, since it's the main connection point between between whats happening outside and inside? could it be something different than a name? could it be a color? using a drawing as an avatar?
The setup with nuxt is messy since it's stuck between nuxt 2 and vue 3. There are a lot of errors that don't depend on the application but rather to the dependencies and it's really really annoying, especially since it prevents solid design principles.
Im trying to understand which setup to use to rewrite the application without nuxt. Currently im looking into fastify + vite + vue, but it's too many things altogether and im a bit overwhelmed.
* performer st. thomas movement to invite for the touch interaction
* the public is invited to follow the performer ? (for example releasing the touch improvisely, some kind of slow rythm, touch pattern, explore this idea as introduction?)
* every user is an object in the VR space, placed in a random-supply-chain to build a meaningful space for the choreography. the object is visible only when the user is touching the screen.
* the performer can activate these objects by getting closer
* when an object is activated it sends a notification to the smartphone of the user, that play some sound effect
* **bonus**: the more the user keep pressed, the bigger the object grows? so it's activated more frequently and this could lead to some choir and multiple activations at the same time?
is great for the beginning. It could start super minimal and imperceptible, transition from the idle mode to the beginning of the performance, with slowly increasing intensity
Janus' looking around and searching could be the reaction when someone connect and is placed in the space. When someone touch, look at them in the virtual place and then stay. it's a first way to create the impression of the environment that surround the performer
are a good way to elaborate on the idea of touch interaction. focus on fingers as well as focus on the surface those fingers are sensing. Bring new consistency to the touchscreen, transform its flat and smooth surface to something else.
Stationary movement that could introduce the performer point of view. The body is super expressive and the head is still, so the point of view in the VR is not crazy from the start.
Need to finish this analysis but for now here is a draft structure for the performance. Eventually will integrate it with the previous two sections: the Performance Structure and the trigger notes.
The space in the virtual environment resemble more an Abstract Supply Chain instead of an architectural space. It's an environment not made by walls, floor, and ceiling, but rather a landscape filled with objects and actors, the most peculiar one being the performer.
We can build a model that scan scales with the connection of new users. Something that has sense with 10 people connected as well as 50. Something like a fractal, that is legible at different scales and intensities.
We have a poll of 3d object related to our theme: delivery packages, bike, delivery backpack, kiva robot, drone, minerals, rack, servers, gpu, container, etc. a proper bestiary of the zone.
Every user is assigned to an object at login. The object you are influences more or less also your behavior in the interaction. Im imagining it in a subtle way, more something related to situatedness than theatrical acting. An object oriented LARP.
How wide or specific our bestiary should be? A whole range of different object and consistency (mineral, vegetal, electronical, etc.) or just one kind of object (shipping parcels for example) explored in depth?
All the interactions are focused on the physical use of touchscreen. They are simple and intuitive gestures, that dialogue with the movements of the performer.
There are three section in the performance and one interaction for each. We start simple and gradually add something, in order to introduce slowly the mecanishm.
*Presence* is the simple act of touching and keep pressing the screen. Ideally is an invite for the users to keep their finger on the screen the whole time. A way for the user to say: hello im here, im connected. For the first part of the performance the goal is to transform the smooth surface of the touchscreen in something more. A sensible interface, a physical connection with the performer, a shared space.
*Rythm* takes into account the temporality of the interaction. The touch and the release. It gives a little more of freedom to the users, without being too chaotic. This interaction could be used to trigger events in the virtual environment.
*Space* is the climax of the interaction and map the position on the touchscreen into the VR environment. It allows the user to move around in concert with the other participants and the performer. Here the plan is to take the unreasonable chaos of the crowd interacting and building something choreographic out of it, with the same approach of the collective ritual ending of the previous iteration.
-*an initial moment of invitation* where the performer introduces the interaction and offer it to the user via something similar to the functioning of mirror neurons. Imagine the movement for St.Thomas as invitation to keep pressing the touchscreen.
It is a moment that introduces the interaction to the public in a practical way, instead of following a series of cold instruction. It is also a way to present the temporality and the rythm of the interaction.
- *a following moment of composition*, in which the interactive mechanism is explored aesthetically. For *Presence* is the way the performer interact with the obejct inside the space. For *Space* is facilitating and leading the behaviour of the users from something chaotic to something organic (from random movements to a circular pattern?)
Started having a look at reactive programming. Since everything here is based on events and messages flowing between clients, server and vvvv, the stream approach of reactive programming makes sense to deal with the flows of data in an elegant way.
- could be related to the configuration of the object, a way to be more or less structured
- for example start from totally deconstructed object and gradually morph into it's normal state
- an assemblage of different parts
Following the timeline of the performance we could setup a flow of transformation for every object: at the beginning displacing randomly the object, messing around with its parts. We could gradually dampen the intensity of these transformations, reaching in the end a regular model of the object.
This transformations are not continous, but triggered by the tap of the user. They could be seen as snapshots or samples of the current level of transformation. In this way, either with high & low sample rate we can get a rich variation amount. This means that if we have a really concitated moment with a lot of interactions the transformations are rich as well, with a lot of movements and randomness. But the same remains true when the rythm of interaction is low and more calm: it only get the right amount of dynamic.
One aspect that worries me is that these transformation could feel totally random without any linearity or consistency. I found a solution to this issue by applying some kind of uniform transformation to the whole object, for example a slow, continous rotation. In this way the object feels like a single entity even when all its parts are scattered around randomly.
The transformation between the displaced and the regular states should take into account what I called *incremental legibility, *that is:
in this way we could obtain some kind of *convergence* of the randomness.
Actually the prototype works fine just with the decreasing intensity, i didn't tried yet to transform the different features individually or in a certain order.
Also: displacing the textures doesn't look nice. It just feels broken and glitchy, not really an object.
1. in one screen we cluster all the objects in a plain view, something like a grid (really packed i presume? it depends on the amount)
2. in the other we could keep them as they were in the first interaction, and present them through the point of view of the performer, keeping the sound notification when she gets closer and working as a close-up device.
we could also display the same thing in two screens, to lower the density of object and focus more on the relationship between the performer and the public as a whole, attuning the rythm
how this interaction interacts with the choreography? is it enough for the performer to be just a point of view?
- activated by touch press. user needs to keep pressed in order to stay connected to the performer.
- when users press they appear in the virtual environment in the form of the same 3D object. the object is still, it's position in the space is defined accordingly to the Abstract Supply Chain structure.
- when the performer gets close to users, a notification is sent to their smartphone and plays some soud effects.
- every object has its own sprite of one-shot sounds
