Tabla Focus: Reimagining the Lehra

There is an apparent simplicity to a lehra (a short melody that follows a taal and repeats). The melody returns, and returns again. Against it, the tabla player can elaborate, interrupt, multiply, and resolve. The melody gives the improvisation a reference; the player supplies its possibilities.

Even that reference contains subtleties. Sam (the first beat and the cycle’s return point) need not announce itself with the loudest sound. In Rupak taal, it belongs to the khali (empty) division. Martin Clayton’s study of Rupak describes a musical organization that a generic accented click cannot adequately explain.¹ A companion must communicate where the player is without flattening the meaning of that place.

Tabla Focus is an iPhone and iPad tabla practice app built for focused traditional practice and for simulating situations players need to rehearse in solo performance and accompaniment. Its Lehra supports layakari, landings around sam, one taal inside another, and cues that leave room for a phrase. Designing those exercises meant working on the musical rules, the visible controls, and the scheduled sound together.

The question became a product question as much as a musical one. How could these possibilities belong to a single practice surface? How could their controls remain intelligible while the player’s hands were occupied? And how could the engineering preserve the relationships the interface promised?

Designing the Lehra interface

A serious practice tool accumulates demands quickly. It needs a melody, a cycle, a tempo and a pitch. Then come the things that happen around playing: reading notation, recording an attempt, setting a timer, recalling a setup, and checking elapsed practice time. Add requests for rhythmic work and the design problem becomes crowded before a single control reaches the screen.

The feature set has to support those relationships. Taal, raag, scale and tempo establish the reference. Layakari, Graha, Cross Taal and Mukhda change the practice situation. Lay Automation plans tempo progression. Farmaish introduces constrained rhythmic requests. Lehra Composer makes the melody editable. Relative mixing adjusts the voices; presets recall the setup. The time log, notation viewer, recorder, timer and screen lock support the work around the music.

The difficulty lies in deciding which choices belong together. A comprehensive specification can become a screen full of equally urgent buttons. A player needs a clear order: establish the reference, choose an exercise, then play. The sketches below reconstruct that grouping problem. They expose the clutter so the final arrangement can be examined; they are not surviving early prototypes.

01 · Concept board

02 · Crowded wireframe

03 · Current app

1 Cycle2 Tempo3 Advanced tools

Tabla Focus’s Lehra screen gives the cycle the largest area, keeping musical position visible above the controls that change the exercise. The utility row sits below it. Tempo follows; taal, raag and scale share a selection row. Four advanced controls sit together, with presets and Lay Automation below. Their more detailed choices open on demand. This is progressive disclosure (showing detail when it is needed): the first screen establishes the task, and a second surface handles its configuration.⁷

That organization makes a product decision visible. A notation viewer does not compete with the cycle for space. A timer remains close to the time log. Screen lock protects a configuration once playing begins. The same interface supports both a quick start and a carefully prepared exercise, with a distinct place for each kind of decision.

1 Cycle2 Time log3 Notation viewer4 Record5 Farmaish6 Screen lock7 Timer8 Tempo9 Taal · raag · scale10 Advanced tools11 Presets12 Lay Automation

Layakari, Graha, Cross Taal, and Mukhda

Layakari: ratios against the reference pulse

Layakari (rhythmic variation against the underlying pulse). Tabla Focus offers fifteen rational ratios, presented through traditional names and explicit fractions. A familiar term can lead one player to the right choice; the ratio can make that choice legible to another. Visible alternatives are useful here: recognition demands less retrieval from memory than an unlabeled system whose meanings must first be learned.²

The Layakari control groups Layakari, Jati, and Chhand. They share a place in the interface while retaining their distinct musical names. Jati (a class of related rhythmic divisions) gives those relationships a family name. In North Indian usage, Tisra can include both 3:1 and 3:2. Chhand (rhythmic organization, including grouping or accent in this context) brings another way of shaping the phrase. Usage varies across traditions; the terms retain that breadth.^{13, 14}

This grouping is a product decision. It gives the player one place to look for related rhythmic work. It does not turn the terms into synonyms. Grouping and subdivision can describe different operations, a distinction also made in Smithsonian Folkways teaching material.³ In the implementation, the ratio, its stress pattern, and its permitted event density are separate concerns. Selected whole-number ratios receive shaped stress patterns. Fractional ratios do not all receive that same treatment. At denser settings, the system can retain structural events while softening intervening ones.

A matra (beat) has duration. Tigun places three equal subdivisions inside it. Aad lay, the 3:2 relationship, stretches three equal subdivisions across two matras. In the diagram, dots mark pulse onsets; the right boundary starts the next interval. Grouping can then organize the same pulses differently without changing their spacing.¹⁷ These are temporal schematics, not a claim that every pulse becomes a melody note or an audible cue. The app separately decides which events to sound and which to soften.

1 Ratio + name

Time inside two matras

Same host tempo · dots = pulse onsets

01 matra2 matras

1 : 1 · Reference

3 : 1 · Tigun

3 : 2 · Aad lay

Grouping + accent

3 + 3

2 + 2 + 2

Graha: placing the landing around sam

Graha (placement relative to sam). Graha serves as the interface group for Anagat, Ateet, and their Sukshma variants. In this app’s Hindustani stress context, Anagat targets a landing before sam; Ateet targets one after it. Tabla Nawaz Academy describes the terms through stress before or after sam.¹² The half-matra and quarter-matra offsets are Tabla Focus settings. Sukshma (finer displacement) names the quarter-matra choices. The product question is precise: how can a player distinguish the target from the current playback position?

The target has to remain visible as the cycle moves around it. Underneath that distinction, integer quarter-matra offsets provide a common lattice for the calculations. The quarter-matra options are available up to 130 BPM, a constraint on the cues this tool provides.

The interface has to make different kinds of information distinguishable. A moving position and a fixed target should not become the same mark with a different color. Apple’s accessibility guidance provides a useful standard for examining such distinctions, including information that must survive a change in visual settings.⁴

Graha offsets

Tabla Focus settings · matras from sam

1 Target2 Current position3 Pending entry

Cross Taal: two cycles sharing sam

Cross Taal (two taals sharing sam, in Tabla Focus). This product name describes the arrangement. The app fits one guest cycle into the duration of one host cycle. Twelve guest matras placed within sixteen Teentaal matras give each guest matra a duration of four-thirds of a host matra. Both cycles reach their next sam together. The label offers a direct route to the exercise without inventing a traditional tabla category.

The guest pulse changes to fit the shared span. Within that span, the guest taal retains its khali roles, giving the relationship a musical structure beyond its arithmetic. Rupak’s khali sam shows why that preservation matters.¹

Here, sound design has musical content. Apple’s Designing Sound session argues for meaning and context in auditory feedback.⁵ The domain knowledge supplies the meaning: which event establishes a reference, which carries a structural distinction, and which should remain quiet.

1 Host cycle2 Guest cycle

Twelve inside sixteen

Matches the capture · equal cycle duration

SamNext sam

Host · Teentaal 16 matras

12345678910111213141516

Guest 12 matras

123456789101112

Khali matrasGuest matra = 4/3 host matras

Mukhda: a cue followed by space

Tabla Focus’s Mukhda tool marks an entry before sam, then leaves the player room to carry the phrase into its landing.

The selected length becomes an entry cue, followed by scheduled silence and a quiet sam reference. Available lengths move in half-matra steps within a limit determined by the taal. What matters is the sequence of information: an entry, room for the player’s phrase, and a point of return. The app supplies the situation. It does not judge the resolution.

Research on Indian instrumental performance distinguishes synchronization over short timescales from coordination across larger phrases.⁶ A practice tool can take that distinction seriously. Continuous prompting is not always the most useful accompaniment. Sometimes the significant engineering decision is to schedule the silence as carefully as the sound.

1 Entry marker2 Queued handoff

Entry, Mukhda, Sam

Cue sequence · schematic

Entry

Mukhda or fixed phrase

Quiet sam

Presets: easy access to complex lehra settings

A useful practice setup can contain a familiar melody, a chosen scale and tempo, a rhythmic task, and a particular listening balance. Another may use a tempo plan. Rebuilding each setup means remembering the settings and entering them again. As the tool becomes more capable, that work grows. Presets make a practice situation repeatable without making its preparation repetitive.

A preset stores the melody and taal, scale, BPM, voice levels, drone settings, compatible rhythmic tools, and the Lay Automation plan. Compatibility matters: Cross Taal takes precedence over Layakari, Graha and Mukhda; automation takes precedence over the click layers. The saved scene follows those rules. It leaves out temporary session state, such as the timer, recording and the current Farmaish request.

The ten slots stay close to the controls they remember. Tap an empty slot to name and save the current setup; tap a saved slot to recall it. Long press an occupied slot for Edit, Rename… or Delete. Edit uses the same playing screen, where Save replaces the stored scene. The player learns one set of controls and uses it for both preparation and revision. Visible slots also reduce the need to remember where a setup was saved.²

Recall has a musical consequence. While stopped, the setup applies immediately. During playback, it queues a scene change at a suitable cycle boundary. The interface shows the arrival separately from the scene that is already playing. A preset therefore has two jobs: retain the configuration and make its return intelligible in time.

1 Preset slots

The saved scene

Configuration · schematic

Melody + taalScale + tempoCompatible toolsMix + tempo plan

↓Preset→Recall at a boundary

Lay Automation: tempo changes at cycle boundaries

Lay Automation. The player can plan editable tempo and hold steps, measured in minutes or avartans (complete taal cycles). The plan can repeat. A tabla practice session can progress through those steps while the player keeps attention on the instrument.

The translation between those measurements requires judgment. A minute is a clock interval; an avartan is a musical span. The app rounds minute-based holds to whole avartans at each step’s tempo. A transition can therefore wait for the cycle boundary, and a nominal minute setting can take a different amount of elapsed time.

Even, Settle, Sprint, and Hold distribute time among the steps differently. Each tempo remains a step, with its own hold. When automation takes over, it also disarms other lay tools, making the change in control explicit. Progressive disclosure offers a useful lens here: detailed planning can have its own surface while the playing screen retains its immediate purpose.⁷

Steps that wait for the cycle

First three planned steps from this capture

85 BPM5 min → cycles

90 BPM5 min → cycles

95 BPM5 min → cycles

1 Editable step2 Time distribution

Farmaish: the ultimate way to test your Tayyari

Tayyari is technical readiness: the fluency and command that let the hands execute a musical idea with clarity. Tabla Legacy connects it with hand dexterity in rela and precision in instrumental accompaniment.¹⁹ Here, testing that readiness means responding to a new rhythmic situation while preserving the pulse and the intended landing.

Farmaish makes the session responsive to a requested task. It presents a rhythmic form with a timing guide, gives it two passes, and introduces the next request at sam. The player encounters a new situation while the practice continues.

The starting level is Foundational. Its seven templates isolate useful timing problems. A Mukhda request gives the player a short phrase into sam, with a defined entry and landing. A bedam tihai asks for three pallas (repeated phrases) without gaps, with the last stroke on sam. A damdar tihai inserts a specified pause between the pallas while preserving that landing. Other requests change the entry matra, target khali or a specified tali, or extend the tihai across two avartans.

Advanced has fifteen templates. They extend the task through Anagat and Ateet landings, Sukshma offsets, Dugun and Chaugun density, and forms such as tukra, nauhakka, chakradar, chakradar tihai, tipalli, chaupalli and mohra. Interior entries can lead to specified later landings. The challenge can change entry, landing, density, form and span together.

These names lead to distinct tasks. A tukra request joins a body to its tihai; a mohra joins a short Mukhda to its tihai. Tipalli carries one phrase through three layas (rates); Chaupalli uses four. The app fits the complete sequence to sam. A request for a khali landing first checks that the taal has a suitable point of arrival; it is not offered as a separate challenge when sam itself is khali, as in Rupak.

Tap the Farmaish icon to turn requests on or off. Hold it for half a second to switch levels; VoiceOver also offers a “Switch level” action. The chosen level is saved for that playback context. When Farmaish takes over, the other lay tools rest. Their prior setup returns when it is disabled.

A request must fit the selected taal and tempo. Sukshma tasks are available up to 130 BPM; Chaugun tasks up to 120 BPM. The chakradar family needs more than six matras and stays within 180 BPM. These are the app’s design constraints. They filter the catalogue before the solver checks whether a request has a valid integer solution. If repeated attempts cannot produce one, a plain bedam tihai to sam provides a fallback.

For a single-level tihai (three repetitions), the solver uses (3p + 2g − 1)s = N. Here, p counts strokes per phrase; g counts stroke-length units in each gap; s is the grid step in quarter-matra units; N is the span from entry to landing. The subtraction accounts for the landing stroke’s position. The resulting marks and spans drive the guide. A shared model keeps the request, visual timing, and cue plan consistent.

The guide draws one ring per avartan, with arcs for phrases and gaps. A structure strip follows the current segment; two pips show the attempt. A pass covers the full request span. A three-avartan request therefore receives six avartans across its two passes. Then sam brings the next task. The sequence asks something of the musician while leaving the judgment of the response with them; Farmaish supplies guidance without listening to or grading the performance.

1 Phrase arcs2 Palla strip3 Attempt indicators4 Queued scene5 Farmaish on

Lehra Composer: practice with your favourite lehra melody

For a tabla player, the choice of lehra can be personal. Perhaps two or three familiar melodies become regular companions in practice. Their contours are known; their return to sam is easy to hear. The product question behind Lehra Composer starts there: can a player bring a favourite melody into the app, then practise with it using the same rhythmic tools?

The current guided route uses humming or singing. Choose the taal and BPM, follow a count-in, then sing one complete cycle. Recording begins at the scheduled sam. The selected instrument sets the sound for playback. The microphone captures the melody; the app proposes notes and their positions within the chosen taal.

1 Cycle positions2 Record3 Capture tempo

Capture one cycle

Guided input · workflow schematic

01Count-in····

02One cycle

03Hear + edit

That transformation requires several kinds of inference. The on-device pipeline uses probabilistic YIN (a pitch-estimation method) to propose pitch candidates. Viterbi decoding (selecting a likely sequence of candidates) finds a plausible pitch path. A hidden Markov model, or HMM (a model of changing hidden states), helps infer notes. The pipeline estimates tonic and tuning from the take, then quantizes rhythm (places events on a timing grid). Each stage answers a different question: which pitch, which note, and where in musical time?

The analysis follows one pitch line. A clean monophonic instrument (one melody line at a time) could meet that input constraint. Instrument capture still needs validation; the current guided route uses humming or singing.

The important product decision comes after inference. Hear recording and Hear lehra let the player compare the take with the proposed melody. Record again and Edit offer two ways to improve it. The editor supports changes to pitch, position, duration and accents. Applying the take, key and divisions becomes one undoable edit, so the musician can revise the interpretation without losing the previous work.

That is a concrete application of direct manipulation: visible musical objects, incremental changes, and reversibility.⁸ The transcription proposes a musical reading; the editor lets the player work on it. Uncertainty becomes something they can examine and change.

Name and save the melody, then select it under Your lehras in the practice screen’s RAAG menu. The saved melody and its Sa become the reference. Playback waits for Play. A familiar tune has become an editable lehra that the player can use in a new practice setup.

1 Editable note2 Undo

On-device transcription

Pipeline · schematic

1

Hummed take

2

Pitch candidates · YIN

3

Pitch path · Viterbi

4

Note states · HMM

5

Rhythm grid

6

Edit + undo

Apple’s guidance distinguishes application audio from system output volume and routing.⁹ Tabla Focus’s internal mix concerns the balance between its voices. Recording raises a separate responsibility: App Review guideline 2.5.14 requires consent and a clear indication.¹⁰ A microphone control carries an obligation to tell the player what is happening.

The iOS audio architecture

A timing control becomes credible when the audio system can preserve its meaning. The architecture begins with musical arithmetic, then turns that result into scheduled sound. Apple’s AVFAudio APIs provide the engines, players and clock coordinates. Tabla Focus supplies the rules that connect a ratio, an offset, a phrase and a cycle boundary.

The musical model comes first. Graha stores offsets as integer quarter-matras. The rhythmic planner uses an LCM (least common multiple) to combine compatible grids before it calculates sample spacing. A fractional layakari can need more than one avartan to close. The closure period is d / gcd(M, d) avartans, where M is the host’s matra count, d is the reduced ratio’s denominator, and gcd is the greatest common divisor. In a sixteen-matra taal, a 5:3 stream closes after three avartans. A change can wait for that compatible sam instead of cutting the current relationship short.

Preparation removes repeated work from playback. Sample decoding runs in a detached task. A generation check rejects results from a superseded request. The sustain profile checks frame counts, sample rate, loop bounds, crossfade size and the asset hash. The decoded bank is then reused. The audio path does not decode a new file for every note.

Absolute sample positions carry musical time. Tabla Focus’s LehraSequencer owns mutable scheduling state on a serial DispatchQueue (an ordered work queue). Its mapping is anchorSample + (matra − anchorMatra) × samplesPerMatra. Each event receives an absolute AVAudioTime sample position (a location in audio frames). A tempo change rebases the future mapping at the next unscheduled position. Buffers already queued retain their scheduled positions. This avoids building a timeline by repeatedly adding rounded event intervals.¹¹

The melody scheduler primes 150 ms ahead and schedules across a 500 ms horizon. The cue scheduler primes roughly 200 ms, bounded to two through eight ticks, then replenishes the queue from playback completions. These margins prepare future audio before its deadline. They are not measurements of tap-to-sound or output latency.

Two player timelines meet at a future sam. Tabla Focus’s Lehra graph uses 48 kHz mono voice buffers; the cue graph uses 44.1 kHz stereo buffers. Equal frame numbers do not represent equal durations. The sequencer resolves a future sam from its live render clock and converts it to host time (the system clock). The boundary carries its ordinal, generation and timeline revision. The cue scheduler maps that instant into its own player’s sample time.¹⁵ UI callbacks report progress after scheduling; they do not establish the audio clock.

The cue engine warms before it arms. Past boundaries trigger bounded retries. Generation guards make superseded selections inert. A musical change remains pending until the scheduled handoff makes it active. The system separates the requested configuration from the one already audible. That state distinction lets the interface explain a delay that has a musical reason.

Long notes need bounded storage. The sustain renderer preserves the original attack, reuses a calibrated sustain region with overlap crossfades, and schedules a release. Chunks are at most 250 ms. The scheduler queues about a second and replenishes it. A longer hold increases the repetition count; it does not require a PCM (pulse-code modulation) buffer for the entire note. Memory use and sound continuity become part of the same design problem.

Eight AVAudioPlayerNode voices feed a Lehra submix, reverb, makeup gain and a limiter before the main mixer. Optional tanpura and pad join on their own paths. The rhythmic cues use a separate engine and player. @Observable state on @MainActor updates the interface while the serial schedulers prepare future events. This division keeps the musical clock independent of screen redraws; it does not move every audio-session operation off the main actor.

AVAudioSession owns the playback context and current output route. Preferred hardware buffer values are requests; Apple says active values can differ.¹⁶ Route recovery has a settling delay and a bounded retry budget. Some route changes stop playback. Device buffers and output routes still add latency.¹⁸ The architecture contains safeguards against late scheduling and stale state. Their audible results require measurements on the device and route in use.

Tabla Focus has gone through repeated rounds of community feedback, and that conversation continues. Practice presents more situations than any first specification can contain. The community’s knowledge helps decide which ones deserve a clearer cue, a better control or a new tool.

Share an idea or feedback so Tabla Focus can keep improving.

Built with 💛 for lifelong Sadhana

References

1. Martin Clayton. “Theory and Practice of Long-form Non-isochronous Meters: The Case of North Indian rūpak tāl.” Music Theory Online 26.1, 2020. Full text.
2. Nielsen Norman Group. Recognition vs. Recall in User Interfaces.
3. Amy C. Beegle. Melodic Rhythms of India. Smithsonian Folkways. Teaching resource.
4. Apple. Visual Design and Accessibility. WWDC 2019.
5. Apple. Designing Sound. WWDC 2017.
6. Martin Clayton, Kelly Jakubowski, and Tuomas Eerola. “Interpersonal entrainment in Indian instrumental music performance.” Musicae Scientiae 23.3, 2019, 304–331. Accepted manuscript.
7. Nielsen Norman Group. Progressive Disclosure.
8. Ben Shneiderman. “Direct Manipulation: A Step Beyond Programming Languages.” Computer 16.8, 1983, 57–69. DOI.
9. Apple. Playing Audio. Human Interface Guidelines.
10. Apple. App Review Guidelines, §2.5.14.
11. Apple. AVAudioPlayerNode. Developer Documentation.
12. Tabla Nawaz Academy. Taal, Laya, Gat Pran.
13. DigiTabla. Layakari: Concepts and Definitions.
14. Ali Akbar Khan Library. Glossary.
15. Apple. AVAudioTime. Developer Documentation.
16. Apple. AVAudioSession — Requesting Audio Session Preferences. Technical Q&A QA1631.
17. DigiTabla. Layakari in Practice and Performance.
18. Apple. AVAudioSession outputLatency. Developer Documentation.
19. Tabla Legacy. Solo and Accompaniment. Practitioner teaching resource.