Partial re-render of a measure

[roscopeeco]

From my brief research I understand (I may be wrong) that there are no plans to extend the functionality to allow editing of notation.

It would be very helpful though if there was functionality added to the api to re-render of a single measure using provided data or the original source data.

This would make editing notation using alphaTab a possibility in conjunction with the other api calls alread available.

[roscopeeco]

In addition insert rendered measure and delete rendered measure api calls would be the icing on the cake.

[Danielku15]

From my brief research I understand (I may be wrong) that there are no plans to extend the functionality to allow editing of notation.

It is currently not directly on our radar to have built-in editor capabilities. But technically most bits should be available to build an own editor on top of alphaTab. In fact there is a project around which does this:
https://github.com/gallegretti/escala
https://gallegretti.github.io/escala/

It would be very helpful though if there was functionality added to the api to re-render of a single measure using provided data or the original source data.

You might be very focused on a specific problem here which might not even exist. Behind the scenes alphaTab holds a data model with all information. Then you trigger a re-layout and rendering whenever edited.

Generally alphaTab should be performant enough to always do a full re-render. The tricky thing is that any change might lead to a significant layout change which anyhow requires a proper full layout to be computed.

Either you adjust the data model directly or you could also use alphaTex as a main source of truth and do manipulation of the abstract syntax tree using the new parser. The alphaTex AST might be a lot more lightweight for code based editing.

Alternatively there is a JSON based flavor of the data model via alphaTab.model.JsonConverter which could be easier to manipulate.

In addition insert rendered measure and delete rendered measure api calls would be the icing on the cake.

The trickiest thing is so handle the data consistency in the data model correctly but generally it is not rocket-science do manipulate the data model. Score.finish() tries to consolidate already most of the bits. The ModelUtils.consolidate is currently internal and very specific to the importer needs. But you could learn from it to implement what you need.

Having more dynamic editing apis to insert new items into the data model is something I have on the roadmap, but it simply wasn't important enough compared to other features to make it to the backlog. 😅

[Danielku15]

is there a config setting to achieve a grid layout so that all notes are spaced evenly across all measures? for any editing ux feature to work it's a must have to allow users to just toggle to notes on and off.

alphaTab only allows "rhythmic spacing" where notes are spaced according to their played duration. Only this way notes are correctly aligned. If multiple instruments/staves/voices are displayed, the notes need to align accordingly. Depending on the optimizations the software implements, the spacing gets "better" in scenarios where many durations are mixed:

alphaTab:

Guitar Pro:

MuseScore:

Theory:

I haven't seen any proper alternative solution to how music notation is displayed. Having even spacing where all notes have the same width, will not only cause problems in the display, it is a clash of music notation principles. IMO users rather expect correct rhythmic spacing of their music sheet.

Hope that helps understanding what's behind the scenes.

I've got the bars appearing evenly spaced but the notes spacing varies between bars...does any editing features have to have 'empty' notes created (16 notes for a 16th note sub division bar) for this to work correctly?

In this screenshot I see an uneven amount of notes in the bars and they are not correctly "filled" with the available time. Assuming a 4/4 time signature, you have space available for 4 quarter notes but all bars have less notes in them.

Bar 1: 13 beats with 16th notes == 3 quarter notes and 1x 16th note. 3 16th notes are missing.
Bar 2: 8 beats with 16th notes == 2 quarter notes. 2 half note is missing.
Bar 3: 10 beats with 16th notes == 2 quarter notes and 1 8th notes. 1 quarter and 1 8th note are missing.

If the musician is supposed to "pause" playing during the remaining time, you are supposed to write rests to fill the bar. Here a screenshot with 3 bars fully filled with 16th notes. Every note takes the even amount of space:

alphaTab:

MuseScore prevents incomplete bars from how they designed the editor. you can only lengthen and shorten the notes and it will automatically insert notes or insert/remove rests so that the bar is 100% filled:

Guitar Pro allows incomplete and overflowing bars. They are highlighted in red if the bar is incomplete:

[roscopeeco]

I understand what you are saying about the spacing and rests. The grid display would ONLY be for the purposes of editing. Maybe only the bar being edited needs to be re-rendered to display as a grid.

I've got a certain understanding of drum notation as I have developed a prototype drum notation web app which allows editing in a grid system (see attached image). It mainly uses css and a bit of svg for display but allows clicking beats on and off and setting articulations. Performance in my app isn't great for rendering a full song whereas alphaTab is great performance wise.

The reason for a grid format is easier user experience. I get the impression you are assuming that someone creating notation is going to a be knowlegeable. I am making no assumption and see it as a teaching aid making it easy for the beginners/students to jut click and see the resulting notation.

Maybe if alphaTab is not really suitable for editing in a grid format I could use a hybrid approach of using my editing app functionality in a modal when a user clicks on an alhaTab score bar.

One other question: Is there anyway to configure alphaTab to display hi-hat eight notes beamed. In the second attached image of alphaTab drum notation it's got 2 voices - cymbals and drums but the cymbals with 8th notes should have single beam per half note.

[Danielku15]

I understand what you are saying about the spacing and rests. The grid display would ONLY be for the purposes of editing. Maybe only the bar being edited needs to be re-rendered to display as a grid.

I've got a certain understanding of drum notation as I have developed a prototype drum notation web app which allows editing in a grid system (see attached image).

Quoting Behind Bars, the "bible" of music notation:

I think good user experience means meeting the expectations of users (musicians), hence: rhythmic spacing. I'm open to learn about other industry practices. Do you have any real references around such a even-spaced practice being a common thing?

Theoretically you could try to patch out things in alphaTab for your app to force it to even-sizing. But my doubts and concerns remain that you might be doing risky things.

alphaTab uses an algorithm based on Gourlays Spring-Rod model. Where "springs" define the spacing between rods (spots where notes are placed). The strength of the spring is determined by the time-difference between elements. For uniformed spacing, you would need to think of a calculation that results in equal spacing. For handling multiple tracks/staves/voices it can get tricky, but for single-voice displays it might be easier. The spot where we calculate the "strength" of the springs is here:

alphaTab/packages/alphatab/src/rendering/staves/BarLayoutingInfo.ts

Lines 337 to 351 in adca157

	private _calculateSpringConstant(spring: Spring, duration: number): number {
	if (duration <= 0) {
	duration = MidiUtils.toTicks(Duration.TwoHundredFiftySixth);
	}
	if (spring.smallestDuration === 0) {
	spring.smallestDuration = duration;
	}
	const smallestDuration: number = spring.smallestDuration;
	const minDuration = this._minDuration;
	const minDurationWidth = BarLayoutingInfo._defaultMinDurationWidth;
	const phi: number = 1 + 0.85 * Math.log2(duration / minDuration);
	return (smallestDuration / duration) * (1 / (phi * minDurationWidth));
	}

Here some references that might be interesting for you.

https://github.com/w3c/mnx/blob/1985ffb41076c3e11acc6a9d6cd00368f2772c0a/references/Gourlay%20-%20Spacing%20a%20Line%20of%20Music.pdf
https://guido.grame.fr/papers/kai_renz_diss.pdf

I get the impression you are assuming that someone creating notation is going to a be knowlegeable. I am making no assumption and see it as a teaching aid making it easy for the beginners/students to jut click and see the resulting notation.

With this assumption I fear might be teaching risky practices to musicians. Especially for drum and percussion musicians it is crucial to learn about duration and rhythms from the very beginning. Teachers, students all musicians alike aim to follow these ground rules.

Adapting to "beginners" is of course a good thing. But I think there is not much gain in this case. Having rhythmic spacing is not something extremely confusing, even if the beginners don't understand it from the start. If they only look at the note heads from the start, and play along, the understanding of the sizes might come naturally. The users-eyes can scroll along the notation as they play and do not need to speed-up or slow-down because spacing is uniform.

Is there anyway to configure alphaTab to display hi-hat eight notes beamed. In the second attached image of alphaTab drum notation it's got 2 voices - cymbals and drums but the cymbals with 8th notes should have single beam per half note.

Not yet. alphaTab has currently only 1 main rule of beaming notes (beaming within the same quarter note). #2399 is on the plan for 1.8.0. also: #2387

[roscopeeco]

This whole conversation is about creating an editor (in my case a drum notation editor) anything that makes that easier or more accessible should not be dismissed out of hand because of some elitist dogma.

I have drum books with notation that has uniform spacing of measures and the beats. In my opinion it is easier to read and I have never found it confusing. So by your thinking the authors of all-time classic drum books are teaching risky practises?

Also there are a plenty of musicians and drummers who can't actually read notation at all. So anything that makes it easier to learn should be applauded. Any music DAW (Ableton live, Fruity Loops) uses a grid system so the user can edit midi notes and beats. This has been standard practise for decades, Such musicians are totally at ease with using a grid (although no notation is displayed) and it doesn't prevent them from having rhythmic timing.

By having a grid for EDITIING actual notation it is combining/extending long established ease of use with education.

[Danielku15]

Let's see if we have the right common understanding on what we talk about and keep things topic-focused. We should avoid getting emotional about what's better in terms of personal preference. For me it is a matter of doing things correct and align with the real-world expectations of users. To set the stage for this:

How spacing works

When I talk about rhythmic spacing and the sizing practices it is about the fact that all notes are placed and spaced according to their times and duration when they are played. That's what all references I have (software, literature and printed music books) have in common and define as ground rules. Simply said: A quarter note is always twice as wide as an 8th note.

Next we need to define the sizes/distances for the spacing are determined. Most applications try to determine the space for a given time period X using the shortest note in a given period of time (either within a single bar, or a whole system/row). This is part of the formulas defined by Gourlays algorithm for horizontal spacing. A key-goal of this algorithm is to optimize the size needed and not scale things larger than maybe needed to fit the available space. The negative part of this system is having non-uniform spaced bars.

Many applications also have a "linear/proportional" scaling. Instead of using the shortest note as a reference, there is rather a fixed width defined for a known time period and everything is scaled relatively to this. For "vertical page/parchment" layouts the bars will still have to be fitted/scaled to the available viewport.

Additional elements like clefs, time signatures or key signatures further impact the spacing. They have fixed width and "shift" the time=0 position to the right.

How applications realize it

alphaTab calculates the spacing per time period X on a bar-to-bar matter. This is not the optimal solution to this problem as results in unevenly sized bars within a system because the base-width is determined by the smallest duration.

For a more "unified/uniform" spacing it is better to look at a whole system/row resulting in a higher
complexity and cost to do the spacing. It is an optimization I thought of, but have never implemented.

alphaTab

MuseScore tweaked to have equal bar widths showing that they look at the whole system

With MuseScore we can see well how the width of a quarter note in bar 1 has the same width as the 2 8th notes in bar 2 or the 4 16th notes in bar 3. This is thanks to looking at the whole system and something alphaTab could also achieve with a bit of implementation effort.

Also DAW applications have time based spacing. There is always a time axis to which the wave-forms or midi events align. This applies also to apps like Ableton, Fruity Loops, Audacity etc. You will not see a "distorted" time axis to fit every note that occurs to a fixed grid.

Generally it should not matter if we talk about viewers or editors. The spacing should follow the same rules. This has nothing to do with "elitist dogma" or thinking of "drummers only" or "musicians who cannot read music notation". Rhythmic spacing is one of the ground rules of music notation, the kind of scaling is subject to the need.

If we talk about beginners, they anyhow do not care yet why notes might be spaced like they are. Or even better: they question it and learn that notes are spaced according to their duration. Whether things are "easier" to read, is a subjective preference but having notes of different durations sized the same, is incorrect and rather cause of confusion.

---

That said, a simple question to preceed: What is really you ask for?

a) a feature to space notes of different durations evenly (my understanding so far)
b) a feature to have more proportional/linearly scaled durations to achieve a less "dynamic" sizing.
c) something else?

My references and the applications also you mentioned rather targeting (b). But the screenshot of your own app indicates towards (a).

Depending on your request, we can discuss further.

[AvaTheArchitect]

I personally would love to hear about the progress of anyone that does create an editor for in app use. My goal as well is to build one or work along with someone that wants to JV on building one that works with AlphaTab. Mine goes a bit deeper as I am trying to find someone that can help me create a data AI model for song stem separating, and then to parse them into tabs etc.

…

On Fri, Dec 26, 2025 at 4:01 PM Daniel Kuschny ***@***.***> wrote: From my brief research I understand (I may be wrong) that there are no plans to extend the functionality to allow editing of notation. It is currently not directly on our radar to have built-in editor capabilities. But technically most bits should be available to build an own editor on top of alphaTab. In fact there is a project around which does this: https://github.com/gallegretti/escala https://gallegretti.github.io/escala/ It would be very helpful though if there was functionality added to the api to re-render of a single measure using provided data or the original source data. You might be very focused on a specific problem here which might not even exist. Behind the scenes alphaTab holds a data model <https://alphatab.net/docs/reference/score> with all information. Then you trigger a re-layout and rendering whenever edited. Generally alphaTab should be performant enough to always do a full re-render. The tricky thing is that any change might lead to a significant layout change which anyhow requires a proper full layout to be computed. Either you adjust the data model directly or you could also use alphaTex as a main source of truth and do manipulation of the abstract syntax tree using the new parser <https://alphatab.net/docs/alphatex/importer>. The alphaTex AST might be a lot more lightweight for code based editing. Alternatively there is a JSON based flavor of the data model via alphaTab.model.JsonConverter which could be easier to manipulate. In addition insert rendered measure and delete rendered measure api calls would be the icing on the cake. The trickiest thing is so handle the data consistency in the data model correctly but generally it is not rocket-science do manipulate the data model. Score.finish() <https://github.com/CoderLine/alphaTab/blob/develop/packages/alphatab/src/model/Score.ts#L431> tries to consolidate already most of the bits. The ModelUtils.consolidate <https://github.com/CoderLine/alphaTab/blob/develop/packages/alphatab/src/model/ModelUtils.ts#L536> is currently internal and very specific to the importer needs. But you could learn from it to implement what you need. Having more dynamic editing apis to insert new items into the data model is something I have on the roadmap, but it simply wasn't important enough compared to other features to make it to the backlog. 😅 — Reply to this email directly, view it on GitHub <#2466 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BNLESQGGSFCRJREHSEQA42D4DXD5XAVCNFSM6AAAAACQCKO3ZKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZUHEZTINY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[Danielku15]

alphaTab mainly aims to ship a core which can also be used to build an editor. The whole UI/UX around an editor is very app specific.

The main gap I see in alphaTab there, are three things:

1. an easy-to-use API for doing data model modifications without breaking any consistency rules within alphaTab.
2. an better API for getting position and sizing information for a single bar to build a editor cursor.

The current solution to these problems are rather prone to errors:

1.a Use alternative representations of the data model (JSON or alphaTex AST) which are a bit more lightweight for modifications.
1.b Implement things yourself by learning all relevant bits for add/remove/edit of model elements.

2.a use the BoundsLookup as-is and re-implement some sizing bits using the information in the EngravingSettings (smufl)

If I ever build a full editor for alphaTab, it will ony be to provide a full alphaTab app for end users. 😁

[AvaTheArchitect]

This is good stuff! And the end user is exactly what I have in mind. I figured in order to do that. I will need to connect everything to a cloud server for persistent memory and storage. And especially, knowing that AI has its limitations, even on the apps now’s that create tabs … it’s usually far from perfect. So having that as a starting point, and then being able to correct the errors by the end users… will be a beautiful thing. Tied in the some educational training videos or learning modules for students who have never written tab before, etc. Very exciting topic!!!

…

On Sat, Dec 27, 2025 at 4:20 AM Daniel Kuschny ***@***.***> wrote: alphaTab mainly aims to ship a core which can also be used to build an editor. The whole UI/UX around an editor is very app specific. The main gap I see in alphaTab there, are three things: 1. an easy-to-use API for doing data model modifications without breaking any consistency rules within alphaTab. 2. an better API for getting position and sizing information for a single bar to build a editor cursor. The current solution to these problems are rather prone to errors: 1.a Use alternative representations of the data model (JSON or alphaTex AST) which are a bit more lightweight for modifications. 1.b Implement things yourself by learning all relevant bits for add/remove/edit of model elements. 2.a use the BoundsLookup as-is and re-implement some sizing bits using the information in the EngravingSettings (smufl) If I ever build a full editor for alphaTab, it will ony be to provide a full alphaTab app for end users. 😁 — Reply to this email directly, view it on GitHub <#2466 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BNLESQCQX7WEVTQEPJTXFAT4DZ2Q3AVCNFSM6AAAAACQCKO3ZKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZVGE3TMNA> . You are receiving this because you commented.Message ID: ***@***.***>