Systemism

2025-09-13T00:00:00+00:00

We can experience a system as a whole or analyse it into its constituent parts. The worldview that privileges the first is called “holism”, the second “reductionism”. In everyday ife, holism typically has a positive connotation, while reductionism is viewed negatively.

Domains that are interpreted as emphasising analysis, most notably science, are called “reductionist” when their method is taken to filter out important aspects of the world. In recent years, a critique of food and nutritional scientists, which argued that they were guilty of “nutritional reductionism”, gained significant traction. The critics instead advocating for holism, often advancing an explicit skepticism of analysis.

If the scientist is the archetypal reductionist, the archetypal holist might be the artist, who experiences the world as it is given and integrates multiple aspects of that experience into their art.

The dichotomy between holism and reductionism is usually false. A scientist who appreciates the holistic beauty of plants is more likely to become interested in their analysis. An artist who is aware of the geometrical patterns in the parts of nature can incorporate them into their artistic vision. While there are scientific disciplines that focus on parts (molecular biology), there are also those focused on wholes (synthetic biology), and many scientists that oscillate between these frames.

There is a verticality in how we contrast holism and reductionism. We imagine experiencing the whole at a “high level” and the parts at a “low level”. At the higher level, we can “take everything in” but at the low level we “miss the big picture”. Even stronger, some argue that analysis risks actively destroying the whole, with our immediate experience being somehow displaced by a symbolic language of atoms, bits, molecules, and nutrients.

Reductionism can instead be thought of as a narrowing of perspective. In that sense, holism itself is a kind of reductionism, as it narrows our perspective to the whole, a particular level of analysis. Just as we can be “nutritional reductionists” (reducing food to nutrients), we can also be “sensory reductionists” (reducing food to sense experience) or “cultural reductionists” (reducing food to its socio-cultural role). Each of these is a legitimate way to analyse food but none of them provides a totalising account.

To be more clear, we can think of two general kinds of reduction, each amounting to a narrowing of perspective:

Macro-reduction: narrowing from parts to wholes (holism)</li>
Micro-reduction: narrowing from wholes to parts (reductionism)</li> </ul>
Science often begins with the experience of an interesting phenomenon. A scientist then attempts to study its underlying causes. When the analysis is complete, they build a model that connects the causes to the experience. The investigation not only includes considerations of parts and wholes, but also attempts to integrate them together in the form of an explanation.
An engineer who develops software moves between writing the code and debugging the program. They experience a problem with the user interface and then must analyse the causes of that problem. The development process is a continuous loop between the parts that make up the program and that whole experience that the user encounters.
The Argentinian philosopher Mario Bunge used the term “systemism” to refer to an epistemology of systematic explanations that bridges holism and reductionism. Bunge was skeptical of both holism and reductionism when used in isolation: reductionists are at risk of fragmenting knowledge, while holists are prone to superficiality.
Imagine that you have made a causal observation of some kind. This could be that:

Clicking the button made the software crash</li>
Mixing the chemicals made the solution blue</li> </ul>
This is the macro</code> level. It is at the top of this diagram and is signified by $A_0 \to B_0$:
$$ \displaystyle {\displaystyle {\text{A}_0 \atop \downarrow} \atop \text{A}_1} {\displaystyle {\to \atop \phantom{x}} \atop \to} {\displaystyle {\text{B}_0 \atop \uparrow} \atop \text{B}_1} $$
At the bottom there is another causal relation $A_1 \to B_1$ occupying the micro</code> level. The micro is less salient or immediate, and may require deep reasoning or the use of instruments:
How is the button implemented and does it produce the bug?</li> Which type of chemicals were added and what reaction was generated?</li> </ul> Moving between the two levels — micro and macro — during active discovery is characteristic by: Analysis: determining the micro-level causes responsible for macro-level effects</li> Synthesis: observing macro-level effects through manipulation of micro-level components</li> </ul> After restricting ourselves to a single level of analysis in our methodology, we risk forming a view of reality that is artificially constrained: Micro-reduction: “there is no society, only individuals”</li> Macro-reduction: “there are no individuals, only groups”</li> </ul> While the former is commonly referred to as “reductionism”, in contra-distinction to the “holism” of the latter, both are related as being kinds of reduction, requiring a narrowing of perspective and a denial of systematic relations. The “macro” does not always refer to a definite level or scale in a physical sense. It depends on the context of an investigation. The elevated position of the macro in the diagram should also not be understood as establishing its priority, just as the lower position of the micro does not always prioritise it as foundational. The specific domain of inquiry determines the level of analysis, and the analysis is not restricted to only two levels: Domain</th> Micro</th> $\leftarrow$ Macro | Micro $\rightarrow$</th> Macro</th></tr></thead> Economics</td> Individuals</td> Groups</td> Societies</td></tr> Technology</td> Components</td> Sub-assemblies</td> Interfaces</td></tr> Software</td> Low-level code</td> High-level code</td> User interfaces</td></tr> </tbody></table> When there is an explanatory gap between two or more levels, the ontological concept of “emergence” is invoked. Here, there are a set of coincident events but no established relation between them. Crucially, this does not mean that the relation will never be known, only that it remains to be discovered; for example, the “mystery” behind the emergence of a blue colour in a mixture is displaced by a mechanistic explanation when we establish the underlying chemistry. In summary, we often have questions of the form “what $x_1$ is the cause of $x_0$?”: $$x_1? \to x_0$$ The $x_0$ could be a scientific observation, a software bug, or an everyday experience. The study or engineering of the relevant system often requires moving between stages of analysis and synthesis. From such a process, we develop deep explanations. In analysis, we do a top-down study of the micro-level causes. To explain why salt morphology</a> affects the intensity of saltiness, we can measure the dissolution of different NaCl crystals in artificial saliva. In synthesis, we do a bottom-up evaluation of the macro-level effects. To explore the relationship between dissolution rate and saltiness, we take salts with known dissolution rates and get people to evaluate their saltiness. We form a complete picture, in which the shapes of salt crystals influence their dissolution rate, affecting the dissociation of salt into $Na^+$ and $Cl^-$ ions, which interact with taste receptors on the tongue and initiate the firing of signals to the brain that result in the perception of different intensitities of saltiness: $$ {\displaystyle {\text{salt} \atop \downarrow} \atop \text{Na}^+} {\displaystyle {\to \atop \phantom{x}} \atop \to} {\displaystyle {\text{taste} \atop \uparrow} \atop \text{signal}} $$ The invention of technology helps people make progress. Such progress is scaled to a societal level when an invention has a concrete implementation as a product. This exposes it to the market, which initiates mechanisms of feedback that improve the implementation. Accelerating progress is not only about incentivising entrepreneurship; it’s also about creating the preconditions for invention and establishing reliable mechanisms of feedback. $$ {\displaystyle {\text{Product} \atop \uparrow} \atop \text{Invent}} {\displaystyle {\to \atop \phantom{x}} \atop \to} {\displaystyle {\text{Market} \atop \downarrow} \atop \text{Progress}} $$ The appearance of “emergent” properties may highlight an inappropriate conceptual or methodological framing. For example, water can be interpreted on a strictly molecular basis as being composed of two kinds of elements existing in a certain relative proportion and structured by particular forces. This is the micro</code> level. Yet, at the macro level, water has properties like viscosity and turbulence, which are difficult to predict based on strict appeals to molecular chemistry. For this reason, scientific fields like rheology are oriented towards developing specific methodologies appropriate to a relatively macro</code> level. $$ \displaystyle \overbrace{ {\displaystyle {A_0 \atop \downarrow} \atop A_1} {\displaystyle {\to \atop \phantom{x}} \atop \to} {\displaystyle {B_0 \atop \uparrow} \atop B_1} }^{\text{analysis}} \iff \overbrace{ {\displaystyle {A_0 \atop \uparrow} \atop A_1} {\displaystyle {\to \atop \phantom{x}} \atop \to} {\displaystyle {B_0 \atop \downarrow} \atop B_1} }^{\text{synthesis}} $$ The utility of having a deep explanation of a phenomenon is not always clear. When first learning chemistry or programming, we might not recognise the value of a systematic explanation of some everyday occurence. What power does it give us? Consider the case of pink tea</a>. With some varieties of green tea, it is possible to create a bright pink colour if it is brewed with baking soda and milk. Recipes typically report that baking soda is needed to generate the colour, without specifying why. At the micro level, baking soda is just an alkalising agent. It elevates pH resulting in chemical reactions (rxns) involving tea polyphenols that cause a change in colour. When milk is heated, there is also a chemical reaction between its sugars and proteins, which contribute a browning effect that is accelerated in alkaline conditions. $$ {\displaystyle { \text{NaHCO}_3 \atop \downarrow } \atop \text{OH}^-} {\displaystyle { \to \atop \phantom{x} } \atop \to} {\displaystyle { \text{pink} \atop \uparrow } \atop \text{rxns}} $$ The original macro observation is still valid and may be perfectly sufficient if we only want to make pink tea for friends. Once we have a micro explanation, we do not discard the macro one. Both levels can function together in an explanatory system. In addition, the explanation gives us more power to act. For example, someone may want to drink pink tea but is concerned about their sodium intake. We have learned that the recipe does not require baking soda, however, only something from the general class of alkalising agents. To increase pH we need something that releases $OH^-$ ions. It is therefore possible to substitute baking soda for a sodium-free alternative as long as it releases $OH^-$, with potassium hydroxide ($KOH$) being an obvious candidate. Imagine that a significant market for pink tea has emerged and there is a demand to manufacture it at industrial scale. The problem is that there is significant inter-batch variation in colour and an immediate need to better control the process. We have learned that a change in pH is critical for determining the final colour of the tea. Installing a pH measuring device to ensure that the correct pH is consistently reached would seem prudent. Finally, changes in colour induced by chemical reactions involving polyphenols, sugars and proteins are unlikely to be restricted to the peculiar case of pink tea. Knowledge of the link between chemical reactions and colour changes can be generalised to many other systems. For example, the (Maillard</a>) browning effect mentioned earlier can be used to explain everything from the deliciousness of toast to the reduced nutritional quality of some foods</a> during processing and storage. Bunge, M. (2014/2003). Emergence and Convergence: Qualitative Novelty and the Unity of Knowledge. Toronto: University of Toronto Press. Bunge, M. (1979). Treatise on Basic Philosophy Volume 4, Ontology II: A World of Systems. Dordrecht: D. Reidel publishing Company. Survey of definitions 2025-04-27T00:00:00+00:00 We often have a fear of fixing the meaning of an idea, thinking that while our idea remains unfixed, it has maximum potential and scope. Everyone then has the problem of interpreting our idea. When trying to build things together, such ambiguity can be a significant impediment to progress. This problem often manifests as a discomfort with definitions. The worry is that a definition may fix an idea in the wrong state, or deprive us of access to many (implicit) definitions at once. But, at a point in time, it’s better to know what we’re talking about than to not know, and definitions can help in this regard. Pointing</a> </h2> When I worked on construction sites with my brother — a painter — he would say things like: “Sand the architrave 1</a>.” “Paint the plinth 2</a>.” I didn’t know what he was talking about, until he would just point at the thing and say: “That.”. He had connected the term and the concept, and this was sufficient for me to get the work done. My brother had given an ostensive definition. Not every thing is as easy to point at, like invisible atoms, abstract concepts and future solutions. Even if we can point at something, we may not have sufficient understanding to solve certain problems relating to that thing. If I can sand an architrave it does not mean I can design an algorithm for creating varied architrave designs. For that, I would need a more precise formulation of the idea. An ostensive definition can sometimes take the form of exemplars: My definition of “robust” is that codebase </blockquote> An exemplar suggests a profile of attributes that we should value, which may be demonstrated implicitly by pointing. We find it easier to reach a stable consensus on our exemplars if we have been explicit about our notion of “goodness”, which takes us beyond mere pointing. Dictioneering</a> </h2> The concept of a definition is usually associated with the lexical definition. This is the kind of definition that we find in a dictionary. When I taught science at university, I would sometimes ask students to define a technical concept like “micelle”. This would prompt a non-trivial number of students to report back a dictionary definition, like this one from Merriam-Webster: Unit of structure built up from polymeric molecules or ions, such as: an ordered region in a fiber (as of cellulose or rayon)</li> a molecular aggregate that constitutes a colloidal particle</li> </ul> </blockquote> Of course, I was asking for something more than a dictionary definition. Armed with a dictionary definition, someone has a basic idea of what is being referred to when a term is used in a conventional way. A university graduate or skilled professional usually has knowledge of a particular subject far beyond the conventional meaning. The usage of an expert or craftsperson may even deviate substantially from the everyday sense of a term 3</a>. The best students defined the concept of a micelle in relation to the coursework that was being examined. They needed to develop a definition that was more precise to our shared context. Precising</a> </h2> When building something — like a new technology — we might ask for it to be made more “simple”. What does “simple” mean here? We could refer to the entries in Merriam-Webster</a> and they wouldn’t help us very much. We need a precising definition. This makes some general definition more precise to our specific context. We might want a simple technology to conform to some of the following precising definitions: A simple technology has the minimum necessary components, to improve our capacity to maintain it</li> A simple technology hides the internal complexity of the system, to provide an accessible user interface</li> (1) and (2): A simple technology has the minimum necessary components, to improve our capacity to maintain it and so it is accessible to the user</li> </ol> Many other definitions could be imagined and combined. Precising definitions — and others: like stipulations — are often ameliorative. They make an idea more suited to our purpose or more useful to achieve some goal. Forming a definition may therefore be a normative act, not merely a descriptive one. Normativity An act is normative when it relates to values. For example, we might opt for something more beautiful, moral or useful. </div> </blockquote> Milk can be defined conventionally as a nutritious white liquid or in the language of colloid science an oil-in-water emulsion. When a food scientist knows that milk can be precisely defined as an emulsion, they can apply general principles from colloid science to understand that system — this is valuable because the scientist values specific ends over others, like measurement, prediction and understanding. Stipulating</a> </h2> To overcome obstacles in our thinking we sometimes need a stipulative definition. Conceptual obstacles can include: Not knowing how or why to begin a project</li> Lacking a shared understanding of a system</li> A philosophical impasse about our goals</li> </ul> A stipulation can be provisional, and even false, yet still valuable. The value of the stipulation is in the process that it initiates and its foundational role in the building of a coherent conceptual model. If someone confuses your stipulation for an absolute definition then the exchange of ideas may prematurely collapse, so you need to communicate your intention clearly. Stipulating a flat world could be an interesting design prompt. It should be minimally controversial as long as people know that you are talking about — say — game development, rather than geophysics. let world_is_flat = true // this is fine let gravitational_acceleration_on_earth = 0 // so is this world_is_flat = false // it's OK to change your mind </code></pre> A stipulation can be thought of as a What if? question: What if x? What follows when x? What can we build, given x? </blockquote> Operationalising</a> </h2> When I planned scientific experiments with researchers, we would talk like this: For the sample vegan cheese replacers, “melted” was defined as the state when the G"</code> value is observed to exceed the G'</code> value during oscillatory shear </blockquote> This is an operational definition, which makes a concept easier to measure and/or quantify. In this case, it makes it easy for those versed in rheology 4</a>, who know that G"</code> and G'</code> represent liquid-like and solid-like behaviour, to quantify melting. One of the most famous operational definitions is associated with Alan Turing, and can be stated as: A machine is intelligent if and only if a human evaluator cannot distinguish between the machine and its human interlocutor when reviewing a text transcript of their conversation </blockquote> Turing devised his theoretical test of machine intelligence because he considered the contemporary philosophical debates on the matter to be unproductive. The Turing test has now been passed many times. This doesn’t mean that machines have become intelligent, only that some meet Turing’s operational definition of machine intelligence. The value in any operational definition is that it helps us grasp clearly that an idea can be tested, and that the justification for that test is sensible. As we encounter such machine “intelligence”, and become aware of its limitations, we should seek better operational definitions. Acknowledging that definitions are subject to revision or correction can replace one fear in us with another. Instead of an anxiety of fixedness, there is a nihilism of definition, in which we reject the possibility that anything can ever truly be defined. In either case, this will make us difficult collaborators, and we should become more comforable with the range and limits of definitions. ^{1 Architrave is the decorative interior moulding that frames doorways. </div> ^{2 Plinth is the lowest part of a column or wall, which may be decorated differently to the rest. </div> ^{3 An expert’s use of a term may become so specific or granular that it warrants the use of a different term entirely, as occurs in the process of what philosophers call “explication”. </div> ^{4 Rheology is the science of the flow and deformation of matter. It can be used to understand and measure properties like viscosity, hardness and melting. </div>}}}} Iconic programming 2025-04-22T00:00:00+00:00 Iconic programming is the writing of programs that resemble what they do. It can involve the prominent use of icons, which visually resemble ideas. Icons and symbols In semiotics</a>, a distinction is made between icons and symbols. Symbols signify what they reference through convention, while icons signify through resemblance. This distinction is associated with the American philosopher Charles Sanders Peirce</a>. </div> </blockquote> Symbols and icons</a> </h2> Unlike icons</a>, symbols are abstract. They don’t necessarily resemble any concrete thing. Their meaning emerges through convention, as in the everyday rules of a language. There is nothing about the following set of symbols that immediately suggest a circle. If we are familiar with some conventions in geometry, English and JavaScript then we can nonetheless interpret that drawBigCircle(3)</code> will draw a circle of radius 9</code>. let drawBigCircle = (r) => { draw.circle(r**2) } </code></pre> Pointers are pointy</a> </h2> In a letter to his wife from 1870 1</a>, Charles Sanders Peirce used simple illustrations to convey what he encountered in his European travels, including Mount Etna, the craters of which are themselves small mountains. The ^</code> in Peirce’s drawings is iconic. It resembles the wide base, steep sides and narrow peak of a mountain. Icons can also bear a resemblance to a non-physical concept. The Odin language uses ^</code> for its pointers: pointer_to_int: ^int </code></pre> In C, *</code> is instead used: int *pointer_to_int </code></pre> The Odin</a> documentation states as justification: Odin borrows the ^ syntax for pointers from the Pascal family, because it is pointy […] — my italics </blockquote> The syntax for pointer in Odin and Pascal resembles the concept of what a pointer does: it is pointy because it points 2</a>. Neither language is fully iconic, as they use combinations of both symbols and icons. The mnemonic and expressive benefits of icons can be leveraged without a wholesale adoption of an iconic language. Sand falls down</a> </h2> Icons can be used to write programs where the input resembles the output. The following syntax is from SPLAT</a>: @ => _ _ @ </code></pre> It is a rule: if a particle is above empty space it will fall into that space. The @</code> is a particle and the _</code> is empty space. In the more accessible SpaceTode</a> — a “spatial programming language” inspired by SPLAT — this rule yields a visual output: particles that fall. Taken together, the set of characters is itself iconic: the rule resembles the causal event that it generates. The creators of SPLAT (Dave Ackley</a>) and SpaceTode (Lu Wilson</a>) rightly emphasise the spatial aspect of their work, but I also think resemblance is a notable characteristic. Comments illuminate</a> </h2> In APL</a>, comments are prefixed with the ⍝</code> or “lamp” symbol: ⍝ this is a comment </code></pre> The intention is that comments illuminate the code. Comments should resemble a (metaphorical) illumination, rather than — for example — a mere recapitulation. This icon is a reminder to the programmer, but not a guarantee of illumination. Like Odin and Pascal, APL is not strictly iconic, as it contains a mixture of icons and more abstract symbols, often borrowed from mathematics. If you find APL code inscrutable, it’s probably not solely owing to its use of icons. ⍝ for illumination: https://xpqz.github.io/learnapl/aplway.html ⍉2∘⊥⍣¯1⍳2*3 </code></pre> Not just boxes</a> </h2> Visual programming is often contrasted with conventional, text-based programming. Visual programs typically rely on graphical elements, like boxes, which can be dragged and connected. These interfaces can be more convenient for specific users or for particular use-cases. Icons resemble what they represent, while a box is symbolic — an abstraction. Programming with icons does not require a graphical user interface. I can type or write ^ ^ ^</code> to represent a mountain range without a GUI. Here are some other icons with possible spatial interpretations that may be intuitive too you: ^</code> pointer</li> !</code> filter</li> ()</code> container</li> (())</code> nested container</li> o</code> loop</li> #</code> grid</li> /</code> gradient</li> @</code> atom</li> %</code> boundary</li> </ul> The concept of “resemblance” is not necessarily spatial: The stimulatory effects of coffee resemble that of tea </blockquote> Conceptually, all games share a family resemblance with each other </blockquote> Why icons?</a> </h2> I might like to program with icons because they have an immediate conceptual similarity to what I am trying to make, and the immediate mechanical simplicity of that which can be typed. This does not have to result in a needless multiplication of symbols, but there is a non-trivial challenge in selecting a finite set of icons that can capture highly generalisable ideas. For example, ideas like parthood, connection and enclosure are highly general, span numerous contexts and can be combined in many ways. A language does not need to be fully iconic, but can leverage icons to make abstract concepts more concrete. An excellent example here is the use of the pointy ^</code> for pointers in Odin and Pascal. Pipes Just as pointers can be pointy, pipes can be…pipey. In Unix, the |</code> or “pipe” is used to compose a pipeline of commands. cat log.txt | grep "error" | sort | uniq </code></pre> The |</code> seems to resemble a pipe, although I could not find any evidence of this being a reason for its original selection. </div> </blockquote> There is something powerful about the idea of “resemblance”. How can programs be made to look and feel more like what they do? What important non-visual resemblances exist and how can they be represented? References</a> </h2> Future of Coding episode 72</a>: podcast about Pygmalion, a prototype for a programming environment that uses “icons”, although the original author does not use the term in the strict, semiotic sense.</li> Ivan Reese’s visual programming Codex</a>: organised collection of visual programming tools, concepts and discussions.</li> Dave Ackley’s SPLAT</a>: Spatial Programming Language, ASCII Text, which I think has some iconic aspects.</li> Lu Wilson’s SpaceTode</a>: a spatial programming language, which I think has some iconic aspects.</li> </ul> ^{1 Nubiola, J., & Barrena, S. (2012). Drawings, Diagrams and Reasonableness in Charles S. Peirce’s Letters during his First Visit to Europe (1870-71). In Das bildnerische Denken: Charles S. Peirce. Retrieved draft version from https://www.unav.es/gep/Nubiola&BarrenaDrawings.pdf on Fri Apr 25, 2025 </div> ^{2 The meaning of an icon depends on the context of its use. We can use ^</code> to represent a pointer to a memory location or to represent a mountain. </div>}} Trying arroost 2023-11-22T00:00:00+00:00 I’ve been playing around with an early version of Arroost, a node-based tool for live sampling. New ways to do things</a> </h2> </iframe> Since the days of soundtracking my own university lectures during Covid lockdowns, I have been quietly releasing music under the name “Curtsy Rehearsed”. It was surprising to find that the music got the tiniest amount of local media attention</a> in Summer 2022. That encouraged me to take the music more seriously, which also made it less fun. I planned to sunset the Curtsy Rehearsed project, until I discovered Lu Wilson’s Arroost</a>. Arroost unlocked music for me again and I’ve never stopped making music since. Dollops</a> (August 2025)</li> Formal Garden</a> (July 2025)</li> Cop Synths</a> (July 2025)</li> Tough Centras</a> (June 2025)</li> Leisure Sick</a> (June 2025)</li> Calmlies</a> (April 2025)</li> Laconics</a> (April 2025)</li> Mulcahy</a> (March 2025)</li> Newly Sincere</a> (March 2024)</li> Kinds of Summer</a> (August 2024)</li> Micro Noirs</a> (October 2024)</li> Micro Saliences</a> (October 2024)</li> Insistence</a> (December 2024)</li> </ul> Arroost was a new way of making music for me. The process became more light and joyful than what had become painstaking, hours-long DAW</a> sessions. Arrows to sounds</a> </h2> Arroost consists of an infinite canvas on which nodes can be placed. When a newly placed node is clicked it starts to record. Make a sound then click the node again and the recording is complete. That node will now play the recording each time it is triggered. There are also special nodes for controlling the Canvas. At time of writing, these control nodes (my term) include: Add: adds a node to the canvas</li> Connect: connects two nodes</li> Remove: removes a node or connection</li> Annotate: adds text next to a block</li> </ul> Individual nodes can be connected through arrows. Nodes can be arranged in sequences using these arrows to create patterns. Given three nodes A, B and C, a loop can be created if there are the arrows A → B, B → C and C → A. Click a node in a loop and the loop will play continuously. In the image below a loop can be seen connected by red arrows. Currently the bottom node in the loop is being triggered. This will be followed by the top-right node and so on. User interface of Arroost showing control nodes (Add, Connect, Remove and Annotate) and example sound structures (single node, node sequence, node loop). There are some other nuances in the design: empty nodes can be used to create rests within sequences; the start time of a recorded sample can be offset; arrows can be coloured to control the flow of sounds. Many of these features can be discovered naturally through play. Watch the creator of Arroost — Lu Wilson — demo the tool at a live event in London (includes a brief snippet of my first Arroost recording!)</a> The core of Arroost involves connecting nodes. This makes Arroost an easy and intuitive live-looper. By easy I mean relative to using a DAW like Reaper: User interface of Reaper DAW with four vocal tracks routed into an instance of its Super8 looper. This works great but it takes some setting up and the interface is busy. Despite its apparent simplicity, Arroost can be used to create some complex sounds. Only live vocal samples recorded into my microphone were used to create the following video, in which you can see the nodes and connections in action: </iframe> Becoming unlocked</a> </h2> Below is a short megamix “Leisure Sick” containing eight snippets of my Arroost experiments. I have high quality version of the full tracks as a private release on Bandcamp and you can contact me at edibotopic@gmail.com</a> if you want a download code. Your browser does not support this audio. </audio> </div> There are vocals strewn across all of my albums but usually as minor details and often warped beyond recognition. Arroost encouraged me to use more vocals through its Emphasis on live recording: it’s possible to do some pre-recorded sampling with Arroost; for example, you can change the audio input settings on your computer and record a drumbreak on YouTube. Arroost is configured, however, to use your default mic for live sampling. The most immediate recording option is to just sing, hum, chant, clap and bang. I could record 5 seconds of sounds with 4 dodgy seconds and then take the 1 second I liked for the rest of the song. It’s amazing how far this approach can take you as the connections build up.</li> Limited control of mix quality: one of the factors that makes recording vocals difficult is the need for noise-reduction. Usually this requires recording some ambient noise and subtracting it from the recording. This needs continuous tweaking and can result in poor quality audio if you’re not in a good recording environment (I rarely am). With Arroost I couldn’t do noise reduction, so I stopped caring and just focused on recording.</li> Coupling of audio and visuals: I normally make songs that are built from hundreds of samples and recordings. When people listen I sometimes get the impression that they don’t know exactly what I did — it’s a black box. Arroost generates a tightly-coupled combination of audio and visuals. Even if sharing a finished set of nodes and connections, there is an embedded performance. I probably couldn’t sing at your wedding but I can put vocal snippets together into an interesting structure — I think Arroost helps show this.</li> </ul> “Share scrappy fiddles”</a> </h2> Encouraged by the developer Lu Wilson</a>’s call to Normalise sharing scrappy fiddles </blockquote> I shared my Arroost creations on a (now defunct) Mastodon account as short videos. All in all, I recorded about 60 minutes of music in three weeks. I stopped when Arroost simply became too addictive! Lu is continuing to work on Arroost. From talking with them, the tool will likely evolve considerably. While writing this post I set up some basic nodes and connections in Arroost to grab a screenshot. Soon after I realised that arrows could now be coloured and that this affected the flow of sound!!! This arrow-colouring novelty immediately made me want to stop writing and start experimenting with Arroost again… In its current state, Arroost is a great tool for rapidly iterating on song ideas. Although I didn’t use it when making the newest Curtsy Rehearsed projects I think Arroost got me back to a place where I could make something again. Links</a> </h2> Arroost</a></li> Lu’s essay on Arroost</a></li> My music on BandCamp</a></li> </ul> Versioning for student work 2023-07-15T00:00:00+00:00 Version control is a powerful tool commonly used in large software projects. It is valuable for other types of project too, including academic writing. This blog is cited in a short guide on Assessment in the Age of AI</a> by University College Cork. Probably more useful than the blog is this handout</a> I provide to students and academics who are interested in versioning but may not be familiar with the concept. Motivation</a> </h2> Students are asked to write because writing is considered useful. Muddled thoughts can be clarified once an attempt is made to write them down. Extracting key information on a topic and combining them into an overview is often far more effective than merely reading about the topic. Although writing is a process, student work is often corrected as a static artifact. The final version is assessed and deemed a reflection of that underlying process. In an era of Large Language Models, there is an increasing probability that this final version is the only version and it was drafted by an undetectable AI. Perhaps then the process of writing — the thing that we value — needs to be re-emphasised. An analog solution is simply to require students to perform their writing in-person. However, this is not always a fair, accessible or practical approach. Serious essays, literature reviews and group projects often involve many hours of work, dead-ends and revisions. It is not feasible to translate this process to an in-person scenario, and it is also not aligned with a workplace that is increasinly digitalised and dispersed. To work effectively, student and teachers alike have to buy into the idea that versioning helps them both. It helps students to structure their writing process, protects them against lost work, and keeps track of their collaborations. It helps teachers gain insights into the student’s writing process and uncovers opportunities for feedback. Background</a> </h2> Working on any large project often demands working with versions. When writing a paper, you typically have multiple drafts. It can be useful to distinguish these with appropriate names. For example: myDraft1.docx</code>, myDraft2.docx</code>, and so on. This is a simple form of version control, although it gets messy. The first scientific paper that I published had 13 drafts! Another problem with this approach is that it becomes difficult to actually compare across the versions. If draft 12 and 13 each have dozens of pages and numerous changes, how can you actually find what you changed? Version control systems — in simple terms — allow you to edit only a single file while storing a history of its different versions, any of which can be restored at a later time. Getting started with versioning</a> </h2> Git is probably the most popular version control system among writers of computer programs and technical documentation. Git is typically used in conjunction with GitHub, a web-based platform for hosting versioned projects and structuring collaboration. Git, however, has a steep learning curve. Google Docs</a> is one of the easiest ways to get started with versioning. It may not be the best system — especially compared to a dedicated tool like Git</a> — but it works and is easy-to-use. Two immediate advantages of versioning student work are: Structure: the expectation that writing projects should have multiple, dated versions can reduce the tendency to write (or copy) everything in one big draft, encouraging instead a more deliberate approach to writing.</li> Transparency: the contributions of individual students to groupwork are highlighted clearly, alerting the group and the teacher to any disparaties in effort.</li> </ol> Versioning is not a general solution for plagiarism and AI usage, although it can be considered a hurdle — to be combined with others — against ineffective approaches to writing. Use versioning as a student</a> </h2> Create a new Google Docs file and give it an appropriate name, such as AIandFoodPaper</code>. Decide what your first task will be; for example, it could be write a rough draft of the project structure. When you have written this draft, select: File > Version History > Name Current Version</code> Give a descriptive name to the version 1</a>. In this case, it could be: Drafted a project structure for AI and Food paper </blockquote> Your next version might be: Drafted an introduction, focusing on AI in data analysis </blockquote> Each time you create a version, it is saved to the version history. This can be viewed by you or anyone else with edit access: File > Version History > View Version History</code> Versions are grouped by month and include details, such as the version name, date/time saved and version author. Contributions by different authors to the same file will be highlighted in a unique colour 2</a>. When you select a version, any edits (additions, deletions) are displayed. If a major error is introduced in a project, a previous version can be restored at any time. Examples of versioning</a> </h3> Named versions should typically involve a substantial, self-contained change. Here are some good examples: Drafted a structure for the project</code> + Title: AI Technology in the food industry + 1. Introduction + 2. Data Analysis + 3. Product Design + 4. Computer Vision + 5. Conclusions </code></pre> Clarified and developed statement regarding new AI technology</code> - AI technologies like ChatGPT display human-like intelligence - and may allow the automation of tasks normally done by humans. + AI technologies like ChatGPT are based on Large Language Models + (LLMs), which — although powerful — have limitations. + Currently, for example, they have limited capacity + to problem-solve when presented with novel scenarios (TODO: add ref). </code></pre> Added reference to support claim regarding AI limitations</code> - Currently, for example, they have limited capacity - to problem-solve when presented with novel scenarios (TODO: add ref). + For example, Crowley (2042), compared humans with an AI in a + series of problem-solving activities and found that humans + out-performed the AI in 20% of the activities. </code></pre> Bad examples come in broadly two forms. The first is a large set of trivial versions. For example, 10 different versions that correct individual typos, which could have been grouped into one version if handled together. Every change or new sentence does not necessarily warrant its own version. The previous example above could have been longer, while still being one version: - Currently, for example, they have limited capacity - to problem-solve when presented with novel scenarios (TODO: add ref). + For example, Crowley (2042), compared humans with an AI in a + series of problem-solving activities and found that humans + out-performed the AI in 20% of the activities. + This suggests that there is still a role for + humans in the performance of these tasks. + However, there was one key limitation of Crowley's work... + ... </code></pre> The second bad example is a single version with a complex set of unrelated changes. This might be a version that includes the deletion of one section, the addition of two others, a change in the title, the addition of images, and a restatement of the central thesis. These changes could probably have been sub-divided and given their own versions. Inevitably there are occasions where different types of change have been made, which can be referred to in a single description: Updated figure 3 and corrected typos in main text</code> However, an effort should be made to avoid doing a substantial amount of unstructured work across the entire paper that is then grouped into one version. Each time you approach your project, you should be thinking: “What specific task am I focusing on now”. Use versioning as a teacher</a> </h2> To make the version history accessible, students need to share the actual Google Docs file. If the file needs to be passed through a plagiarism-detector, they can also download the file in an appropriate format suitable for upload. To share the Docs file, select: File > Share > Share with Others</code> To ensure there are no issues with file access, the General Access setting in the popup dialog can be changed from “Restricted” to “Anyone with a Link”. This is important primarily for cases where a teacher does not have a Gmail account (rare). When you receive this link, you should be able to access the version history as described earlier. If you also require students to upload the file to an LMS like Canvas or Blackboard, they will first need to download the file in a suitable format. In File > Download</code> both Word (.docx) and .pdf formats are available. Reviewing work</a> </h3> The version history is a supplement to the assessment process. A good version history might be expected to demonstrate: Consistent work on the project over time</li> Evidence of iteration and editing of own writing</li> Descriptive version names that identify major changes</li> Solutions to different writing problems (referencing, logic, organisation, visualisations, editing)</li> Balance of workload across collaborators (group projects)</li> </ul> If you are suspicious that a project has been plagiarised or AI-generated, the version history is another tool for you to evaluate the process behind the writing. When feedback on writing is a part of your assessment process, the version history provides a useful reference point for both student and teacher. Students might ask the question: How many versions will I need to get a good mark? </blockquote> Similar questions are often asked about numbers of citations and numbers of words — they all usually miss the point. Any significant writing project will consist of more than one version, usually many more, but a precise number cannot be given. It is possible for there to be 100 versions that each only make trivial changes (typos, spelling) — the high number does not necessarily reflect strong writing. In comparison, 10 or 20 versions, which showcase a range of activities, including additions, deletions, rewordings, citations and clarifications, might be more compelling evidence of effort. If the students get the impression that they are trying to hit a number, rather than approach their writing in a structured manner, then the exercise is a waste of everyone’s time. ^{1 Google Docs limits users to 40 named versions. They should be used judiciously, especially on collaborative projects. </div> ^{2 Office365’s browser-based Word has version history features similar to Google Docs. At time-of-writing, however, Word does not support named versions. </div>}}

Edibotopic blog

Being right about one thing

Survey of ambiguities

Aspirational procedures

Stokes' Law

Systemism

Survey of definitions

Iconic programming

Trying arroost

Versioning for student work

Edibotopic blog

Being right about one thing

Survey of ambiguities

Ambiguity in technology</a> </h2> Technology can be ambiguous in different ways. There can be ambiguity of:</p> Function</strong>: multiple interpretations of what it does</em></li> Procedure</strong>: multiple interpretations of how to use it</em></li>

Ambiguity and generalisation</a> </h2> Both ambiguity and generalisation involve one-to-many relationships:</p> Ambiguity</strong>: one perception with many possible interpretations</li>

Ambiguity and mental processing</a> </h2> Ambiguity is a feature of many creative works, which attract varying interpretations.</p> Tell all the truth but tell it slant</p> — Emily Dickinson</p> </blockquote>

Aspirational procedures

Stokes' Law

Systemism

Survey of definitions

Operationalising</a> </h2> When I planned scientific experiments with researchers, we would talk like this:</p> For the sample vegan cheese replacers, “melted” was defined as the state when the G"</code> value is observed to exceed the G'</code> value during oscillatory shear</p> </blockquote>

Iconic programming

Trying arroost

Versioning for student work