https://community.wolfram.com RSS Feed for Wolfram Community showing any discussions tagged with Signal Processing sorted by active. https://community.wolfram.com/groups/-/m/t/3729239 # Informational Metabolics in a Dual-Phase Cellular Automaton: Verifiable Delay Functions, 4x21 Geometric Confinement, and the Algorithmic Exhaust of Observation ### Author’s Prologue: A Path to Cellular Automata Before diving into the mechanics of Linked Digital Dynamics (LDD), I want to briefly share the context of this work. My background did not begin in theoretical physics; it began in the social sciences. I was studying the emergent behaviors of complex networks and agents, which eventually required me to move under increasing confinement into the strict logic of number theory to test my intuition. My guiding thesis through this interdisciplinary journey was a simple epistemological equation: $1 = O + C + E$. For anything to be considered part of classical reality ($1$), it must be Observable ($O$), Communicable ($C$), and Effectual ($E$). For years, I operated on this intuitive conjecture, trying to map how ideal models resolve into logical, computational realities. As I refined this into Latin square dynamics, I belatedly realized that the mathematics of information, communication, and computation theory were always leading me to a single destination: Cellular Automata. Discovering that the Wolfram Physics Project and Mathematica had already established the exact computational environment needed to resolve these intuitive models was a revelation. As you read the following framework and experiment with the code, you will see how the LDD engine is simply the literal, discrete execution of this equation—where observation is geometric confinement, communication is phase-locking, and effect is the thermodynamic drag of computation. --- ### 1. Abstract The Wolfram Physics Project has provided a profound new lens for viewing spacetime as an emergent property of discrete computation. Yet, as a community, we often grapple with the combinatorial explosion inherent in un-pruned multiway systems—what might be thought of as a "Cosmological Halting Problem." This paper introduces **Linked Digital Dynamics (LDD)**, an exploratory cellular automaton that attempts to model a strict thermodynamic filter over these multiway branches. By treating the substate as a simple $6 \times 6$ dual-phase grid, we observe that even minimal localized interactions generate massive combinatorial phase spaces (e.g., $2^{72}$ conditions). To explore how a universe might compute this without freezing, LDD introduces a simulated physical cost: a **Verifiable Delay Function (VDF)**. Using a $4 \times 21$ geometric confinement matrix (the "Anvil Strike"), this toy model shears off incompatible geometries as **Algorithmic Exhaust** (entropy). Through an executable Wolfram Language Macro-Engine shared below, we can visually explore how this underlying "Informational Metabolic Hunt" naturally segregates a chaotic substate into stable, fast-ticking islands and dense, slow-ticking wells. LDD is presented here as a computational sandbox to invite community feedback on whether emergent gravity and relativistic time dilation might be fruitfully modeled as the macroscopic unevenness of computational friction. --- ### 2. Introduction: Exploring the Cosmological Halting Problem Like many in this community, I have been deeply inspired by the shift toward modeling physics as fundamental, discrete computation. However, while experimenting with localized multiway graphs, I repeatedly ran into a practical computational wall. If every point in space represents a discrete locus evaluating causal branches, the system must navigate a massive phase space of potential states. Consider a minimal collision of two $6 \times 6$ binary substates (an un-sponged False Vacuum). This simple interaction yields over 4.7 sextillion ($2^{72}$) possible combinatorial starting conditions. If the universe were purely probabilistic and smooth, searching through this phase space to find a stable interaction seems computationally prohibitive. Without a rigorous pruning mechanism, a discrete universe risks freezing under the weight of its own combinatorial explosion. **Testing a Thermodynamic Cost for Computation** Linked Digital Dynamics (LDD) is my attempt to build a computable model that addresses this by enforcing a strict thermodynamic cost for time. Inspired by cryptographic principles, I wanted to test what happens if the multiway graph is aggressively filtered by **Topological Drag**—a Verifiable Delay Function (VDF) that forces potential states to "prove" their structural integrity before solidifying. This led to the concept of **Informational Metabolics**. In this framework, a pro-causal trajectory does not calculate all possible futures; it "hunts" for adjacent structural support within a rigid $4 \times 21$ spatial confinement matrix. If the geometry perfectly phase-locks, it metabolizes that potential into a stable structure. If it fails, the unmatched data is sheared off into the substate as Algorithmic Exhaust. --- ### 3. Ontology of the Strata: Substate, Microstate, and Macrostate To circumvent the combinatorial explosion of the multiway graph, LDD proposes that reality does not compute in a single continuous layer. Information must survive severe geometric compression to ascend from pure potential to classical reality. * **I. The Substate (The False Vacuum):** The foundational layer, modeled computationally as a $6 \times 6$ branchial buffer. This is a region of pure, un-sponged potential—a completely frictionless state of non-constructive optimism where multiway branches freely generate. It possesses zero entropy. * **II. The Microstate (The Thermodynamic Forge):** Defined by the **$4 \times 21$ Geometric Confinement Matrix**. When two offset causal trajectories attempt to interact, their multiway potential is forced into an orthogonal cross-reading we call the **Anvil Strike**. It is a literal cryptographic pruning function testing if discrete geometries can support one another. * **III. The Macrostate (Linear Indifference):** The resulting classical reality, composed exclusively of localized motifs that survived the Anvil Strike. A Macrostate observer exists in a state of **Linear Indifference**—because its internal structure balances the thermodynamic drag, it feels no friction from its own existence, experiencing discrete processing purely as smooth spacetime. --- ### 4. Cryptographic Thermodynamics: The Cost of Observation In classical physics, entropy is a measure of disorder. In LDD, entropy is strictly redefined as **Algorithmic Exhaust**—the literal byproduct of failed computation. Because the substate is continuously attempting to expand, the universe requires an anchoring mechanism. The VDF acts as the fundamental clock speed of the universe, imposing **Topological Drag** modeled as a $+2, -1$ pro-causal ratchet. The $+2$ represents optimistic branchial generation, and the $-1$ represents the thermodynamic computational cost exacted by the universe. When a trajectory enters the $4 \times 21$ confinement cage, the VDF enforces **Mutually Assured Cooperation**. Optimistic multiway data only survives if it has adjacent structural support. Incompatible data snaps under the tension and is sheared off the event horizon back into the substate as Algorithmic Exhaust. --- ### 5. Informational Metabolics: The Darwinian Engine of Reality LDD requires a radical inversion of perspective: a localized multiway branch is an active, hungry computational agent. We term this survival mechanism the **Informational Metabolic Hunt**. The massive $2^{72}$ combinatorial phase space of the False Vacuum is the raw caloric potential of the universe. As a trajectory is pushed forward by the VDF, it must consume this substate potential to maintain phase-lock. A successful "hunt" occurs when two distinct trajectories possess the exact geometric seeds required to interlock. Conversely, trajectories with incompatible seeds cannot metabolize the local substate; they "starve" within the Anvil Strike and drop out of the macro-reality. Only the most geometrically optimized structures survive the friction of time. --- ### 6. Informational Relativity and Cosmogenesis Because LDD posits that time is locally computed labor rather than a universal background dimension, there is no absolute clock. By decoupling a local observer's VDF speed from the computational phase of an external node, we organically generate **Informational Relativity**. A stable macrostate motif requires an $8 \times 8$ harmonic membrane to resolve chiral pressure. The literal edge of this membrane acts as the particle's **Event Horizon**, which exhibits **Causal Elasticity**. An observer can tolerate a slight relational phase offset ($\Delta$) with an external node without breaking phase-lock. However, if the relativistic tension exceeds the harmonic capacity, the boundary violently shears into Algorithmic Exhaust. This perfectly mirrors Einsteinian mechanics: * **Spatial Expansion (Redshift):** If an external node's VDF computes slower ($\Delta > 0$), the computational channel stretches. * **Informational Collisions (Blueshift):** If the node computes faster ($\Delta < 0$), the computational distance collapses, aggressively forcing its multiway state onto the observer. --- ### 7. The LDD Engine: A Computable Laboratory To move from philosophy to falsifiable physics, I have developed a native Wolfram Language laboratory. **I. The Holographic Relativistic Micro-Engine** This module isolates a single $4 \times 21$ Anvil Strike. Using the dual-slider architecture, you can physically drag an external node through the entire spectrum of informational Doppler shift. You can also load highly ordered "Custom Seeds" (orthogonal arrays) to witness how perfect geometry acts as a "Still Life," surviving VDF loops without evaporating. ```mathematica ClearAll[SeedFrameA, SeedFrameB, InitializeFalseVacuum, VDFSubstateMix, AnvilStrike, LDDChronoverticalTick, LDDDashboard]; (* I. CUSTOM STARTING CONDITIONS *) SeedFrameA = {{1, 0, 1, 0, 1, 0}, {0, 1, 0, 1, 0, 1}, {1, 0, 1, 0, 1, 0}, {0, 1, 0, 1, 0, 1}, {1, 0, 1, 0, 1, 0}, {0, 1, 0, 1, 0, 1}}; SeedFrameB = {{1, 1, 1, 1, 1, 1}, {0, 0, 0, 0, 0, 0}, {1, 1, 1, 1, 1, 1}, {0, 0, 0, 0, 0, 0}, {1, 1, 1, 1, 1, 1}, {0, 0, 0, 0, 0, 0}}; InitializeFalseVacuum[] := RandomInteger[1, {6, 6}]; VDFSubstateMix[grid_] := Mod[grid + ListConvolve[{{1, 1, 1}, {1, 0, 1}, {1, 1, 1}}, grid, 2], 2]; (* II. MICROSTATE CONFINEMENT & ALGORITHMIC EXHAUST *) AnvilStrike[gridA_, gridB_, ticksA_, ticksB_] := Module[ {trajA, trajB, phaseSpace, cage, stabilizedCage, preSum, postSum, entropy}, trajA = Join[Flatten[gridA], IntegerDigits[Mod[ticksA, 64], 2, 6]]; trajB = Join[Flatten[gridB], IntegerDigits[Mod[ticksB, 64], 2, 6]]; phaseSpace = Join[trajA, trajB]; cage = Partition[phaseSpace[[Mod[Range[84]*5, 84] + 1]], 21]; preSum = Total[Flatten[cage]]; stabilizedCage = cage * UnitStep[ListConvolve[{{1, 1, 1}, {1, 0, 1}, {1, 1, 1}}, cage, {2, 2}, 0] - 1]; postSum = Total[Flatten[stabilizedCage]]; entropy = preSum - postSum; <|"Microstate" -> stabilizedCage, "Entropy" -> entropy, "ExhaustBits" -> (cage - stabilizedCage)|> ]; (* III. CHRONOVERTICAL TICK *) LDDChronoverticalTick[gridA_, gridB_, localVDF_, deltaVDF_] := Module[ {ticksA, ticksB, mixedA, mixedB}, ticksA = localVDF; ticksB = Max[0, localVDF + deltaVDF]; mixedA = Nest[VDFSubstateMix, gridA, ticksA]; mixedB = Nest[VDFSubstateMix, gridB, ticksB]; AnvilStrike[mixedA, mixedB, ticksA, ticksB] ]; (* IV. INTERACTIVE DASHBOARD *) LDDDashboard[] := DynamicModule[ {gridA, gridB, result}, gridA = SeedFrameA; gridB = SeedFrameB; Manipulate[ result = LDDChronoverticalTick[gridA, gridB, localVDF, deltaVDF]; Column[{ Style["LDD: Holographic Relativistic CA Engine", Bold, 16, FontFamily -> "Helvetica"], Spacer[10], Row[{Style["Local VDF Speed: ", 12], Style[localVDF, Bold, 14], Spacer[20], Style["Relativity (\[Delta]): ", 12], Style[deltaVDF, Bold, 14], Spacer[30], Style["Algorithmic Exhaust (Entropy): ", 12, Red], Style[result["Entropy"], Bold, 16, Red]}], Spacer[15], Text@Grid[{{Column[{Style["Observer A Frame (Local)", 10], ArrayPlot[Nest[VDFSubstateMix, gridA, localVDF], ImageSize -> 130, Mesh -> True, ColorFunction -> "DeepSeaColors"]}], Column[{Style["Observer B Frame (External)", 10], ArrayPlot[Nest[VDFSubstateMix, gridB, Max[0, localVDF + deltaVDF]], ImageSize -> 130, Mesh -> True, ColorFunction -> "DeepSeaColors"]}]}}, Spacings -> {5, 1}], Spacer[20], Style["Phase-Locked Microstate (4x21 Confinement)", Bold, 12], ArrayPlot[result["Microstate"], ImageSize -> 550, Mesh -> True, ColorFunction -> "SunsetColors"], Spacer[10], Style["Non-Constructive Optimism (Sheared Entropy)", 10, Gray], ArrayPlot[result["ExhaustBits"], ImageSize -> 550, Mesh -> True, ColorFunction -> "Monochrome"] }, Alignment -> Center], {{localVDF, 42, "Observer A Baseline (Local VDF)"}, 1, 256, 1, Appearance -> "Labeled"}, {{deltaVDF, 0, "Informational Relativity (\[Delta])"}, -512, 512, 1, Appearance -> "Labeled"}, Row[{Button["Load Custom Seeds (A & B)", {gridA = SeedFrameA; gridB = SeedFrameB;}], Spacer[10], Button["Generate Random Vacuum", {gridA = InitializeFalseVacuum[]; gridB = InitializeFalseVacuum[];}]}], ControlPlacement -> Top, TrackedSymbols :> {localVDF, deltaVDF} ] ] LDDDashboard[] ``` **II. The Macroscopic Spacetime Lattice (Deep Time Simulation)** This module expands the engine into a macroscopic lattice of 144 interacting observers. Using Deep Time Controls, you can age the universe by hundreds of ticks instantly. You will observe the False Vacuum segregate into cold islands of stable matter (fast-ticking clocks / vacuum) and dense, hot entropic borders (slow-ticking clocks / time dilation). ```mathematica ClearAll[InitializeMacroVacuum, VDFSubstateMix, MacroAnvilStrike, MacroNetworkTick, LDDMacroDashboard]; InitializeMacroVacuum[size_] := Table[<|"Substate" -> RandomInteger[1, {6, 6}], "VDFClock" -> 0, "Entropy" -> 0.0|>, {size}, {size}]; VDFSubstateMix[grid_] := Mod[grid + ListConvolve[{{1, 1, 1}, {1, 0, 1}, {1, 1, 1}}, grid, 2], 2]; MacroAnvilStrike[nodeA_, nodeB_] := Module[ {trajA, trajB, phaseSpace, cage, stabilizedCage, preSum, postSum}, trajA = Join[Flatten[nodeA["Substate"]], IntegerDigits[Mod[nodeA["VDFClock"], 64], 2, 6]]; trajB = Join[Flatten[nodeB["Substate"]], IntegerDigits[Mod[nodeB["VDFClock"], 64], 2, 6]]; phaseSpace = Join[trajA, trajB]; cage = Partition[phaseSpace[[Mod[Range[84]*5, 84] + 1]], 21]; preSum = Total[Flatten[cage]]; stabilizedCage = cage * UnitStep[ListConvolve[{{1, 1, 1}, {1, 0, 1}, {1, 1, 1}}, cage, {2, 2}, 0] - 1]; postSum = Total[Flatten[stabilizedCage]]; preSum - postSum ]; MacroNetworkTick[network_] := Module[ {size, nextNetwork, n, s, e, w, localEntropy}, size = Length[network]; nextNetwork = network; Do[ n = network[[Mod[i - 1, size, 1], j]]; s = network[[Mod[i + 1, size, 1], j]]; e = network[[i, Mod[j + 1, size, 1]]]; w = network[[i, Mod[j - 1, size, 1]]]; localEntropy = Mean[{MacroAnvilStrike[network[[i,j]], n], MacroAnvilStrike[network[[i,j]], s], MacroAnvilStrike[network[[i,j]], e], MacroAnvilStrike[network[[i,j]], w]}]; If[localEntropy < 1.5, nextNetwork[[i,j, "VDFClock"]] += 1; nextNetwork[[i,j, "Substate"]] = VDFSubstateMix[network[[i,j, "Substate"]]];]; nextNetwork[[i,j, "Entropy"]] = localEntropy; , {i, size}, {j, size}]; nextNetwork ]; LDDMacroDashboard[] := DynamicModule[ {gridSize = 12, macroNetwork, totalAge = 0}, macroNetwork = InitializeMacroVacuum[gridSize]; Manipulate[ Column[{ Style["LDD: Macroscopic Spacetime Lattice", Bold, 16, FontFamily -> "Helvetica"], Spacer[5], Row[{Style["Age of Universe (Total Ticks): ", 14, White], Style[totalAge, Bold, 16, Cyan]}], Spacer[15], Row[{ Column[{Style["Algorithmic Exhaust (Gravitational Heatmap)", Bold, 12, White], Style["Dark = Perfect Phase Lock (Baryonic Matter/Vacuum)\nBright/Hot = High Entropy (Event Horizons/Chaos)", 10, Gray], MatrixPlot[Map[#["Entropy"] &, macroNetwork, {2}], ColorFunction -> "ThermometerColors", ImageSize -> 300, Frame -> False, Mesh -> True, MeshStyle -> Opacity[0.2]]}], Spacer[40], Column[{Style["Informational Relativity (Local VDF Ticks)", Bold, 12, White], Style["Bright = Fast Clocks (Low Drag)\nDark = Slow Clocks (Time Dilation/Gravity Wells)", 10, Gray], MatrixPlot[Map[#["VDFClock"] &, macroNetwork, {2}], ColorFunction -> "SunsetColors", ImageSize -> 300, Frame -> False, Mesh -> True, MeshStyle -> Opacity[0.2]]}] }] }, Alignment -> Center, Background -> Black], Row[{Style["Advance Time: ", Bold, 12], Button["+1 Tick", {macroNetwork = MacroNetworkTick[macroNetwork]; totalAge += 1;}], Button["+10 Ticks", {Do[macroNetwork = MacroNetworkTick[macroNetwork], {10}]; totalAge += 10;}], Button["+100 Ticks", {Do[macroNetwork = MacroNetworkTick[macroNetwork], {100}]; totalAge += 100;}]}], Spacer[10], Button["Inject Big Bang (Regenerate Network)", {macroNetwork = InitializeMacroVacuum[gridSize]; totalAge = 0;}], ControlPlacement -> Top ] ] LDDMacroDashboard[] ``` --- ### 8. Conclusion and Call to Action: Mining the Substate Linked Digital Dynamics demonstrates that a discrete, computable universe must possess a physical thermodynamic cost to prevent a combinatorial explosion. The Cosmological Halting Problem is solved by the Verifiable Delay Function—a pro-causal ratchet that violently shears off non-constructive optimism as Algorithmic Exhaust. In this model, gravity, time dilation, and event horizons are simply emergent, macroscopic artifacts of localized computational friction. I present this framework not as a completed map of physics, but as a foundational sandbox. The true work lies in exploring the $2^{72}$ phase space of the False Vacuum. I issue a direct challenge to the Wolfram Community: **Mine the Substate.** Using the provided Mathematica engine, search the combinatorial starting conditions for the exact binary seeds—the cryptographic "Latin squares" and orthogonal arrays—that yield perfectly stable, zero-entropy loops. By discovering which specific geometric matrices survive the thermodynamic forge of the $4 \times 21$ Anvil Strike, we can begin to isolate the literal discrete DNA of ordinary matter, dark matter, and the frictionless vacuum. Steven De Costa 2026-06-08T07:49:22Z https://community.wolfram.com/groups/-/m/t/3725403 ![Superoscillations Part 2: Phase vortices, quantum potential and free evolution of wave packets][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=4313hero.png&userId=20103 [2]: https://www.wolframcloud.com/obj/74e74fc0-e0b8-4eb6-ba63-9cbad970ab82 Bruno Tenorio 2026-06-01T17:46:43Z https://community.wolfram.com/groups/-/m/t/3715438 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/2dd621c0-ea9a-45aa-88da-6e4db8750a21 Jana Rusrus 2026-05-13T02:52:25Z https://community.wolfram.com/groups/-/m/t/2187926 Where can I find an explanation of the options for FourierParameters? The "Get Help" documentation just gives some "common choices" without explanation. There are apparently two parameters that control how Mathematica calculates the expression returned. Jay Gourley 2021-02-08T03:33:52Z https://community.wolfram.com/groups/-/m/t/3713462 ![Superoscillations Part I: 1D foundations, leaky functions and quantum wavefunctions][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Image20260511195639.png&userId=20103 [2]: https://www.wolframcloud.com/obj/8d53f8f8-2805-49dd-b7bc-ee20599a9be9 Bruno Tenorio 2026-05-08T22:22:16Z https://community.wolfram.com/groups/-/m/t/3710670 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/d67fd36a-d01f-41e6-bcc2-939ceed7aed9 Marco Thiel 2026-05-03T19:10:32Z https://community.wolfram.com/groups/-/m/t/3710411 ![Photographing the quantization of light][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=Photographingthequantizationoflight.png&userId=20103 [2]: https://www.wolframcloud.com/obj/3a9d99d6-b7bd-472c-a8f1-3a4cd19c7cb0 Mohammad Bahrami 2026-05-01T14:54:40Z https://community.wolfram.com/groups/-/m/t/3674222 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/4dcf93ed-d510-4c9d-942b-f6fa8a951ecd Jana Rusrus 2026-04-04T17:10:12Z https://community.wolfram.com/groups/-/m/t/3673172 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/1a2195f5-f342-4069-9a09-da04b2e23137 Dara Shayda 2026-04-01T22:43:34Z https://community.wolfram.com/groups/-/m/t/3660024 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/9f4999ac-49ef-427f-ae84-87f00ee39f73 Jana Rusrus 2026-03-13T14:50:35Z https://community.wolfram.com/groups/-/m/t/3646965 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/4f0a4ff2-ffad-46b5-ab11-ba4964d1a296 Jana Rusrus 2026-02-28T15:27:16Z https://community.wolfram.com/groups/-/m/t/3641062 I have a two members list with a very noisy behaviour. I tried differents kernel as for example SavitskyGolay and median method bot the results are no acceptable. Juan Fuentes 2026-02-17T21:13:54Z https://community.wolfram.com/groups/-/m/t/3589102 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/9f23858c-9e7c-4883-8a89-dc7e65f09a5d Guhan Thiagarajan 2025-12-11T00:20:39Z https://community.wolfram.com/groups/-/m/t/3580921 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/c6388a9d-cdfc-4d41-9d79-caccd5ba5c68 Adael Reyes 2025-11-23T22:34:43Z https://community.wolfram.com/groups/-/m/t/2527035 A Wolfram U daily study group on "Signals, Systems and Signal Processing" begins on May 16, 2022. Join instructors [@Leila Fuladi][at0] and [@Mariusz Jankowski][at1] and a cohort of fellow learners to study the concepts, mathematics, principles and techniques of signal processing. We'll cover methods of analysis for both continuous-time and discrete-time signals and systems, sampling and introductory filter design. The concepts and methods of signals and systems play an important role in many areas of science and engineering and many everyday signal processing examples are included. A basic working knowledge of the Wolfram Language is recommended. **[REGISTER HERE][1]** ![enter image description here][2] [1]: https://www.bigmarker.com/series/daily-study-group-signals-systems-and-signal-processing/series_details?utm_bmcr_source=community [2]: https://community.wolfram.com//c/portal/getImageAttachment?filename=WolframUBanner.jpeg&userId=130003 [at0]: https://community.wolfram.com/web/leilaf [at1]: https://community.wolfram.com/web/mariuszj Abrita Chakravarty 2022-05-06T22:26:34Z https://community.wolfram.com/groups/-/m/t/3572151 ![Temperature sensing by the calcium-sensing receptor][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=3588Temperaturesensingbythecalcium-sensingreceptor3.png&userId=20103 [2]: https://www.wolframcloud.com/obj/09f283ea-56d5-462c-b25b-ab526b9c8ce0 Philip Kuchel 2025-11-07T19:19:53Z https://community.wolfram.com/groups/-/m/t/3553666 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/4ed0e3bd-bb8c-4b1a-9492-b0a297c141b0 Carlo Réan 2025-10-01T15:43:09Z https://community.wolfram.com/groups/-/m/t/3551641 &[Wolfram Notebook][1] [1]: https://www.wolframcloud.com/obj/33a41820-c999-4515-81be-555ebda62982 Dara Shayda 2025-09-26T13:19:06Z https://community.wolfram.com/groups/-/m/t/1383630 During this year's Wolfram Summer Camp, being mentored by Christian Pasquel, I developed a tool that identifies chord sequences in music (from MIDI files) and generates a corresponding graph. The graph represents all [unique] chords as vertices, and connects every pair of chronologically subsequent chords with a directed edge. Here is an example of a graph I generated: ![Graph genehrated from Bach's prelude no.1 of the Well Tempered Klavier (Book I)][1] Below is a detailed account on the development and current state of the project, plus some background on the corresponding musical theory notions. #Introduction       **GOAL** | The aim of this project is to develop a utility that identifies chords (e.g. C Major, A minor, G7, etc.) from MIDI files, in chronological order, and then generates a graph for visualizing that chord sequence. In the graph, each vertex would represent a unique chord, and each pair chronologically adjacent chords would be connected by a directed edge (i.e. an arrow). So, for example, if at some point in the music that is being analyzed there is a transition from a major G chord to a major C chord, there would be an arrow that goes from the G Major chord to the C Major chord. Therefore, the graph would describe a [Markov chain][2] for the chords. The purpose of the graph is to visualize frequent chord sequences and progressions within a certain piece of music.       **MOTIVATION** | While brainstorming for project ideas, I don't know why, I had a desire to do something with graphs. Then I asked myself, "What are graphs good at modelling?". I mentally browsed through my areas of interest, searching for any that matched that requirement. One of my main interests is music; I am somewhat of a musician myself. And, in fact, [musical] harmony *is* a good subject to be modelled by graphs. Harmony, one of the fundamental pillars of music (and perhaps the most important), not only involves the chords themselves, but, more significantly, the *transitions* between those, which is what gives character to music. And directed graphs, and, specifically, Markov models, are a perfect match for transitions between states. ---------- #Some background *Skip this if you aren't interested in the musical theory part or if you already have a background in music theory!* ##What is a chord? A chord is basically a group of notes played together (contemporarily). Chords are the quanta of musical "feeling"; the typical—but somewhat naïve—example is the sensation of major chords sounding "happy" and minor chords sounding "sad" or melancholic (more on types of chords later). Types of chords are defined by the [intervals][3] (distance in pitch) between the notes. The *root* of a chord is the "most important" or fundamental note of the cord, in the sense that it is the "base" from which the aforementioned intervals are measured. In other words, the archetype of chord defines the "feel" and the general harmonic properties of the chord, while the root defines the pitch of the chord. So a "C Major" chord is a chord with archetype "major triad" (more on that later) built on the note C; i.e., its root is C. The *sequence* of chords in a piece constitutes its **harmony**, and it can convey much more complex musical messages or feelings than a single chord, just as in language: a single word does have meaning, but a sentence can have a much more complex meaning than any single word. ##Patterns in chord sequences The main difference that between language and music is that language, in general, has a much stricter structure (i.e. the order of words, a.k.a. syntax) than music: the latter is an art, and there are no predetermined rules to follow. But humans \[have a tendency to\] like patterns, and music wouldn't be so universally beloved if it didn't contain any patterns. This also explains the unpopularity of [atonal music][4] (example [here][5]). But even atonal music has patterns: it may do its best to avoid harmonic patterns, but it still contains some level of rythmic, textural or other kinds of patterns. This is why using graphs to visualize chord sequences is interesting: it is a semidirect way of identifying the harmonic patterns that distinguish different genres, styles, forms, pieces or even fragments of music. In my project, I have mainly focused on the "western" conception of tonal music, an particularly in its "classical" version (what I mean by "classical" is, in lack of a better definition, a classification that encompasses all music where the composer is, culturally, the most important artist). That doesn't mean this tool isn't apt for other types of music; it just means it will analyze it from this specific standpoint. In tonal music, the harmonic patterns are all related to a certain notion of "center of gravity": the [*tonic*][6], which is, in some way the music's harmonic "home". Classical (as in pre-XX-century) tonal music usually ends (and often starts) with the tonic chord. In fact, we can further extend the analogy with gravity by saying that music consists in a game of tension, in which the closer you are to the center of gravity (the tonic), the greater the "pull". In an oversimplified manner, the musical equivalent of the [Schwarzschild radius][7] is the [dominant chord][8]: it tends towards the tonic. Well, not really, because you *can* turn back from it—and in fact a lot of interesting harmonical sequences consist in doing just that. ##Some types of chords In "classical" music (see definition above), there are mainly these kinds of chords (based on the amount of unique notes they contain): triad chords (i.e. three-note chords), seventh chords (i.e. four-note chords; we'll see why they're called *seventh* in a bit), and ninth chords (five-note chords). There is another main distinction: major and minor chords (i.e. the cliché "happy" vs "sad" distinction). ###Triad chords Probably the most simple and frequent chord is the triad chord (either major or minor). Here is a picture of a major and a minor triad C chord (left to right): ![Major and minor triad C chords (ltr)][9] ###Seventh chords [Seventh chords][10] are called so because they contain a seventh [interval][11]. Their main significance is in dominant chords, where they usually appear in the major-triad-minor-seventh (a.k.a ["dominant"][12]) form. Another important seventh chord form is the fully diminished seventh chord (these will be relevant for the code later), which also tends to resolve ("resolve" is music jargon for "transition to a chord with less tension") to tonic. ![Seventh chords][13] ###Ninth chords Although not extremely frequent, they do appear in classical music. The most "popular" is the dominant ninth chord (an extension of the dominant 7th). An alternative for this chord is the minor ninth dominant chord (built from the same dominant 7th chord, but with a minor ninth instead). <br> ---------- #Algorithms and Code In this section I'm going to walk through my code in order of execution. Four main parts can be distinguished in my project: importing and preprocessing, splitting the note sequence into "chunks" to be analyzed as chords, identifying the chord in each of those chunks, and visualizing the whole sequence as a graph. ##First phase: importing and preprocessing the MIDI file The first operation that needs to be done is importing the MIDI file and preprocessing it. This includes selecting which elements to import from the file, converting them to a given simplified form, and performing any sorting, deletion of superfluous elements, or other modification that needs to be done. For this purpose I defined the function `importMIDI`: importMIDI[filename_String] := MapAt[Flatten[#, 1] &, MapAt[flattenAndSortSoundNotes, Import[(dir <> filename <> ".mid"), {{"SoundNotes", "Metadata"}}], 1], 2] Here `dir` stands for the directory where I saved all my MIDIs (to avoid having to type in the whole directory every time). Notice that we're importing the music as SoundNotes *and* the file's metadata—we will need it for determining the boundaries of measures (see below). The function `flattenAndSortNotes` does what it sound like: it converts the list of `SoundNote`s that `Import` returned into a flattened list of notes (i.e. a single track), sorted by their starting time. It also gets rid of anything that isn't necessary for chord identification (i.e. rhythmic sounds or effects). Consult the attached notebook for the explicit definition. Here is the format the sequence of notes is returned in (i.e. `importMIDI[...][[1]]`): {{"C4", {0., 1.4625}}, {"E4", {0.18125, 1.4625}}, {"G4", {0.36875, 0.525}}, <<562>>, {"G2", {105., 107.963}}, {"G4", {105., 107.963}}} Each sub-list represents a note. Its first element is the actual pitch; the second is a list that represents the timespan (i.e. start and end time in seconds). <br> ##Second phase: splitting the note sequence into chunks The challenge in this part of the project is knowing how to determine which notes form a single chord; i.e., where to put the boundary between one chord and the next. The solution I came up with is not optimal, but, until now, nothing better has occurred to me (suggestions are welcome!). It involves determining where each measure start/end lies in time from the metadata and splitting each of those into a certain amount of sub-parts; then the notes are grouped by the specific sub-part of the specific measure they pertain to. The rationale behind this is that chords in classical music tend to be well-contained within measures or rational fractions of these. This procedure is contained in the function `chordSequenceAnalyzeUsingMeasures`. I'm going to go over it quickly: chordSequenceUsingMeasures[midiData_List /; Length@midiData == 2, measureSplit_: 2, analyzer_String: "Heuristic"] := Block[{noteSequence, metadata, chunkKeyframes, chunkedSequence, result}, (*Separate notes from metadata*) noteSequence = midiData[[1]]; metadata = midiData[[2]]; Until here it's pretty self evident. (*Get measure keyframes*) chunkKeyframes = divideByN[ measureKeyframesFromMetadata[ metadata, (Last@noteSequence)[[2, 2]]], measureSplit]; Here the function `measureKeyframesFromMetadata` is called. It fetches all of the `TimeSignature` and `SetTempo` tags in the metadata and identifies the position of each measure from them. `divideByN` subdivides each measure by `measureSplit` (an optional argument with default value `2`). (*Chunk sequence*) chunkedSequence = {}; Module[{i = 1}, Do[ With[{k0 = chunkKeyframes[[j]], k1 = chunkKeyframes[[j + 1]]}, Module[{chunk = {}}, While[ i <= Length@noteSequence && ( k0 <= noteSequence[[i, 2, 1]] < k1 || k0 < noteSequence[[i, 2, 2]] <= k1 ), AppendTo[chunk, noteSequence[[i]]] i++;]; AppendTo[chunkedSequence, chunk] ] ], {j, Length@chunkKeyframes - 1}]]; chunkedSequence = DeleteCases[chunkedSequence, l_List /; Length@l == 0]; Once the measures' timespan has been determined, a list of "chunks" (lists of notes grouped by measure part) is generated. (*Call analyzer*) Switch[analyzer, "Deterministic", result = chordChunkAnalyze /@ chunkedSequence, "Heuristic", result = heuristicChordAnalyze /@ justPitch /@ chunkedSequence ]; result = resolveDiminished7th[Split[result][[All, 1]]] ] Finally, each chunk is sent to the chord analyzer function `heuristicChordAnalyze`, which I'll talk about in the next section, along with the currently mysterious `resolveDiminished7th`. Since this algorithm for "chunking" a note sequence doesn't work for everything, I also developed an alternative, more naïve approach: chordSequenceNaïve[midiData_List /; Length@midiData == 2, analyzer_String: "Heuristic", n1_Integer: 6, n2_Integer: 1] := Module[{noteSequence, chunkedSequence, result}, (*Separate notes from metadata*) noteSequence = midiData[[1]]; (*Chunk sequence*) chunkedSequence = Partition[noteSequence, n1, n2]; (*Call analyzer*) result = heuristicChordAnalyze /@ justPitch@chunkedSequence; result = resolveDiminished7th[Split[result][[All, 1]]] ] <br> ##Phase 3: identifying the chord from a group of notes This has been the main conceptual challenge in the whole project. After some unsucsessful ideas, with some suggestions from Rob Morris (one of the mentors), whom I thank, I ended up developing the following algorithm. It iterates through each note and assigns it a score that represents the likeliness of that note being the root of the chord based on the presence of certain indicators (i.e. notes the presence of which define a chord, to some degree), each of which with a different weight: having a fifth, having a third, a minor seventh... Then the note with the highest chord is assumed to be the root of the chord. In code: heuristicChordAnalyze[notes_List] := Block[{chordNotes, scores, root}, (*Calls to helper functions*) chordNotes = octaveReduce /@ convertToSemitones /@ notes // DeleteDuplicates; (*Scoring*) scores = Table[Total@ Pick[ (*Score points*) {24, 16, 16, 8, 2, 3, 1, 1, 10, 15, 15, 18}, (*Conditions*) SubsetQ[chordNotes, #] & /@octaveReduce /@ {{nt + 7}, {nt + 4}, {nt + 3}, {nt + 10}, {nt + 11}, {nt + 2}, {nt + 5}, {nt + 9}, {nt + 4, nt + 10}, {nt + 3, nt + 6, nt + 10}, {nt + 3, nt + 6, nt + 9}, {nt + 1, nt + 4, nt + 10}} ] (*Substract outliers*) - 18*Length@Complement[chordNotes, octaveReduce /@ {nt, 7 + nt, 4 + nt, 3 + nt, 10 + nt, 11 + nt, 2 + nt, 5 + nt, 9 + nt, 6 + nt}], {nt, chordNotes}]; (*Return*) root = Part[chordNotes, Position[scores, Max @@ scores][[1, 1]]]; {root, Which[ SubsetQ[chordNotes, octaveReduce /@ {root + 10 , root + 2, root + 5, root + 9}], "13", SubsetQ[chordNotes, octaveReduce /@ {root + 10, root + 2, root + 5}], "11", SubsetQ[chordNotes, octaveReduce /@ {root + 4, root + 10, root + 2}], "Dom9", SubsetQ[chordNotes, octaveReduce /@ {root + 4, root + 10, root + 1}], "Dom9m", SubsetQ[chordNotes, octaveReduce /@ {root + 11, root + 7, root + 3}], "m7M", SubsetQ[chordNotes, {octaveReduce[root + 11], octaveReduce[root + 4]}], "7M", SubsetQ[chordNotes, {octaveReduce[root + 10], octaveReduce[root + 4]}], "Dom7", SubsetQ[chordNotes, {octaveReduce[root + 10], octaveReduce[root + 7]}], "Dom7", SubsetQ[chordNotes, {octaveReduce[root + 10], octaveReduce[root + 6]}], "d7", SubsetQ[ chordNotes, {octaveReduce[root + 9], octaveReduce[root + 6]}], "d7d", SubsetQ[chordNotes, {octaveReduce[root + 10], octaveReduce[root + 3]}], "m7", MemberQ[chordNotes, octaveReduce[root + 4]], "M", MemberQ[chordNotes, octaveReduce[root + 3]], "m", MemberQ[chordNotes, octaveReduce[root + 7]], "5", True, "undef"]} ] ###A note on notation In this project I use the following abbreviations for chord notation (they're not in the standard format). "X" represents the root of the chord. - *X-**5*** = undefined triad chord (just the root and the fifth) - *X-**M*** = Major - *X-**m*** = minor - *X-**m7*** = minor triad with minor (a.k.a dominant) seventh - *X-**d7d*** = fully diminished 7thchord - *X-**d7*** = half diminished 7thchord - *X-**Dom7*** = Dominant 7th chord - *X-**7M*** = Major triad with Major 7th - *X-**m7M*** = minor triad with Major 7th - *X-**Dom9*** = Dominant 9th chord - *X-**Dom9m*** = Dominant 7th chord with a minor 9th - *X-**11*** = 11th chord - *X-**13*** = 13th chord ###Dealing with diminished 7th chords Now, on to `resolveDiminished7th`. What is this function on about? Well, recall the fully diminished seventh chords I mentioned in the Background section. Here's the problem: they're completely symmetrical! What I mean by that is that the intervals between subsequent notes are identical, even if you [invert][14] the chord. In other words, the distance in semitones between notes is constant (it's 3) and is a factor of 12 (distance of 12 semitones = octave). So, given one of these chords, there is no way to determine which note is the root just by analyzing the chord itself. In the context of our algorithm, every note would have the same score! At this point I thought: "How do humans deal with this?". And I concluded that the only way to resolve this issue is to have some contextual vision (looking at the next chord, particularly), which is how humans do it. So what `resolveDiminished7th` does is it brushes through the chord sequence stored in `result`, looking for fully diminished chords (marked with the string "d7d"), and re-assigns each of those a root by looking at the next chord: resolveDiminished7th[chordSequence_List] := Module[{result}, result = Partition[chordSequence, 2, 1] /. {{nt_, "d7d"}, c2_List} :> Which[ MemberQ[octaveReduce /@ {nt, nt + 3, nt + 6, nt + 9}, octaveReduce[c2[[1]] - 1]], {{c2[[1]] - 1, "d7d"}, c2}, MemberQ[octaveReduce /@ {nt, nt + 3, nt + 6, nt + 9}, octaveReduce[c2[[1]] + 4]], {{c2[[1]] + 4, "d7d"}, c2}, MemberQ[octaveReduce /@ {nt, nt + 3, nt + 6, nt + 9}, octaveReduce[c2[[1]] + 6]], {{c2[[1]] + 6, "d7d"}, c2}, True, {{nt, "d7d"}, c2}]; result = Append[result[[All, 1]], Last[result][[2]]] ] ##Phase 4: Visualization Basically, my visualization function (`visualizeChordSequence`) is fundamentally a highly customized call of the `Graph` function; so I'll just paste the code below and then explain what some parameters do: visualizeChords[chordSequence_List, layoutSpec_String: "Unspecified", version_String: "Full", mVSize_: "Auto", simplicitySpec_Integer: 0, normalizationSpec_String: "Softmax"] := Module[{purgedChordSequence, chordList, transitionRules, weights, graphicalWeights, nOfCases, edgeStyle, vertexLabels, vertexSize, vertexStyle, vertexShapeFunction, clip}, (*Preprocess*) Switch[version, "Full", purgedChordSequence = StringJoin[toNoteName[#1], "-", #2] & @@@ chordSequence, "Basic", purgedChordSequence = Split[toNoteName /@ chordSequence[[All, 1]]][[All, 1]]]; (*Amount of each chord*) chordList = DeleteDuplicates[purgedChordSequence]; nOfCases = Table[{c, Count[purgedChordSequence, c]}, {c, chordList}]; (*Transition rules between chords*) Switch[version, "Full", transitionRules = Gather[Rule @@@ Partition[purgedChordSequence, 2, 1]], "Basic", transitionRules =(*DeleteCases[*) Gather[Rule @@@ Partition[purgedChordSequence, 2, 1]](*, t_/; Length@t\[LessEqual]2]*) ]; (*Get processed weight for each transition*) weights = Length /@ transitionRules; If[normalizationSpec == "Softmax", graphicalWeights = SoftmaxLayer[][weights]];; graphicalWeights = If[Min@graphicalWeights != Max@graphicalWeights, Rescale[graphicalWeights, MinMax@graphicalWeights, {0.003, 0.04}], graphicalWeights /. _?NumericQ :> 0.03 ]; (*Final transition list*) transitionRules = transitionRules[[All, 1]]; (*Graph display specs*) clip = RankedMax[weights, 4]; edgeStyle = Table[(transitionRules[[i]]) -> Directive[Thickness[graphicalWeights[[i]]], Arrowheads[2.5 graphicalWeights[[i]] + 0.015], Opacity[Which[ weights[[i]] <= Clip[simplicitySpec - 2, {0, clip - 2}], 0, weights[[i]] <= Clip[simplicitySpec, {0, clip}], 0.2, True, 0.6]], RandomColor[Hue[_, 0.75, 0.7]], Sequence @@ If[weights[[i]] <= Clip[simplicitySpec - 1, {0, clip - 1}], { Dotted}, {}] ], {i, Length@transitionRules}]; vertexLabels = Thread[nOfCases[[All, 1]] -> (Placed[#, Center] & /@ (Style[#[[1]], Bold, Rescale[#[[2]], MinMax[nOfCases[[All, 2]]], Switch[mVSize, "Auto", {6, 20}, _List, 10*mVSize[[1]]/0.3*{1, mVSize[[2]]/mVSize[[1]]}]]] & /@ nOfCases))]; vertexSize = Thread[nOfCases[[All, 1]] -> Rescale[nOfCases[[All, 2]], MinMax[nOfCases[[All, 2]]], Switch[mVSize, "Auto", (Floor[Length@chordList/10] + 1)*{0.1, 0.3}, _List, mVSize]]]; vertexStyle = Thread[nOfCases[[All, 1]] -> Directive[Hue[0.53, 0.27, 1, 0.6], EdgeForm[Blue]]]; vertexShapeFunction = Switch[version, "Full", Ellipsoid[#1, {3.5, 1} #3] &, "Basic", Ellipsoid[#1, {2, 1} #3] &]; Graph[transitionRules, GraphLayout -> Switch[layoutSpec, "Unspecified", Automatic, _, layoutSpec], EdgeStyle -> edgeStyle, EdgeWeight -> weights, VertexLabels -> vertexLabels, VertexSize -> vertexSize, VertexStyle -> vertexStyle, VertexShapeFunction -> vertexShapeFunction, PerformanceGoal -> "Quality"] ] There are five main things to focus on in the above definition: the graph layout (passed as the argument `layoutSpec`), the edge thickness (defined in `edgeStyle`), the vertex size (defined in `vertexSize`), the version (passed as argument `version`) and the simplicity specification (`simplicitySpec`). The graph layout is a `Graph` option that can be specified in the argument `layoutSpec`. If `"Unspecified"` is passed, an automatic layout will be used. I find that the best layouts tend to be, in order of preference, "BalloonEmbedding" and "RadialEmbedding"; nevertheless, neither are a perfect fit for every piece. In the future I would like to to implement custom (i.e. pre-defined) positioning, so that I can design it in a way that best fits this project. The edge thickness is a function of the amount of times a certain transition between two chords has occurred in the chord sequence. There is an option (namely the `normalizationSpec` argument) to enable or disable using a Softmax function for assigning thicknesses to edges. This is due to the fact that for simple/short chord sequences, Softmax is actually counterproductive because it suppresses secondary but still top-ranked transitions; i.e., it assigns a very high thickness to the most frequent transition and a low thickness to all other transitions (even those that come in second or third in frequency ranking). But for large or complex sequences it is actually useful, because it "gets rid of" a lot of the \[relatively\] insignificant instances, thus making the output actually understandable (and not just a [jumbled mess of thick lines][15]). The vertex size is proportional to the number of occurrences of each particular chord (that is, without taking into account the transitions). It can also be specified manually by passing `vSize` as a list `{a,b}` such that `a` is the minimum size an `b` is the maximum. The `version` can be either `"Full"` or `"Basic"`; the default is `"Full"`. The `"Basic"` version consists of a simplified chord set in which only the root note of the chord is taken into account, and not the archetype. For example, all C chords (M, Dom7, m...) would be represented by a single `"C"` vertex. Finally, the simplicity specification (`simplicitySpec`) is a number that can be thought of, in some way, as a "noise" threshold: as it gets larger, fewer edges "stand out"—that is, more of the lower-significance ones are rendered with reduced opacity or are shown as dotted lines. This is useful for large or complex sequences. <br> ---------- #Some examples Here I will show some specific examples generated with this tool. I tried to use different styles of music for comparison. - **Bach**'s [prelude no.1][16] from the Well Tempered Clavier: ![Visualization of Bach's prelude no.1 ][17] - **Debussy**'s [*Passepied*][18] from the *Suite Bergamasque*: ![Visualization of Debussy's *Passepied*][19] - A "template" blues progression: ![Blues template][20] - **Beethoven**'s second movement from the *Pathétique* sonata (no.8): ![Beethoven][21] - Any "reggaeton" song (e.g. Despacito): ![Reggaeton][22] #Microsite Check out the form page (a.k.a. microsite) of this project [here][23]: https://www.wolframcloud.com/objects/lammenspaolo/Chord%20sequence%20visualization [![enter image description here][24]][23] Briefly, here is what each option does (see the section **Algorithms and code** for a more detailed explanation): - **Chunkifier funciton**: choose between splitting notes by measures or by a constant amount of notes - **Measure split factor**: choose into how many pieces you want to divide measures (each piece will be analyzed as a separate chord) - **Graph layout**: choose the layout option for the `Graph` call - **Normalization function**: choose whether to apply a Softmax function to the weights of edges (to make results clearer in case of complex sequences). - **Version**: choose "Full" for complete chord info (e.g. "C-M", "D-Dom7", "C-7M"...) or "Basic" for just the root of the chord (e.g. "C", "D"...) - **Vertex size**: specify vertex size as a list `{a,b}` where `a` is the minimum and `b` is the maximum size - **Simplicity parameter**: visual simplification of the graph (a value of 0 means no simplification is applied) <br> #Conclusions I have developed a functional tool to visualize chord sequences as graphs. It is far from perfect, though. In the future, I would like improving the positioning of vertices, being able to eliminate insignificant transitions from the graph altogether, and making other visual adjustments. Furthermore, I plan to refine and optimize the chord analyzer, as right now it is just an experimental version that isn't too accurate. A better "chunkifier" function could be developed too. Finally, I'd like to thank my mentor Christian Pasquel and all of the other WSC staff for this amazing opportunity. I'd also like to thank my music theory teacher, Raimon Romaní, for making me, over the years, sufficiently less terrible at musical analysis to be able to undertake this project. [1]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Prelude.png&userId=1372342 [2]: https://en.wikipedia.org/wiki/Markov_chain "Wikipedia: Markov chain" [3]: https://en.wikipedia.org/wiki/Interval_(music) "Wikipedia: Interval" [4]: https://en.wikipedia.org/wiki/Atonality "Wikipedia: Atonality" [5]: https://youtu.be/L85XTLr5eBE "Schönberg's 4th string quartet on YouTube" [6]: https://en.wikipedia.org/wiki/Tonic_%28music%29 "Wikipedia: Tonic" [7]: http://astronomy.swin.edu.au/cosmos/S/Schwarzschild+Radius "Basic info on Schwartzschild radius" [8]: https://en.wikipedia.org/wiki/Dominant_(music) "Dominant chord" [9]: http://community.wolfram.com//c/portal/getImageAttachment?filename=2548Macro_analysis_chords_on_C.jpg&userId=1372342 [10]: https://en.wikipedia.org/wiki/Seventh_chord "Wikipedia: Seventh chord" [11]: https://en.wikipedia.org/wiki/Interval_(music) "Wikipedia: Interval" [12]: https://en.wikipedia.org/wiki/Dominant_seventh_chord "Wikipedia: Dominant seventh" [13]: http://community.wolfram.com//c/portal/getImageAttachment?filename=images.png&userId=1372342 [14]: https://en.wikipedia.org/wiki/Inversion_(music)#Chords "Wikipedia: Inversion#Chords" [15]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Passepied.png&userId=1372342 "Jumbled mess!" [16]: https://www.youtube.com/watch?v=aengbLEFnM8 [17]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Prelude.png&userId=1372342 [18]: https://www.youtube.com/watch?v=hDWbVP-5DSA "Passepied" [19]: http://community.wolfram.com//c/portal/getImageAttachment?filename=deb_pass2.png&userId=1372342 [20]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Blues.png&userId=1372342 [21]: http://community.wolfram.com//c/portal/getImageAttachment?filename=pathetique.png&userId=1372342 [22]: http://community.wolfram.com//c/portal/getImageAttachment?filename=Reggaeton.png&userId=1372342 [23]: https://www.wolframcloud.com/objects/lammenspaolo/Chord%20sequence%20visualization "Microsite" [24]: http://community.wolfram.com//c/portal/getImageAttachment?filename=ScreenShot2018-07-19at1.53.02PM.png&userId=11733 Paolo Lammens 2018-07-14T05:10:03Z https://community.wolfram.com/groups/-/m/t/3502721 ![enter image description here][1] &[Wolfram Notebook][2] [1]: https://community.wolfram.com//c/portal/getImageAttachment?filename=chloefinalpicturecompessay.png&userId=3502268 [2]: https://www.wolframcloud.com/obj/5b67f4b8-3394-41ba-9b11-73c9d08d61b7 Chloe Kong 2025-07-10T21:30:39Z