Feature Request: ability to position a clef arbitrarily

[ericjs]

A treble clef is a G clef positioned so as to place the G4 on the second line of the staff (as located by the center of the loop at the bottom of the staff). While not often used any more, technically it can be positioned anywhere to make a different line (or space) to be where G4 is located on the staff (e.g. a "french violin clef" places the G4 on the first line). Something similar applies to the other clefs (F3 of the bass clef, etc.).

It would be nice to be able to set up a clef in any position when wanted to enter some historical score, for example Bach's autograph of BWV 995, where the G clef puts the G on the second space.

[guiv42]

Similar problem as #37 and #270: data related to some objects is spread all over the code base. This also applies to "Clef". Before trying to implement this feature, a first step of rationalization is needed: define one single place in the code to hold all attributes of a Clef. Not a trivial issue. A few examples of Clef attributes (not exhaustive list):

Note name and octave of first line: https://github.com/helge17/tuxguitar/blob/4a7fc87b04130e1c35c047588bc2f77ae122163c/desktop/TuxGuitar/src/org/herac/tuxguitar/app/view/component/tab/edit/EditorKit.java#L40

Clef name: https://github.com/helge17/tuxguitar/blob/4a7fc87b04130e1c35c047588bc2f77ae122163c/desktop/TuxGuitar/src/org/herac/tuxguitar/app/view/dialog/clef/TGClefDialog.java#L54

positions of sharps/flats: https://github.com/helge17/tuxguitar/blob/4a7fc87b04130e1c35c047588bc2f77ae122163c/common/TuxGuitar-lib/src/org/herac/tuxguitar/graphics/control/TGMeasureImpl.java#L39

width: https://github.com/helge17/tuxguitar/blob/4a7fc87b04130e1c35c047588bc2f77ae122163c/common/TuxGuitar-lib/src/org/herac/tuxguitar/graphics/control/TGMeasureImpl.java#L58

graphical representation: https://github.com/helge17/tuxguitar/blob/4a7fc87b04130e1c35c047588bc2f77ae122163c/common/TuxGuitar-lib/src/org/herac/tuxguitar/graphics/control/painters/TGClefPainter.java#L12

vertical position: https://github.com/helge17/tuxguitar/blob/4a7fc87b04130e1c35c047588bc2f77ae122163c/common/TuxGuitar-lib/src/org/herac/tuxguitar/graphics/control/TGNotation.java#L8

note: some of these are redundant.

[ericjs]

@guiv42 , Is there any kind of separation between model and view or is it all just UI-centric code containing ad hoc model bits?

[ericjs]

Sorry, thinking further I realize the idea of model and view relate here a little more complexly than usual. I assume the data of the score itself is at least separated from the view? The model I'm thinking of here is a coherent and complete model defining the details of how the score is rendered onto the staff. So it seems like such a model would need to be created and the usage of these various bits currently in the form of scattered static arrays and such replaced with the usage of such a model, yes?

Besides the items you've collected here @guiv42 , I'd add the ability to have a transposition or scordatura (if there's not already an issue, I can add one). For where there's tablature rather than the staff, different tunings would call for the same kind of rendering model.

[guiv42]

Is there any kind of separation between model and view

Difficult to answer, the code base is huge and not documented! My impression is that there is globally some separation between data and graphical representation, but the frontier is not so clear. And some significant portions of code manipulating data are spread across the code, together with graphical rendering. This is typically the case for Clefs: basically the only "data" for Clef is just an integer in the range [1..4]. Then each ui-related function depending from clef (re)defines the additional needed data. Rationalization should be possible here (I'm currently working on this first step).

And just a small (but important) detail about your initial post:

A treble clef is a G clef positioned so as to place the G4 on the second line of the staff

Take care, the treble clef used for guitar (and TuxGuitar) is not this one: there is an (implicit) 1-octave shift. The G4 is just above the top line of the staff. Some software make this explicit by drawing a "8" just under the treble clef, that could be useful to add this in TuxGuitar also to make this offset explicit.

I'd add the ability to have a transposition or scordatura

Sorry but I do not understand this request. When I look for "scodatura" on the web, I find "tuning different from the normal one". If that's the case it's already available. Just click on menu "Track/Properties" (or double-click on track in track's table at bottom of screen), then you have a button to choose tuning (and eventually force a transposition offset). If it's something else you're asking for, could you please precise your request?

[ericjs]

By transposition, I meant what you described for guitar. Some instruments are "transposing" instruments and music for them is traditionally written on the staff transposed from how it sounds. For some instruments it is something other than an octave.

Technically transposition can also be considered a form of scodatura, but scodatura is a little weirder, because scortadura means tuning one or more string differently than normal but writing the music on the staff as if it was not tuned differently. An example is Bach's cello suite #5 is written for the top cello string to be tuned down from the usual A to a G. This causes the weirdness that only some notes on the staff are off a tone from what you expect. I'm not positive but I think a rule like "notes above / below such an such a note get the shift applied" could work (I'm not sure if scortadura would ever be used for just a middle string). I'm not sure since obviously the range of the strings overlaps... I realize this is potentially problematic, and it would be pretty niche feature, but it is fodder for thinking about how detailed a staff-rendering model should be, so that it could at least theoretically support such a thing (or some other thing we've not yet thought of or encountered).

[guiv42]

Some instruments are "transposing" instruments and music for them is traditionally written on the staff transposed from how it sounds.

That is exactly what "Offset" parameter does, in the "Track properties / Tuning" dialog.

About scodatura, thanks for the explanation, this is completely new to me. But it really sounds like a "niche feature", so honestly I don't think this should be considered.

it is fodder for thinking about how detailed a staff-rendering model should be

Here I need to be fully transparent about current development status. This repo started here about a year ago, from a huge and not documented code base. So every single evolution is a challenge. We are slowly gaining maturity, step by step, with limited workforce and skills. So, currently any serious modification of the app data or rendering models is completely unrealistic. So I consider "scodatura" out of scope. Anyway, I want to address the rationalization of Clef object implementation. Globally such cleanup activities may not be immediately visible to users, but in my opinion they are a necessary step if we want to maintain TuxGuitar on the long run.

So here is my current plan:

1. short term: define all Clef attributes (see above) in a single TGClef object, and propagate everywhere. This task is already started.
2. long term (i.e. not planned yet): add user interface to define user-specific clef. Exactly like the description in your first post. Note that this evolution requires to break compatibility of TuxGuitar file format.