Chapter 13 — Conclusion & Architectural Retrospective
ReasonTouch Technical Companion
Version: Draft 1.0
Chapter 13 — Conclusion & Architectural Retrospective
13.1 Purpose of this Chapter
This final chapter concludes the first edition of the ReasonTouch Technical Companion.
Rather than introducing new technical systems, it reflects upon the architectural decisions documented throughout the companion and explains why the project has been designed in the way it has.
It also establishes principles that should continue to guide future development, ensuring that ReasonTouch remains coherent as it grows.
13.2 Looking Back
ReasonTouch began as a comparatively simple idea:
A touch-screen application that helps musicians build chord progressions.
As development progressed, it became increasingly clear that the project had the potential to become something much more ambitious.
Each solved problem revealed another opportunity:
- recognising harmonic function
- understanding cadence
- analysing progression flow
- predicting continuation
- generating alternatives
- explaining musical decisions
The application gradually evolved from a chord-selection interface into a system capable of reasoning about harmony.
13.3 The Evolution of the Architecture
The architecture itself mirrors this journey.
Early versions were largely procedural:
User selects chord
↓
Chord added
↓
Display updated
Current architecture instead resembles a layered reasoning system:
User Action
↓
Theory Layer
↓
Analysis Layer
↓
Planning Layer
↓
Generation Layer
↓
Presentation Layer
Each layer has a clearly defined responsibility.
This separation is the foundation upon which future capabilities will continue to be built.
13.4 Why Layering Matters
Throughout this companion, one architectural theme has appeared repeatedly:
Each layer should know only what it needs to know.
For example:
The UI should not understand harmonic function.
The planner should not understand Android.
The generator should not know how information is displayed.
The analysis engine should not know how suggestions are rendered.
Each subsystem remains independently understandable.
This dramatically reduces long-term complexity.
13.5 The Importance of Explainability
One distinguishing characteristic of ReasonTouch is that its recommendations are intended to be explainable.
Instead of:
Suggested:
Am
the application should eventually be capable of saying:
Suggested:
Am
Reason:
Acts as vi in C major.
Provides a softer tonic substitute before
moving towards ii–V resolution.
This emphasis on explanation transforms the application from a generator into a teacher.
13.6 Software That Teaches
Many music applications perform useful tasks.
Relatively few attempt to improve the user’s understanding.
ReasonTouch aims to narrow the gap between:
- creating music
and
- understanding music.
Every generated suggestion has the potential to become an educational opportunity.
13.7 Human Creativity Remains Central
Throughout development one principle has remained unchanged:
The software should never replace the composer.
Instead it should behave more like:
- a collaborator
- a mentor
- a theory reference
- a creative partner
Suggestions are optional.
The user remains in complete control.
13.8 The Value of Musical Context
Traditional chord generators often operate locally.
Example:
Current Chord
↓
Next Chord
ReasonTouch increasingly considers broader context.
Eventually decisions will depend upon:
- phrase
- cadence
- section
- song
- style
- emotional direction
This wider perspective produces more convincing musical suggestions.
13.9 Balancing Theory and Creativity
Music theory describes common practice.
It does not dictate creativity.
ReasonTouch therefore attempts to balance:
Predictability
↓
Musical Logic
↓
Creative Surprise
Users should be able to choose whether they prefer:
- conservative harmony
- adventurous harmony
- stylistic authenticity
- experimentation
The architecture supports all of these equally well.
13.10 Building for Longevity
Many software projects become increasingly difficult to extend.
ReasonTouch has intentionally prioritised maintainability over rapid feature accumulation.
Examples include:
- immutable data models
- isolated engines
- modular planners
- reusable theory objects
- strategy-based generation
- clearly defined responsibilities
These choices may initially require more effort but significantly reduce future development costs.
13.11 Documentation as Architecture
This companion serves a purpose beyond documentation.
It captures the reasoning behind architectural decisions.
Source code explains:
how something works.
Documentation explains:
why it was designed that way.
Future contributors should be able to understand not only the implementation but also the design philosophy.
13.12 Incremental Development
One lesson repeatedly reinforced during development is the value of incremental progress.
Large architectural goals become manageable when decomposed into small, independently testable steps.
For example:
Chord Database
↓
Theory Objects
↓
Key Detection
↓
Progression Analysis
↓
Planning
↓
Generation
↓
Phrase Planning
↓
Song Planning
Each milestone provides useful functionality while preparing the next.
13.13 Respecting Existing Work
Future enhancements should extend existing systems rather than replacing them.
Whenever possible:
- improve
- refactor
- generalise
- simplify
before introducing entirely new frameworks.
Architectural continuity is one of the project’s greatest strengths.
13.14 The Role of Refactoring
Refactoring should be viewed as normal development rather than corrective work.
Signs that refactoring is appropriate include:
- duplicated logic
- unclear responsibilities
- difficult testing
- growing coupling
- expanding interfaces
Small, continuous refactoring preserves long-term stability.
13.15 Future Contributors
As ReasonTouch grows, additional contributors may eventually participate.
This companion exists partly to support that future.
A new developer should be able to understand:
- project philosophy
- architectural layers
- planning systems
- theory model
- coding conventions
- future direction
without needing to reconstruct those decisions from source code alone.
13.16 Lessons Learned
Several architectural lessons have emerged during development.
Separate Musical Theory from User Interface
Theory evolves independently of presentation.
Prefer Composition over Duplication
Reusable engines simplify future expansion.
Explain Decisions
Generated output becomes more valuable when accompanied by reasoning.
Keep Systems Small
Smaller components are easier to understand and maintain.
Build for Extension
Future ideas should require addition rather than modification.
13.17 Defining Success
ReasonTouch should not measure success solely by:
- feature count
- code size
- complexity
Instead success can be judged by questions such as:
- Does it help musicians compose?
- Does it encourage learning?
- Does it inspire experimentation?
- Does it remain understandable?
- Does it remain enjoyable?
These questions should continue to guide future decisions.
13.18 Final Vision
The long-term aspiration is not simply to build another music application.
It is to create an environment in which technology actively supports musical thought.
An environment where:
- ideas can be explored
- theory becomes approachable
- experimentation feels safe
- creativity is encouraged
- learning happens naturally
ReasonTouch therefore becomes more than software.
It becomes part of the creative process.
13.19 Closing Remarks
The first edition of this Technical Companion documents the foundations of that vision.
The systems described throughout these chapters represent only the beginning.
Future editions will undoubtedly contain:
- new planners
- richer analysis
- deeper educational capabilities
- broader stylistic understanding
- more sophisticated musical reasoning
Yet if the architectural principles established here remain intact, those additions can be made without compromising clarity.
The architecture has been designed not merely to solve today’s problems, but to accommodate tomorrow’s ideas.
Final Statement
ReasonTouch has always been envisioned as a conversation between music and technology.
Technology provides consistency, speed, and analytical power.
Music provides expression, emotion, and creativity.
The purpose of this project is to ensure that one enhances the other.
If that balance is maintained, ReasonTouch will continue to evolve not only as an application, but as a genuinely useful creative companion for musicians.
End of the ReasonTouch Technical Companion — First Edition