Part 1

A developer built a web-based tablature editor for the Guitalele, an instrument with limited resources, using AI assistance. The project evolved from a simple text parser into a full-featured editor supporting multiple scores, metadata, and a custom shorthand notation. The developer faced challenges with the notation's usability and added polyphonic lines for melody and bass.

When I started this project around 3 weeks ago, I never thought this one project would compel me to face so many challenges. It started with a simple idea. I needed something to practice the Guitalele, an instrument with a very limited fan following that never reached the heights of the Guitar or Ukulele. Because of that, resources like tabs, scores, and specialized tuners are incredibly scarce. So, I sat down to build a simple text area that would take my own musical shorthand and parse it specifically to Guitalele standards. Using AI as my primary co-pilot, we started building. And then, the engineering snowball completely took off. The first version was laughably simple — a <textarea and a Parse button. You paste some shorthand, hit the button, and hope something renders on the other side. For about an hour, that was enough. Then the cracks showed. I needed to manage multiple scores, not just one. I needed to edit old ones, not just create new ones. I needed parameters like time signature, instrument, capo position, and a description for each score. A raw textarea was not going to cut it. So the editor grew. A dropdown to switch between existing scores — all stored locally for now. Input fields for metadata — name, time signature 4/4, 3/4, 6/8, 2/4, 2/2 , instrument Guitalele for now, but the door is open , capo position 0 to 12 . A publish/draft toggle. A delete button with a confirmation dialog. Auto-resizing textarea that grows as you type. A manual modal referencing every shorthand rule I had invented so far. No cloud, no server — just React state and a dream. Once the basic editor was ready, the next itch started. There is a classic dialogue in the movie 'Yeh Jawaani Hai Deewani' - Yaadein mithai ke dibbe ki tarah hoti hain... Ek baar khula toh sirf ek tukda nahi kha paoge. English Translation: "Memories are like a box of sweets... Once it opens, you won't be able to stop at just one piece." Well, here is Baba Palashananda Version of it: Features mithai ke dibbe ki tarah hoti hain... Ek baar scope khula toh sirf ek editor pe nahi rukoge.Poora app hi banaoge... English Translation: "Features are like a box of sweets... Once the scope opens up, you won't just stop at a single code editor. You'll end up building the whole damn app..." I know Pianists use staff notations, guitarists tabs, ukulelists also use some version of tabs. All the available materials were standardized for these systems. Guitalele is orphaned in this respect. The shorthand notation was my own invention. I started with this 0:6@q . You won't believe me how easy things look on paper, until you actually implement and use it. It was very easy on paper to write : , @ etc. on paper. I wrote a parseToken function to handle individual notes, then a parseShorthandText function to handle the full score. The parser had to deal with: Measure 1 — First measure 3:1@q — fret:string@duration 3:1 | 5:2 @q — notes wrapped in brackets -@q — silence with duration t after duration — hold the note into the next beatThe first version of the parser I implemented could decode the following: Measure 1: 0:6 | 2:5 @h -@h Measure 2: 3:3@q | 3:3@q | 4:3@q | 5:3@q Excited me started typing his very first tab on a system he implemented, a 'King' feel. It was not very long, I understood, the system I implemented is utterly problematic to type and utterly confusing as well. I also missed two major features: v1 for melody, v2 for bass — independent polyphonic lines, one for chord and another for melodyAlong with those two features, I have to come up with another idea of shorthand. Already 6 hours passed by that time still I am unable to even write a single full score. Even 'Twinkle Twinkle Little Star' felt like a chore to transcribe on my system. Time for a break. I straight went to terrace and started looking at the clouds. After almost 30 minutes or so when I came back to my desk, the solution was quite clear, why not simply use fret, string notation, exactly how I show it on my channel? And thus the first appearance of: 3f1sq — fret + f + string + s + durationAlmost every parsing was taken care, just had a task of character replacement. I finally did not replace the existing : and @ parsing, rather extended it with new syntax. Along with this, also removed the mandate of Measure notation thus making writing even easier. Now with text based parsing, it also felt easier to actually introduce description. However, as the syntax is space based, I can't put space in the description yet. May be fix for some later time. d:text — notes to the reader, doesn't affect soundAfter all the features completed, within another hour few more validations entered the scene. If a measure has 3.5 beats in a 4/4 time signature, it throws an error. If a string number is out of range 1-6 for Guitalele , it throws an error. If a bracket is missing its closing pair, it throws an error. js export const parseShorthandText = shorthandText = { const lines = shorthandText.split "\n" ; const scores = ; const errors = ; let currentScore = null; for let lineIdx = 0; lineIdx < lines.length; lineIdx++ { const line = lines lineIdx .trim ; if line || line.startsWith "==" continue; if line.startsWith "Score:" { if currentScore scores.push currentScore ; currentScore = { id: "", title: "", instrument: "", timeSignature: "4/4", measures: , capo: 0 }; continue; } // Parse measures, tokens, validate durations... } return { scores, errors }; }; Compiler design was not part of my syllabus any time. It always felt magical to me how if , else , for convert into a string of 1 and 0 . But here I was — writing a lexer, a parser, a validator, and a semantic analyzer for a domain-specific language I had just invented over a weekend. The "magic" of compilers didn't feel so magical anymore. It felt like a long chain of if conditions and regex patterns. Once the parser could produce structured data, I needed to hear if the output was correct. So I built a note player, a bare-bones audio thing using the Web Audio API. At that time, it felt like a toy I got when I was 9. But I did not know at the time that this "simple toy note player" would eventually grow into a full SVG-based score viewer with tablature rendering, sheet music notation, voice polyphony, metronome, auto-scroll, and a dark-themed GUI. But that story is for the next part. At that point, I had a local tool that could parse shorthand, play notes, and display results. I showed the prototype to Gemini. Gemini suggested adding a "Create" button. A Create button won't work without knowing who created it. That needs login. Login means authentication. Auth means a backend. A backend means Firestore. And if I am going through all the trouble of setting up Firestore, why not just save my scores there? Gemini struck a string in me which resonated far longer than I expected. Trade off decision took quite longer than I expected it to be. What would I lose? A few days of effort. Maybe a week. What would I gain? Oh, and a few sleepless nights. Well, three weeks to be very precise. I made the call. The snowball won't stop rolling. I just don't know why I chose Firebase. Maybe because, I spend significant office hours working in AWS, so an alternative for home. profiles collection for user data. scores collection with a composite key: username:instrument:slugified-title . js const makeScoreDocId = uname, instr, title = { const s = slugify title ; return ${uname}:${slugify instr }:${s} ; }; The CRUD operations came next. Firestore made the experience very smooth. No backend needed at all. Simple DB calls, that too direct from client browser. I once thought about it, how nice would it be to directly call DB from UI. Well, turns out Google gave the option, which I was not aware of. After successfully launching the web app I can realistically claim, I have seen the practical limitations of a No-Backend architecture. Trust me, beyond few easy peasy work you absolutely need a strong backend layer. Here are few things that I leveraged: getDocs with a where query . setDoc . updateDoc . deleteDoc . js const loadScores = useCallback async = { if user return; const q = query scoresRef, where "userId", "==", user.uid ; const snap = await getDocs q ; // ... build list, sort by creation date }, user ; The security rules had to be right too. Readable by all published scores are public , but writable only by the owner with a verified email. No one should overwrite someone else's score. If you are not coming from GCP or Firebase background, Security Rules are simple validations which you can use to limit access to collections and actions on them. With the cloud backend in place, I used the tool myself for four days. Wrote a few scores. The first one I published was Ode to Joy — a chord melody arrangement for Guitalele. I even made a YouTube Shorts to go with it. It was working. People could see it. I could share it. But looking at the raw shorthand text in the editor started to hurt my eyes. Raw shorthand text in a plain textarea is hard to read. All those 3f1sqd:F4 Note silver white tokens blend into a grey soup. After staring at them for days, I needed color. Desperately. So I wrote a custom syntax highlighting system from scratch. No libraries. Just regex and inline styles. js const COLOR SCHEME = { separator: ' 334155', headerLabel: ' 67e8f9', headerValue: ' e2e8f0', measureLabel: ' c084fc', pipe: ' 475569', bracket: ' fbbf24', chordContent: ' fde68a', duration: ' 4ade80', voice: ' 22d3ee', tie: ' f87171', annotation: ' fb923c', }; Every token type gets its own color. Fret numbers in slate, strings in gray, durations in green, voices in cyan, annotations in orange, ties in red. The textarea sits transparent over a <pre layer that renders the highlighted version. You type in invisible text over a colorful display, a trick borrowed from code editors like VS Code. js function highlightShorthand text { const escaped = text.replace /&/g, '&amp;' .replace /</g, '&lt;' .replace / /g, '&gt;' ; const lines = escaped.split '\n' ; const coloredLines = lines.map line = { if /^={2,}|^---+/.test line return <span style="color:${COLOR SCHEME.separator}" ${line}</span ; if /^ Score|Time Signature|Instrument|Capo|Description|ID :/.test line return line.replace /^ Score|Time Signature|Instrument|Capo|Description|ID : . $/, , label, val = <span style="color:${COLOR SCHEME.headerLabel}" ${label}</span <span style="color:${COLOR SCHEME.headerValue}" :${val}</span ; // ... more token colorization } ; return coloredLines.join '\n' ; } Two functions and about 80 lines of regex. But those 80 lines make the difference between "what did I just type?" and "oh, I see, the quarter note is missing on beat 3." Although I am the only one using it and may be, I would always be the only one using it. Still it feels to put a logical end to anything I start. A week in, here's what I had built: And none of this was planned. The editor was supposed to be a debugger. The parser was born from boredom. The note player was a validation tool. The cloud backend was an AI's suggestion I took as a dare. The highlighter came from eye strain after publishing my first real score. All because I wanted to practice a niche instrument that nobody writes tabs for. The snowball hasn't stopped rolling. But that's a story for another day.