Cross-Domain Hexadecimal Encoding & Color Barcode System

Website Portfolio Copy — Symbolic Encoding, Music/Color Mapping & Visual Data Representation

Project positioning

This is a long-running personal research and software project for translating heterogeneous symbolic domains into a shared hexadecimal representation.

The system began more than a decade ago after I encountered Christian Faur’s Color Alphabet, a visual-language project that maps letters to standardized colors. That work provided the initial conceptual trigger: if one symbolic system can be deterministically represented by another, a shared numerical layer can make broader transformations possible.

My project developed in a different direction. Instead of limiting the model to direct letter-to-color substitution, I introduced a numerical / hexadecimal interchange layer and built mapping tables across multiple domains:

Letters, Abjad and Jafr-oriented numerical mappings

Sound, musical notes, MIDI and frequency

Color, wavelength, RGB and hexadecimal color

A fourth astronomical domain developed and documented separately

One practical output of the system is the generation of color-based visual codes / color barcodes derived from encoded data.

The project should be described publicly as an encoding and transformation system, not as a proven cryptographic algorithm. Hexadecimal representation itself is not encryption. Private cipher-like transformations may be layered on top of the canonical representation, but no claim of modern cryptographic security is made without a formal security model and independent analysis.

Classification

Project Type: Personal Research Software / Encoding System / Data Representation
Origin: More than a decade of personal experimentation
Primary Concept: Cross-domain deterministic transformation through a shared hexadecimal representation
Domains in this project: Letters / Abjad, Music / Sound, Color
Separate Domain: Astronomy / Universal Parallelism — maintained as an independent project
Practical Output: Color barcode / chromatic data representation
Research Artifacts: Mapping tables, spreadsheets, long-form technical notes, musical tables, color-system notes
Portfolio Relevance: High — original research / computational representation / data modeling
Suggested CV Relevance: Tier B research evidence; potentially Tier A discussion material when presented as representation-system design rather than cryptography

Website Card

Title:
Cross-Domain Hexadecimal Encoding & Color Barcode System

One-line Description:
A personal encoding and transformation system that normalizes letters, musical data, and color into a shared hexadecimal representation and uses the resulting mappings for cross-domain conversion and chromatic barcode generation.

Categories:

Research Software
Data Encoding
Symbolic Systems
Information Representation
Music Computing
Color Computing
Experimental Software
Visualization
Personal Research

Technology / Concept Tags:
Hexadecimal · Encoding · Abjad · MIDI · Frequency · RGB · Color Spectrum · Color Barcode · Data Mapping · Symbolic Transformation

Hero Introduction

Most data systems transform values inside one domain.

Text remains text.
MIDI remains music data.
RGB remains color.

This project explores a different question:

Can multiple symbolic systems be normalized into one numerical representation and then translated through that common layer?

The system uses hexadecimal representation as a canonical interchange format.

Conceptually:

Letters / Numbers
        ↓
  Normalization
        ↓
Canonical Numeric Layer
        ↓
      HEX
   ↙   ↓   ↘
Music Color Visual Code

Rather than building isolated converters, the goal is to create a common representation through which several independently defined symbolic systems can interact.

Origin of the Idea

The earliest conceptual inspiration came from the work of artist Christian Faur and his Color Alphabet.

Faur developed a deterministic mapping between the English alphabet and a set of distinct colors, allowing textual information to be represented visually as color. His published explanation describes assigning standardized colors to alphabetic signs and developing encoding tools that translate textual data into color-oriented representations.

That idea was the starting point, not the final architecture.

My project moved beyond a direct relationship such as:

Letter → Color

and evolved toward:

Domain Value
      ↓
Numeric Normalization
      ↓
Hexadecimal Representation
      ↓
Target-Domain Mapping

The purpose was to make the intermediate representation reusable across multiple domains.

Attribution

The portfolio should preserve the project provenance clearly.

Recommended wording:

The initial idea was inspired by Christian Faur’s Color Alphabet, which demonstrates deterministic letter-to-color mapping as a visual language. I used that concept as a starting point and developed a broader hexadecimal interchange model spanning letter-based numerical systems, music/MIDI data, color-space mappings, and visual barcode generation.

This distinction is important:

Faur: color alphabet / visual encoding of language
This project: shared hexadecimal representation and cross-domain transformation architecture

Source Research Structure

The surviving research material is organized into major conceptual sections.

The long-form notes explicitly include:

Section I: Letters
Section II: Sound
Section III: Color

The sound section develops a substantial body of music-theory material, including frequency, pitch, duration, intensity, timbre, notation, scales, intervals, chords, transposition, and broader musical terminology.

The color section develops color terminology and models including:

Hue
Value / Lightness
Chroma / Saturation
Tint
Shade
Tone
additive color
subtractive color
color systems
warm and cool colors

The software/mapping layer does not need every theoretical note to perform a conversion, but this research formed the semantic background used while defining the transformation tables.

System Model

At the architectural level, the project can be described as four layers.

┌──────────────────────────────────────────┐
│          Domain Representation           │
│ Letters | Music | Color | Visual Output  │
└───────────────────┬──────────────────────┘
                    │
┌───────────────────▼──────────────────────┐
│          Domain Normalization            │
│ Character IDs | MIDI | RGB | Wavelength  │
└───────────────────┬──────────────────────┘
                    │
┌───────────────────▼──────────────────────┐
│       Canonical Numerical / HEX Layer    │
└───────────────────┬──────────────────────┘
                    │
┌───────────────────▼──────────────────────┐
│       Transform / Render / Decode        │
│ Color Code | Music Mapping | Symbols     │
└──────────────────────────────────────────┘

The central idea is that source and destination domains do not need to understand one another directly.

Each domain only needs:

a deterministic mapping into the common representation, and
a deterministic mapping out of it.

Why Hexadecimal?

Hexadecimal is useful here as a compact machine-friendly representation of numerical values.

It provides:

deterministic numerical representation,
easy conversion to/from integers,
natural compatibility with RGB color notation,
compact display,
straightforward storage and comparison,
a neutral intermediate form between unrelated symbolic systems.

For color, hexadecimal notation is already familiar:

#RRGGBB

For other domains, numerical values can also be converted into hex strings.

This creates a practical technical bridge even when the original meanings of the domains are unrelated.

Important Security Boundary

This project has historically been used in private cipher/encoding experiments, but the public technical description must distinguish encoding from cryptography.

Encoding

A reversible deterministic representation such as:

Decimal 255 → Hex FF

does not provide confidentiality.

Anyone who knows the representation can reverse it.

Cipher Layer

If a private transformation introduces:

a secret key,
secret permutation,
private lookup table,
keyed substitution,
keyed sequence transformation,
or another secret-dependent process,

that layer can reasonably be called a custom cipher layer.

However:

No claim is made that such a custom cipher is secure against modern cryptanalysis unless it has a defined threat model, formal design, and independent security review.

For the public portfolio, the strongest accurate positioning is therefore:

Cross-Domain Encoding & Transformation System

rather than:

New Cryptographic Standard.

Chapter I — Letters, Abjad & Numerical Symbol Systems

The first domain deals with characters and traditional numerical mappings associated with letters.

The research notes begin with Arabic-script letters and their traditional Abjad values.

The core computational concept is not dependent on whether a user accepts any historical or esoteric interpretation of those systems.

From a software perspective, they are deterministic mapping tables:

Character
   ↓
Assigned Numeric Value
   ↓
Normalized Integer
   ↓
Hex Representation

Abjad as a Data Mapping

Traditional Abjad assignments provide a predefined mapping between letters and numbers.

For computational use, such a table can be represented as:

Letter → Numeric ID

The application can then:

look up the value,
serialize it,
transform it,
convert it into hexadecimal,
or route it to another output domain.

The system therefore treats Abjad primarily as a historical symbolic-number mapping.

Jafr-Oriented Material

The project also contains research associated with Jafr-oriented symbolic traditions.

For public technical documentation, this should be framed carefully:

Historical or symbolic mapping material is treated as a source of deterministic tables and transformation rules, not as validated scientific evidence for supernatural or predictive claims.

This keeps the software engineering discussion separate from cultural or metaphysical interpretation.

Character Normalization

A modern V2 should explicitly normalize text before conversion.

Possible normalization stages:

Input Character
      ↓
Unicode Normalization
      ↓
Arabic/Persian Variant Handling
      ↓
Canonical Character
      ↓
Mapping Table
      ↓
Numeric / Hex Value

Examples of issues that must be handled:

Arabic ي vs Persian ی
Arabic ك vs Persian ک
presentation forms
diacritics
whitespace
punctuation
unsupported characters

Chapter II — Sound & Music

The second major domain is music.

The underlying research material is extensive and includes:

musical sound,
frequency,
pitch,
duration,
amplitude/intensity,
timbre,
octaves,
notes,
staff notation,
clefs,
transposition,
chords,
harmony,
and musical terminology.

The computational mapping is narrower and more structured.

MIDI Mapping Table

The surviving midi.xlsx file contains a structured mapping table with columns for:

Octave Name
MIDI Octave
MIDI Note Number
Note Name
Frequency Hz
Absolute Cents
Custom conversion key
Converted decimal value
Converted hexadecimal value

This is strong technical evidence that the music section is not merely theoretical notes.

It contains an actual numeric conversion model.

Music Conversion Model

Conceptually:

Musical Note
     ↓
MIDI Note Number
     ↓
Custom Numeric Key
     ↓
Decimal Representation
     ↓
Hexadecimal Representation

A target implementation can then use the normalized value to retrieve:

note name,
MIDI index,
octave,
frequency,
or other associated metadata.

Frequency as Physical Data

Musical pitch has a measurable physical representation through frequency.

The research notes explicitly describe pitch in terms of oscillations per second and Hz.

This provides a useful contrast with purely symbolic domains:

letters are primarily symbolic,
note names are symbolic,
MIDI note numbers are digital identifiers,
frequency is a physical measurement.

The system can connect these representations through explicit lookup and conversion tables.

MIDI as a Bridge

MIDI is particularly useful because it already assigns stable numeric identifiers to notes.

A simplified pipeline can therefore be:

Note Name
   ↓
MIDI Number
   ↓
Integer
   ↓
HEX

And, where defined:

HEX
 ↓
Integer
 ↓
MIDI Number
 ↓
Note / Frequency

This makes the music domain a natural participant in the common numeric layer.

Cross-Domain Possibility: Text to Music

Once both character mappings and musical mappings share a normalized representation, transformations can be defined between them.

For example:

Text
 ↓
Character Values
 ↓
Canonical Numeric / HEX Stream
 ↓
Music Mapping
 ↓
MIDI Notes

This should be described as an algorithmic mapping, not as evidence that a linguistic symbol has an inherent physical musical meaning.

The meaning comes from the defined mapping system.

Chapter III — Color

The third major domain is color.

The surviving color research covers formal color vocabulary and several color-model concepts.

The project’s computational artifacts include a spreadsheet that maps Persian letters to:

wavelength-like numerical values in nanometers,
RGB values,
hexadecimal color values.

Color Mapping Table

The Book1 (2).xlsx research table contains columns labeled approximately as:

nanometer
letters
color code in hexadecimal
color code in three-color / RGB system

Example structure:

Wavelength
   ↓
Letter
   ↓
RGB
   ↓
HEX Color

This provides a direct connection between alphabetic symbols and machine-renderable colors.

Example Mapping Structure

The table begins with values in the red end of the mapped range and progresses through letters and color codes.

Conceptually:

Persian Letter
      ↓
Assigned Wavelength Position
      ↓
RGB Triplet
      ↓
#RRGGBB

The project can then use the resulting hexadecimal color directly in:

web rendering,
image generation,
barcode cells,
visual data blocks.

Color Theory Research

The written research section distinguishes concepts such as:

Hue

The basic color family.

Value / Lightness

Relative lightness or darkness.

Chroma / Saturation

Relative color purity/intensity.

It also documents:

Tint
Shade
Tone
additive mixing
subtractive mixing
historical color systems
warm/cool classification

This broader research helps contextualize why a color mapping should be treated as a defined model rather than assuming color has one universal semantic meaning.

RGB and Hexadecimal

Color is the domain in which hexadecimal representation becomes immediately visible.

For example:

RGB(255, 0, 0)
        ↓
     #FF0000

This makes color a natural rendering layer for a canonical hex stream.

The internal representation can therefore be converted into actual visual output without requiring another textual encoding.

Chromatic Data Encoding

One of the practical outputs of the project is color-based data representation.

A generic encoding flow is:

Input
  ↓
Normalized Data
  ↓
HEX Stream
  ↓
Color Mapping
  ↓
Color Cells / Blocks
  ↓
Visual Code

The resulting output can function as a color barcode when the layout, symbol boundaries, ordering rules, and decoding process are defined deterministically.

Color Barcode Concept

Unlike a conventional black/white barcode, a chromatic code can use multiple color states per cell.

Conceptually:

00 → Color A
01 → Color B
02 → Color C
...

or, depending on the mapping:

HEX Symbol → Color

A sequence such as:

A4 7C 20 FF

can therefore become a sequence or matrix of defined colors.

Visual Barcode Architecture

A robust V2 should separate payload encoding from rendering.

Payload
  ↓
Serializer
  ↓
Canonical Byte / Hex Stream
  ↓
Optional Cipher Layer
  ↓
Error-Detection / Framing
  ↓
Color Symbol Mapping
  ↓
2D Renderer
  ↓
PNG / SVG / Print

A decoder should reverse the pipeline:

Image / Scan
  ↓
Cell Detection
  ↓
Color Classification
  ↓
Symbol Recovery
  ↓
Frame Validation
  ↓
Optional Decipher
  ↓
Payload

Why the Barcode Layer Should Be Separate

The barcode renderer should not know whether the original payload was:

text,
music,
a number,
a file identifier,
or another supported domain.

That is an important architectural separation.

The renderer should receive normalized data.

This makes the system extensible.

Reliability Challenges of Color Barcodes

Color-based machine-readable codes introduce practical issues that ordinary hexadecimal strings do not.

Examples:

display calibration,
printer variation,
camera white balance,
illumination,
compression,
color-space conversion,
fading,
adjacent-color confusion,
color vision accessibility.

A production-quality V2 should therefore avoid relying on visually similar colors as independent symbols.

Error Detection

A serious visual encoding format should include at minimum:

version identifier,
payload length,
checksum,
orientation markers,
framing,
invalid-symbol detection.

Possible structure:

Header
+
Version
+
Length
+
Payload
+
Checksum

If the system is intended for noisy scanning environments, forward error correction can be added later.

Fourth Domain — Intentionally Separated

The original broader research includes a fourth domain related to astronomy.

That material is not included in this project page.

It was developed into an independent project and should remain documented separately.

Recommended wording:

A fourth astronomical transformation domain was developed separately and is documented under the independent Universal Parallelism project.

This keeps the scope of the current project clear and avoids duplicating another research project.

Transformation Matrix

A useful way to present the platform is as a transformation matrix.

Source	Letter Domain	Music Domain	Color Domain	Visual Code
Letter	normalize	map to musical value	map to color	render
Music	map to symbol	normalize	map to color	render
Color	map to symbol/value	map to musical value	normalize	render
Raw Data	decode to domain	decode to domain	render as color	render

Not every transformation needs to be semantically meaningful.

The system guarantees only the mapping rules that are explicitly defined.

Canonical Interchange Layer

The cleanest modern architecture is to avoid direct converters such as:

LetterToColor()
LetterToMusic()
MusicToColor()
ColorToMusic()

That approach grows combinatorially as domains increase.

Instead:

Domain A
   ↕
Canonical Representation
   ↕
Domain B

With three domains, this already reduces duplicated transformation logic.

With additional domains, the benefit becomes larger.

Suggested V2 Domain Interface

Conceptually:

Encoder<TDomain>
    encode(value) -> CanonicalValue

Decoder<TDomain>
    decode(CanonicalValue) -> value

Each domain adapter owns its own rules.

Examples:

LetterEncoder
MidiEncoder
ColorEncoder

This prevents one domain from being tightly coupled to another.

Canonical Value Model

A future canonical representation could include more than a plain string.

Example:

{
  "version": 2,
  "domain": "music.midi",
  "value": "003C0000",
  "metadata": {
    "note": "C4",
    "midi": 60
  }
}

For compact barcode output, this structured representation can later be serialized into bytes.

Versioning

Versioning is essential.

If a mapping table changes, an old barcode must remain decodable.

Therefore mappings should never silently change in place.

Recommended model:

Alphabet Mapping v1
Music Mapping v1
Color Mapping v1
Barcode Format v1

Future changes create new versions rather than mutating historical definitions.

Registry Architecture

A V2 system can maintain a registry of conversion domains.

Example:

Domain Registry
├── letters.abjad.v1
├── letters.persian-color.v1
├── music.midi.v1
├── color.rgb.v1
└── barcode.chromatic.v1

Each registry entry contains:

identifier,
version,
input range,
normalization rules,
mapping table,
inverse-map availability,
validation rules.

Reversibility

Each mapping should explicitly declare whether it is:

one-to-one,
one-to-many,
many-to-one,
reversible,
partially reversible,
lossy.

This is critical.

For example, if multiple letters map to the same color, color → letter conversion becomes ambiguous.

A V2 implementation should detect this formally rather than assuming reversibility.

Collision Analysis

Mapping tables should be automatically checked for collisions.

Example test:

For every encoded value:
    count(source symbols mapping to value)

If count > 1:
    mapping is not uniquely reversible

The build/test process should generate a collision report.

Security Model

If a cipher mode is retained, it should be architecturally separate from encoding.

Domain Encoding
      ↓
Canonical Payload
      ↓
Cipher Layer
      ↓
Encoded/Encrypted Payload
      ↓
Color Barcode

This allows:

encoding without secrecy,
cipher experiments without changing domain mappings,
replacement of a private cipher with standard cryptography where actual security is required.

Recommended Cryptographic Boundary

For real confidentiality, V2 should use established cryptographic primitives.

For example:

Canonical Data
      ↓
Standard Authenticated Encryption
      ↓
Ciphertext
      ↓
Chromatic Renderer

The color barcode becomes only a transport representation.

Security remains the responsibility of the cryptographic layer.

This avoids confusing visual complexity with cryptographic strength.

Research Artifacts

Current project evidence includes:

Long-Form Notes

A large Persian technical/research document containing:

letters / Abjad material,
extensive sound/music theory,
and a dedicated color section.

MIDI Spreadsheet

A structured conversion sheet containing:

MIDI note numbers,
note names,
frequencies,
cents,
custom conversion values,
decimal conversion,
hexadecimal conversion.

Letter / Color Spreadsheet

A structured table containing:

Persian letters,
wavelength-like values,
RGB values,
hexadecimal color codes.

These artifacts demonstrate that the project progressed beyond a conceptual description into explicit conversion tables.

Evidence Level

Recommended website label:

Partially Verified / Research-Artifact Verified — Surviving mapping tables and technical notes document the letter, music, and color domains. The full historical software engine and every private cipher implementation should be attached only where surviving source is available.

Historical Development Pattern

The project evolved through research rather than through a fixed product specification.

Conceptually:

Observe Existing Idea
      ↓
Experiment with Mapping
      ↓
Expand Domain
      ↓
Create Tables
      ↓
Normalize Numerically
      ↓
Introduce HEX
      ↓
Generate Visual Codes
      ↓
Refine Transformations

This is closer to exploratory computational research than client software delivery.

Why This Project Matters

The most valuable aspect is not that the project uses hexadecimal.

Hex conversion by itself is trivial.

The engineering value lies in the representation architecture:

unrelated symbolic systems are modeled as adapters around a shared canonical layer.

That is the same architectural idea used in many serious software systems:

canonical data models,
protocol gateways,
import/export layers,
serialization systems,
intermediate representations,
compiler IRs,
integration middleware.

The domains here are unconventional, but the architectural pattern is general.

V2 — Modern Research Implementation

A modern rebuild should turn the historical tables into a testable, versioned software platform.

Recommended title:

HexaBridge — Cross-Domain Encoding Laboratory

If a descriptive rather than branded title is preferred:

Cross-Domain Hexadecimal Encoding & Color Barcode System

V2 Recommended Architecture

                  Web / CLI / API
                        ↓
                Conversion Service
                        ↓
              Canonical HEX / Bytes
                        ↓
      ┌─────────────────┼─────────────────┐
      │                 │                 │
      ▼                 ▼                 ▼
 Letter Adapter      MIDI Adapter      Color Adapter
      │                 │                 │
      └─────────────────┼─────────────────┘
                        ↓
               Barcode Renderer
                        ↓
                 PNG / SVG / PDF

Optional:

Canonical Payload
      ↓
Cryptographic Adapter
      ↓
Barcode Renderer

V2 Technology Direction

A practical modern implementation could use:

Python for research calculations and table validation
Laravel or another web backend for API/UI if a hosted interface is required
PostgreSQL for versioned mappings
JSON for portable mapping definitions
SVG for deterministic vector barcode rendering
PNG for raster export
automated tests for reversibility and collisions

The implementation language matters less than preserving deterministic behavior and testable mappings.

Mapping Definitions as Data

Rules should be stored as versioned data rather than hard-coded scattered conditionals.

Example:

{
  "domain": "music.midi",
  "version": 1,
  "entries": [
    {
      "source": 60,
      "note": "C4",
      "frequency_hz": 261.6256,
      "canonical": "003C0000"
    }
  ]
}

This allows:

inspection,
testing,
migration,
reproducibility.

Automated Validation

Every mapping release should run checks such as:

duplicate source IDs,
duplicate target IDs,
invalid hex values,
invalid RGB ranges,
missing letters,
MIDI range validation,
invertibility,
round-trip conversion.

Round-Trip Tests

For reversible mappings:

source
  ↓ encode
canonical
  ↓ decode
source

must produce the original value exactly.

Example test property:

decode(encode(x)) == x

for every valid x.

Cross-Domain Tests

For a defined transformation:

Letter → Canonical → Color

the expected color should be fixed by the mapping version.

Tests should make these outputs reproducible.

Barcode Testing

A modern barcode implementation should test:

renderer determinism,
orientation,
image scaling,
RGB preservation,
compression tolerance,
scan/decoder round-trip,
corrupted-cell detection.

Accessibility & Human Factors

Color-only representation is not equally accessible to all users.

Therefore a mature V2 should support:

optional textual/hex representation,
high-separation palettes,
alternate symbols/patterns,
contrast validation,
machine-readable mode independent of human color recognition.

This is especially important because Christian Faur himself discusses accessibility limitations of color-only alphabets in relation to color vision.

Potential Applications

The architecture can support experimental applications such as:

visual representation of text,
music-to-color visualization,
text-to-music mapping,
educational demonstrations of numeric representation,
deterministic generative artwork,
compact visual IDs,
private experimental encoding workflows,
color barcode research.

These should be presented as applications of the mapping system, not as proof that the domains have intrinsic physical equivalence.

Non-Claims

The public project page should explicitly avoid claiming:

that hexadecimal itself provides encryption,
that colors possess universal semantic meaning,
that Abjad/Jafr mappings establish scientific causation,
that musical notes and letters are physically equivalent,
that a custom cipher is secure because it is complex,
that color barcodes outperform established barcode standards without benchmarking.

This strengthens the credibility of the actual engineering work.

My Role

This is an independent personal research project.

My work includes:

identifying the initial research direction,
expanding beyond direct letter-color mapping,
collecting and structuring domain knowledge,
designing conversion tables,
building custom numerical mappings,
introducing a shared hexadecimal representation,
creating MIDI conversion tables,
creating letter/color conversion tables,
experimenting with cross-domain transformation,
developing color-barcode concepts,
and separating the astronomical branch into an independent project.

Engineering Highlights

Expanded a letter-to-color inspiration into a multi-domain representation architecture.
Designed a canonical hexadecimal layer for converting between heterogeneous symbolic systems.
Created structured Persian letter-to-color/RGB/HEX mapping data.
Created MIDI/note/frequency/custom-key/HEX conversion tables.
Used explicit mapping tables instead of relying only on narrative theory.
Developed chromatic barcode / visual-code applications on top of the normalized data.
Separated representation, optional ciphering, and rendering as distinct architectural concerns.
Preserved the astronomy-related branch as a separate research project rather than conflating scopes.
Established a clear path toward versioned mappings, round-trip tests, collision analysis, and deterministic rendering.

Career Evidence

This project can demonstrate:

Data Modeling
Canonical Representation Design
Encoding / Serialization Concepts
Research Software
Algorithmic Mapping
Music Computing
Color Computing
Visualization
Experimental Systems
Domain Abstraction
Versioned Data Design
Testing of Reversible Transformations
Intellectual Provenance / Attribution Discipline

CV Relevance

Tier B — Research / Architecture Evidence

This project is distinctive and can be valuable in a portfolio because it demonstrates abstraction across unrelated domains.

For a conventional enterprise-software CV, it should not displace production systems with stronger business impact.

For interviews involving:

architecture,
data transformation,
canonical models,
research engineering,
creative computing,
visualization,

it can become a strong discussion project.

Interview Story

Situation

More than a decade ago I encountered Christian Faur’s Color Alphabet, which demonstrated that letters could be mapped deterministically to colors.

Task

I wanted to explore whether that principle could be generalized beyond a direct alphabet-to-color substitution and used as a reusable representation model across different symbolic domains.

Action

I developed mapping research around letter-based numerical systems, music/MIDI/frequency, and color/RGB/HEX. I introduced hexadecimal representation as a common numerical layer, built structured conversion tables, and used the resulting mappings in experiments including chromatic barcode generation. A later astronomy-related branch was separated into its own project.

Result

The work evolved into a personal cross-domain encoding framework rather than a single converter. The surviving research includes detailed notes and explicit music/color mapping tables, and the modern reconstruction can formalize the system through versioned adapters, collision analysis, round-trip tests, and deterministic barcode rendering.

Suggested Website Full Description

Overview

Cross-Domain Hexadecimal Encoding & Color Barcode System is a personal research project exploring how heterogeneous symbolic systems can be represented through a shared numerical layer.

The system connects three main domains:

letter-based numerical mappings,
music and MIDI,
color and RGB/HEX.

A fourth astronomy-related domain was developed separately and is documented as an independent project.

Inspiration

The earliest inspiration came from Christian Faur’s Color Alphabet.

Faur’s work showed how letters could be deterministically mapped to distinct colors and rendered as a visual language.

I used that concept as a starting point but moved the architecture toward a generalized intermediary representation rather than a fixed letter-to-color table.

Core Idea

The system normalizes each supported domain into a numerical form and then into a hexadecimal representation.

Source Domain
     ↓
Normalization
     ↓
Canonical HEX
     ↓
Target Domain

This makes cross-domain transformations possible without building every converter as a separate hard-coded relationship.

Research Domains

Letters

Character mappings, including Abjad-oriented numerical tables.

Music

MIDI note numbers, note names, octaves, frequencies, cents, custom numeric keys, decimal and hexadecimal values.

Color

Persian-letter mappings to wavelength positions, RGB triplets, and hexadecimal colors.

Visual Encoding

Generation of color-based visual representations / barcodes from normalized data.

Security Position

The system can be used as part of private cipher experiments, but hexadecimal conversion itself is encoding, not encryption.

The public project therefore makes no claim of cryptographic security.

In a modern V2, any real confidentiality requirement should use a standard cryptographic layer independently from the domain encoding and color rendering.

Version 2

The modern rebuild turns the historical mapping tables into a versioned transformation platform.

Core V2 capabilities:

domain adapters,
canonical byte/hex representation,
versioned mapping registry,
reversible-transform declarations,
collision detection,
round-trip tests,
optional cryptographic adapter,
chromatic barcode renderer,
barcode decoder,
SVG/PNG export,
machine-readable mapping definitions.

Short Website Card Copy

Cross-Domain Hexadecimal Encoding & Color Barcode System

A personal research system that normalizes letters, MIDI/music data, and color into a shared hexadecimal representation for cross-domain transformation and chromatic visual encoding.

Alternative One-Liners

Architecture-oriented

Designed a canonical hexadecimal interchange layer for deterministic transformations across letter, music/MIDI, and color domains.

Research-oriented

Expanded a color-alphabet inspiration into a multi-domain encoding system linking symbolic letters, musical data, RGB/HEX color, and visual barcodes.

Visualization-oriented

Built experimental data mappings capable of rendering normalized symbolic information as deterministic color-based visual codes.

Security-safe

Developed a custom encoding and transformation framework used in private cipher experiments, while keeping representation and cryptographic security as separate concerns.

Suggested Website Slug

/projects/cross-domain-hex-encoding

Alternative:

/research/hexadecimal-color-barcode-system

Suggested Project Naming Options

Recommended Descriptive Name

Cross-Domain Hexadecimal Encoding & Color Barcode System

Best for technical credibility and immediate recruiter comprehension.

Optional Product Name

HexaBridge

Subtitle:

Cross-Domain Encoding Laboratory

This is stronger as a product identity if the project is rebuilt as a public tool.

Cover Direction

Title

Cross-Domain Hexadecimal Encoding

Subtitle

Letters · Music · Color · Chromatic Barcodes

Visual Direction

A premium square technical-research cover showing three source domains converging into a central hexadecimal stream:

Left

Persian/Arabic letters
numerical symbols

Center

0–9 / A–F
hexadecimal data stream
transformation matrix

Right / Lower Areas

musical staff / MIDI notes / waveform
RGB spectrum / color wheel
matrix of colored barcode cells

The cover should visually communicate:

SYMBOL
  ↘
   HEX → TRANSFORM → COLOR CODE
  ↗
MUSIC

Avoid astronomical imagery on this cover because that branch belongs to the separate Universal Parallelism project.

Evidence Gallery Recommendation

Research Documents

long-form letters/music/color notes
screenshots of section headings
theoretical diagrams

Mapping Tables

MIDI spreadsheet
letter/RGB/HEX spreadsheet
sample mapping exports

Software / Algorithms

If recovered or rebuilt:

conversion engine
CLI
mapping registry
automated round-trip tests
collision report

Color Barcode

example encoded payload
rendered color barcode
decoded output
side-by-side round-trip demonstration

Provenance / Reference

Initial conceptual inspiration:

Christian Faur — Color Alphabet

Faur’s system maps alphabetic symbols to distinct colors and includes tools/processes for translating textual data into color-oriented representation.

This project acknowledges that influence while documenting a separate multi-domain hexadecimal transformation architecture.

Universal Parallelism / Astronomy Domain

The fourth domain is intentionally not described here.

It is maintained as a separate project:

Universal Parallelism

Public archive:

https://soroush.neyestani.com/portfolio-archive/universal-parallelism/

This separation keeps the current system focused on encoding architecture rather than duplicating the astronomy-related research.

Final Portfolio Statement

This project did not begin with hexadecimal.

It began with a much simpler question:

If a letter can become a color, what is the common representation that would allow different symbolic systems to become interchangeable?

The answer I explored was a canonical numerical layer represented in hexadecimal.

From there, the project expanded into:

Letters
   ↘
    Canonical HEX
   ↗      ↓
Music   Color
          ↓
    Chromatic Code

The most important outcome is not a claim that these domains are naturally equivalent.

They are not.

The engineering achievement is the definition of explicit, inspectable mapping rules that allow them to be transformed through one shared representation.

That distinction turns the project from an abstract symbolic experiment into a software-architecture problem involving:

canonical data models,
adapters,
versioning,
reversibility,
collision analysis,
serialization,
rendering,
and testing.

The modern reconstruction formalizes those ideas while preserving the exploratory origin of the project.