Concept of number of frets, choosen instrument, tuning and auxiliary lines above the staff

[BeFrankly]

Hello,

I was just wondering if Tuxguitar has a concept on how to deal with the above. I just tested what the highest note is (I'm also thinking of testing the lowest note), and found that with the standard steel string guitar I can't hear any sound from the 22nd fret onwards. When I change instruments, e.g. a clean guitar, I hear a tone up to the 29th fret. The 29th seems to be the highest possible fret.

Have you ever seen a guitar or instrument with 29 frets?

I've also noticed that when you switch to view->fingerboard, the board only shows 23 frets. Mmmh. That's amazing, because you can get up to 29 frets in the score .

So what is the concept behind this? I was wondering what should happen when you switch from a clean guitar (29 or in real life 24 frets) to an instrument with only 22 frets. Should Tuxguitar issue a warning and highlight the notes that you can't play on the selected instrument.

Great if someone tells his or her opinion about that.

[guiv42]

Hi. That's an interesting question...
Currently there's no such thing as a "number of frets" associated to an instrument in TuxGuitar. This can sometimes lead to unexpected behavior (see issue #71 for example).
That being said, it's not a trivial issue. What could be a max number of frets for any non-fretted instrument? (a piano track).
It's also possible to play above the highest fret: I have in mind the slide guitar solo from Clapton's "Layla", I think it reaches 29 or so, even on a 22 or 24 frets instrument.

From software perspective: there is a max value of 30 (100 for percussion channel). But not so easy to change, as it is hard-coded at several places.

[BeFrankly]

Oh, yes, @guiv42 , i forgot to take a look at the bending effect. As long as a fret based instrument has a fixed number of frets, it depends on other physical details, of how high the tone can be.
And even Tuxguitar could not know which instrument the sound engine es using. When just sending MIDI signals to Jack or something, for example.

At least I think, the composer himself need to have knowledge about the borders of what one can do with the instrument.
I guess I have seen some supporting features for composers in other software, so that a warning is raised, when he leaves the range of an instrument.
But how much should this software support. Should it highlight a warning, when when finger set of the the left hand is physically not possible? Who is the guitar player? Is it a master who can spread his fingers over 7 or 8 fets?

So nothing that should be implemented in Tuxguitar. To my opinion, you only have to think about adding some frets to the fretboard view, because 24 frets are not visible at the moment. Or you place attributs on the score that tells Tuxguitar the physic of the Instrument (Deepst and highest tone, number of frets).

[belfie13]

a penny for my thoughts,
│
│ I would put 24 frets in the view because there are a
│ few guitars these days with that many.
│
│ also the hard coded limit of 30 frets doesn't need to change.
│ the instrument attribute view would be helpful somewhat,
│ at least you know what your dealing with.
│
│ i don't think warnings should be given if a score is
│ not physically possible but perhaps if it's not
│ programmatically possible. like if a bend will reach past
│ the range of the software instrument? it might be hard to
│ fault find the tip of a bend not playing in a score, in this
│ rare case, maybe it should say 'hey, that note isn't going
│ to play on this instrument'. but then there's too many places
│ that could happen, like drum tracks with the wrong note mapping,
│ or pitch bends on a grand piano, among many others i could
│ probably think of. actually pitch bends on a grand piano would
│ work on software 🤣 i haven't seen one in real life but maybe
│ theres a pedal that stretches the back of the piano.
↓
but why did i have to put my two cents in? 🤪

[zuzute]

Hi guys.
I would like to humbly ask you not to set a hard limit of frets to such a low value as 29. I've seen the number in the patches and it makes me sad.
Generally, 27-28 frets look like a reasonable limit like Fodera's A.Jackson model or mine custom Long Drone Controller Mk1 (4 string bass with a long scale tuned A-E-B-F#->A, i.e. 4 octaves, 27 frets). But I've seen a lot of instruments with more than 30 frets, even my friend has a 31-fret 7-string guitar (B -> B, 5 octaves). Many custom shops will make you a 36-fret instrument if you pay enough. They may even stuff a humbucker + sustainer in the space left!
Also, as said above, the slide has no fret limitations. Some weird people (including me) sometimes use pickups, nails, and picks as "frets" to get a higher note when using harmonics is inappropriate for some reason. I've seen a guy with a custom-made pick (one side was metallic to more easily use it as a "movable fret").
So, to summarize:
Please reconsider. (c) the blue elephant from SWTOR
To at least 36 frets.

Edit: no need to bother with more than 24 frets in the fretboard view, of course.

P.S. Conklin 36-fret bass:

[guiv42]

For sure the limit can be debated: different users, different instruments, different use cases... it seems to me it should be valuable to make this parameter configurable somehow.
That being said, actual state of the code base is not very favorable. Such a limit exists at several different places in the code, each time with a hard-coded value. Not so easy to identify all occurrences.

I've seen the number in the patches and it makes me sad

Yes I have added another occurrence of this limit recently. To reassure you, I did this consciously. And no need to be sad: I don't consider this a stable situation, but more a short-term solution to fix faster another issue.
It is my intention to rework this. I just cannot do everything at the same time.

So I can propose a plan in 2 steps:

1. keep existing hard-coded limit, but cleanup and rationalize the code to have one single value defined. A candidate solution could be to store it in TGTrack.java class, so we can define a different limit for each track one day. Quite tricky to implement.
   I will create a dedicated issue so we don't forget this point.

2. open parameter to user configuration
   for example with a new field in track properties dialog.

Note: this would break compatibility of file format (additional data to store)

[zuzute]

For sure the limit can be debated: different users, different instruments, different use cases... it seems to me it should be valuable to make this parameter configurable somehow. That being said, actual state of the code base is not very favorable. Such a limit exists at several different places in the code, each time with a hard-coded value. Not so easy to identify all occurrences.

Agree, codebase cleanup/refactoring should be a priority now, it'll make things much easier later.

Yes I have added another occurrence of this limit recently. To reassure you, I did this consciously. And no need to be sad: I don't consider this a stable situation, but more a short-term solution to fix faster another issue. It is my intention to rework this. I just cannot do everything at the same time.

Sure, take your time, it's not a huge problem. I appreciate that you guys pulled TG from oblivion. I'm still using TG in most cases (sometimes up to the final production stage) despite having GP and various other commercial software. TG just feels comfortable and I'm glad it'll stay alive.

So I can propose a plan in 2 steps:

1. keep existing hard-coded limit, but cleanup and rationalize the code to have one single value defined. A candidate solution could be to store it in TGTrack.java class, so we can define a different limit for each track one day. Quite tricky to implement.
   I will create a dedicated issue so we don't forget this point.
2. open parameter to user configuration
   for example with a new field in track properties dialog.

Seems reasonable. No hurry. Do what you think is most important now. Sadly, I'm not well-versed in Java and can't help much with the coding part.

Note: this would break compatibility of file format (additional data to store)

Eeeh, let's leave it for now then, until 2.0 or so. It's no pressing issue.

[guiv42]

Agree, codebase cleanup/refactoring should be a priority now, it'll make things much easier later.

Issue #256 created for that purpose.

[guiv42]

Configuring max fret number per track should be quite simple now (see #260, hope I haven't forgotten any other hard-coded limit). Possibly, just a new field in track properties dialog could be sufficient. To be implemented in a future version where .tg file format evolves.

[guiv42]

See PR #521: max fret number is now configurable per track (except for percussion tracks), in tuxguitar-next branch