Closed raphaelgoulart closed 1 month ago
Thanks, I'll fix both of those :+1:
Question for you, has there been any discussion about 5 or 6 string bass support? These have been difficult to work with in RB3 protar and Rocksmith, requiring hacks to encode the tuning, and it would be very nice if YARG had more direct support.
Specifically I would suggest: if the bass tuning lists have 5 or 6 offset numbers, they should be interpreted relative to BEADG or BEADGC tuning. This shouldn't conflict with any existing conversions since real_bass_tuning
from songs.dta
should only ever have 4 numbers (more are ignored by the game).
real_bass_tuning = 0 0 0 0 0 "B standard"
real_bass_tuning = -2 0 0 0 0 "Drop A"
real_bass_tuning = 0 0 0 0 0 0 "B standard"
No problem if this hasn't been hashed out or won't be immediately supported, but it'd be helpful if I can handle reading/writing them now in a way that will match what is implemented later.
I suppose this also applies similarly to 7/8 string guitar but that has a few more issues to tackle (display, MIDI spec, etc.) :sweat_smile: But likewise, real_guitar_tuning
with more than 6 numbers could be defined as being relative to BEADGBE or F#BEADGBE.
That's a great question; YARG can (and probably will) support 5/6-string bass charts - most likely, Pro Bass and Pro Guitar will share the same engine/specs exactly, without any arbitrary limitations.
In fact, a few of the Pro Bass charts I've made for the main setlist had more than 4 strings, although I've set the tuning relative to EADGBE in the metadata (i.e. real_bass_tuning = -1 -1 -1 -1 0 "Eb Standard Bass"
in a chart that required an upper string, or real_bass_tuning = -10 -10 -8 -8 -7 -7
as a more extreme monstrosity).
Obviously, these charts haven't been implemented yet, so I am free to change these at any point. My initial idea, however, was just for the data to be converted from one text format to the other, but otherwise be untouched - as it is, it would help me greatly to test the charts in RB3, since chord names are impacted by the tuning and it's one of the things I can only double-check in the game itself.
Also, a factor against handling tuning differently is that it goes against what Charter and Pro Guitar Preview for REAPER expect - the tunings I sent above are also the ones I used in the charting softwares. It's not a HUGE issue though, since it's fairly easy to convert EADGBE-based tuning values to BEADGC, and it would only have to be done in the .ini once.
I will discuss this with the charting team and the dev team, it shouldn't be difficult to decide hopefully.
A preliminary discussion with the charting team favored EADGBE-based tuning for everything, for parity with the existing charting tools and ease of implementation. Sure the strings will look ugly for 5S/6S Pro Bass tunings, but it's not a major issue since that's not something the player will see directly, and 5S/6S bass will still be supported nonetheless.
However, there are very few protar charters in the team (so there wasn't a lot of discussion lol), and this is by no means a final decision, so I suggest bringing up the conversation in #proposals or #suggestions in the YARG Discord (whichever you have access to)
For now, I suggest implementing as just direct data conversion, and changing later if necessary.
This should be working in version 20240928
, using the EADGBE reference in all cases. I didn't yet add names to any tunings going RB -> CH; I'll plan on adding that later at least for common tunings. Let me know if there are any issues.
Perhaps surprisingly, tuning data is supported in the song.ini file, but is ignored when converting to RB3 (tuning in the .dta defaults to 0 0 0 0 0 0 even if an alternate tuning is specified in the song.ini)
Conversely, converting a RB3 chart with custom tuning to CH/PS format also leads to the tuning not being included in the .ini file.
A few examples:
real_guitar_tuning = -1 -1 -1 -1 -1 -1 "Eb Standard"
(real_guitar_tuning (0 0 0 0 0 0))
(real_guitar_tuning (-1 -1 -1 -1 -1 -1))
With Pro Guitar support planned for YARG 0.13 (and presumably already present in Phase Shift), it should be worth looking into implementing support for those tags in conversions. Hopefully it should be straightforward to implement as well!
Let me know if you need any extra info!