Draft 1

This project started as an attempt to copy a generative weaving system using p5.js. The original work does not aim to look like real fabric, and I also did not try to achieve that. Instead, I focused on understanding how the logic and structure of weaving could be translated into code.

During the copying process, I noticed that although my work follows a similar structure to the original, the final result is still different. The system I created feels very structured and precise, which made its digital quality clearly visible. This difference was not caused by one big change, but by many small decisions inside the code.

While working on the project, I realized that even very small changes in parameters could lead to much bigger visual differences. A slight adjustment in spacing, speed, or values could completely change the overall pattern, even when the basic logic stayed the same. This made me understand how sensitive generative systems can be.

Rather than seeing this difference as a failure of copying, I began to see it as part of the learning process. Through this project, I started to think more about what coding is good at, what it resists, and how structure and repetition become visible through iteration.

Draft 2

I began this project by working with a generative weaving system in p5.js. At first, my focus was largely visual. I paid attention to grids, threads, colour, and repetition, and tried to understand how these elements could come together to resemble fabric. At this stage, I was thinking more like a maker, concentrating on form and outcome rather than on the system itself.

As the project developed, my approach gradually shifted. I noticed that very small changes in the code could produce a wide range of different results. Some changes were barely visible, while others completely altered the structure. This made me stop thinking of the work as a set of final images. Instead, I began to see it as a process that continuously unfolds. Rather than exporting individual still images, I chose to record the system running, allowing the behaviour of the system to remain visible over time.

Reading the Conditional Design Manifesto helped me articulate this shift. The manifesto frames design as the construction of conditions rather than the production of fixed outcomes. This perspective resonated strongly with my experience of coding. Although the system appears flexible, it is not open. Every action takes place within boundaries that I define. Even randomness operates according to rules. Writing code, in this sense, is less about making things happen and more about deciding what is allowed to happen in the first place. Meaning is produced at the level of rules, before any visual result appears.

This became even clearer when I introduced damage and collapse into the system. The fabric could fail in different areas, spread unpredictably, or slowly disappear. At this point, the work no longer felt like an object, but like a behaviour. Iteration stopped being a method for refinement and instead became a way of observing how the system responds under pressure.

Adding repair introduced another layer of decision-making. Initially, I assumed repair would simply restore the fabric. However, implementing it revealed that repair is never neutral. A system that repairs must decide what is fixed, how visible the repair is, and whether traces of damage are erased or preserved. I chose to make repair visible by marking only the damaged areas while leaving the rest unchanged. This allows the system to retain a record of what has happened.

Although I am not trying to directly represent social inequality, the idea of repair made me aware of its broader implications. Repair can suggest care, but it can also suggest control or erasure. By keeping repair visible, these meanings remain unresolved rather than smoothed over.

At this stage, the project remains experimental. However, it has shifted how I understand coding—not just as a tool for producing images, but as a way of thinking through rules, labour, and care. Moving forward, I want to connect this system to textile and weaving histories, particularly the work of women weavers associated with the Bauhaus, and explore how generative systems can reflect these histories through conditional processes.

Draft 3

Over the past few weeks, my project developed from a visual experiment into a study of how a system changes over time. I built a small generative weaving system in p5.js. At the beginning, I was mainly interested in how to make the fabric look convincing. The system slowly draws warp and weft lines to form a grid. I adjusted colour palettes, weaving patterns, and hole positions. My focus was on appearance.

Through iteration, my attention gradually shifted. When I changed small values in the code, the results were sometimes much larger than expected. A minor numerical adjustment could influence the entire fabric structure. This made me realise that the project was not only about producing images, but about observing how a rule-based system behaves. The system may appear flexible, but every action still takes place inside boundaries that I define.

This way of thinking relates to the ideas expressed in the Conditional Design Manifesto, which suggests that design is about creating conditions rather than directly designing fixed outcomes (Conditional Design, 2013). In my project, I do not control the final image in detail. Instead, I construct a framework of rules. The visual result emerges from how those rules interact over time. Meaning therefore appears at the level of structure, not decoration.

The turning point of the project was introducing damage and repair. When damage is activated, holes expand and threads break apart. The woven structure begins to collapse. Repair does not simply restore the fabric to its original state. After light damage, the repair looks almost clean. After heavy damage, the repair takes longer and becomes uneven. Even when the holes close, the fabric remains slightly distorted. The repaired surface shows tension and irregularity. This effect was not manually added but produced by the system’s internal logic.

Through this process, I began to understand iteration differently. Iteration is not refinement toward perfection. It is accumulation. Each stage leaves a trace that cannot be fully removed. The system carries memory forward rather than returning to a neutral state.

Writing this response followed a similar pattern. I revised earlier drafts instead of restarting from zero. Some sections were removed, others reorganised. The final version is shaped by these adjustments. Like the fabric, the text records its development. Revision becomes a form of structural repair rather than erasure.

My initial inspiration came from digital reinterpretations of Bauhaus weaving, which also translate material practices into systems of structure and repetition. While my project does not directly address this history, it made me reflect on how systems allow certain actions while restricting others. No matter how much iteration occurs, the framework remains.

Through this project, I learned that working with generative systems is less about control and more about defining limits. Iteration exposes how structure, pressure, and memory operate inside those limits.

References

• Conditional Design (2013) Conditional Design Manifesto. Available at: https://conditionaldesign.org/manifesto (Accessed: 6 February 2026).

Draft 3 – Rendered Version

In this rendered version, earlier statements remain visible as commented code rather than being erased. The structure of revision mirrors the logic of the weaving system itself: iteration accumulates rather than resets. By placing the text inside the coding environment without executing it, the writing becomes a system of conditions rather than a finished image.

• Block 1: Early Position (Commented)

• Block 2: Structural Revision

• Block 3: Parameters and Conditions

• Block 4: Damage / Repair Logic

• Block 5: Iteration and Memory

• Block 6: Writing as Structural Repair

• Block 7: Reference