Jump to content

SmellyOrc

Member
  • Posts

    424
  • Joined

  • Last visited

  • Country

    Netherlands
  • Donations

    0.00 USD 

Posts posted by SmellyOrc

  1. The distortion tone was set as the default one. RS2014 does not show a tone change to that tone at the start of the first note (where i set the tone change to Distortion).

     

    This is what's in the XML:

     

      <tonebase>Distortion</tonebase>
      <tonea>Distortion</tonea>
      <toneb>Acoustic</toneb>
      <tones count="1">
        <tone time="255.765" name="Acoustic"/>
      </tones>
     

    I've tried deleting the arrangement from the toolkit and re-adding it, but that didn't fix it.

  2. I don't know where to put this, here or in the toolkit thread, since I don't know which one is "at fault".

    Anyway, I have a song where I essentially only have one tone change: at the end of the song (to an acoustic tone). So, knowing I have to have at least 2 tone changes in my song so I'm able to add a second tone in the toolkit, I added a tone change to a distorted tone (the one used in the rest of the song) at the beginning of the first note. However, the game does not pick up the second tone change (the one to the acoustic tone) correctly. It does pick up A tone change, but it only says "Song Title" and no add-on like lead, acoustic or whatever. Also, the tone does not change at all.

     

    What do I do?

  3. The "Precise Select Like" function does something similar to what you want. It selects every note that has the same fret and string number as your currently selected note. It will, despite its name, also select those same notes that have a different duration than the note you have selected, and it will also select the same notes that have a technique added to them.

     

    Precise Select Like can be used by pressing Shift + L, or in the Menu under Edit -> Selection.

    • Like 1
  4. Every word in the blue line comes out as a single line in RS2014. You can make those blue lines by selecting the words that you want RS2014 to show as one line, and then pressing ctrl + m.

     

    The grey thingy at the bottom is the sustain of the word/syllable, that is correct.

  5. Yes, that behaviour is bugging me as well. I figured that had to do with the graphics engine that is used by EoF.

     

    Also, I now have another bug regarding truncating short notes (this is in 4/4 time signature):

     

    http://puu.sh/fjuf1/f15e7267df.png/ss%20%282015-02-01%20at%2006.52.01%29.png

     

    Shorter notes than that are truncated, though:

     

    http://puu.sh/fjuFf/244328b9fb.png/ss%20%282015-02-01%20at%2006.56.02%29.png

     

    Guess it's another math error?

  6. Actually it does NOT matter what you call your tones in EoF, as long as you know the ORDER in which you made them. When you import the arrangement in the toolkit, the default tone will be the first tone, with the name you gave it in EoF. The second tone will be Tone B, with the same name as you gave it in EoF. Now, you can change these tones with tones that have a different name. The only "annoying" thing about this, is that the toolkit automatically adds the two, or more, tones to the tone list.

     

    So, in my opinion, the best way is to just describe the tone like Plum said (e.g. Songclean or SongDist), add the tones to your tone list in the toolkit, add the arrangement, then switch the tones in the arrangement with the tone you actually want it to have.

     

    TL;DR It does not matter if your EoF and toolkit tone names are different.

  7. I've found a bug in the "truncate short notes" feature.

     

    Anything shorter than a quarter note, regardless of time signature. If a note is tied to another, or has a technique where the duration is important to keep (slide, bend, vibrato) it is not truncated no matter how short the combined length is. If you ever needed to know specifics about any menu functions or preferences, check out the manual (Help>Manual). The preferences are described in the "Configuration EOF>Preferences" section.

     

    In short: quarter notes are truncated when they're in a 3/4 time signature bar:

     

    http://puu.sh/eKLGl/022106570b.png/ss%20%282015-01-19%20at%2011.28.15%29.png

     

    This gets truncated to this:

     

    http://puu.sh/eKLMj/5b98f6eeb5.png/ss%20%282015-01-19%20at%2011.28.48%29.png

     

    Just thought I'd give a heads up. Don't you just love bugs? :D

  8. I've got a crash bug that pretty reproducible. It involves deleting all the tech notes after the normal notes have been deleted.

    Here are the steps I use to create the crash bug:

     

    1) Import Guitar pro file with tech notes

    2) Ctrl + A to select all normal notes.

    3) Press delete

    4) Press F4 to go to tech note view

    5) Press Ctrl + A to select all tech notes

    6) Press Delete

    7) Crash

    8) ???

    9) Profit!

     

    Reproducibility is around 80%

     

    Edit: One more bug, but I don't know whether it's a bug or intended behaviour:

     

    I have time signature changes in my tempo map. Now, because #/8 tempo isn't handled properly yet, I use the double BPM feature as a quick n dirty work-around. Thing is, when I use it, the  time signature change moves to the next few bars over, so that it's in the exact same position time-wise (but not bar-wise, get it?). So, for example I have a 13/8 time sig at bar 31 (00:51 seconds) that I want doubled in BPM, and a 7/4 time sig change at bar 34 (1:08). When I double the BPM at bar 31, the time sig change to 7/4 is now at bar 37 (still at 1:08). And there is no change at bar 34. Is this intended?

  9.  

    I've got another 7-string custom that needs testing. I dunno why I keep making them, because I still don't have a 7-string :/

     

    Anyway, here it is: https://www.dropbox.com/s/24gv55dct0r334p/Mayan_Redemption---The-Democracy-Illusion_v1_p.psarc?dl=0

     

    B-Standard.

    Just tested it, and found the song was just slightly too quite compared to the tone. I think you should increase the song volume by 1 or 2 dB, other than that it is absolutely perfect. Great work.

    I also want to thank you for introducing Mayan into my music library, they are fantastic! 

     

     

     

    Awesome. Thank you for your feedback!

  10.  

    I think I've found a similar bug. Looks like it has to do with non 4/4 time signatures.

     

    This one's a midi import bug though:

     

    http://puu.sh/dbMEd/2b967273a4.png/ss%20(2014-11-30%20at%2008.33.52).png

     

    Is getting imported as:

     

    http://puu.sh/dbMyX/197ca86197.png

     

    In short: time signature changes are not imported at the right bars, and there's a BPM change imported right before some of these time signature changes. It happens usually when going from 13/8 to 7/4, but not always. It's... random?

     

    The gp5 file is here: https://www.sendspace.com/file/el1bjp

    The midi file is here (made from the gp5 file using guitar pro 6): https://www.sendspace.com/file/321n2b

    I've fixed this. As you say, beat lengths weren't being determined correctly in non #/4 meter.

     

     

    Was this fix included in r1363?

  11. I found another GP import bug:

     

    http://puu.sh/cD5H2/a21d57b602.png/ss%20%282014-11-04%20at%2006.07.00%29.png

     

    As you can see, bar 161 imports correctly, but bar 162 is missing one chord. Also happens at bar 163 and bar 166. It also goes out of sync by a few bars around bar 166.

     

    I've uploaded the GP file here for you to look at: https://www.sendspace.com/file/bapkut.

    EoF file is here: https://www.dropbox.com/s/j76e1sgpfc8b12b/Mayan%20-%20Paladins%20Of%20Deceit%20%28Pro%29.eof?dl=0

    Accompanying .ogg file: https://www.dropbox.com/s/igpclk05gdbnikf/guitar.ogg?dl=0

     

    I think I've found a similar bug. Looks like it has to do with non 4/4 time signatures.

     

    This one's a midi import bug though:

     

    http://puu.sh/dbMEd/2b967273a4.png/ss%20%282014-11-30%20at%2008.33.52%29.png

     

    Is getting imported as:

     

    http://puu.sh/dbMyX/197ca86197.png

     

    In short: time signature changes are not imported at the right bars, and there's a BPM change imported right before some of these time signature changes. It happens usually when going from 13/8 to 7/4, but not always. It's... random?

     

    The gp5 file is here: https://www.sendspace.com/file/el1bjp

    The midi file is here (made from the gp5 file using guitar pro 6): https://www.sendspace.com/file/321n2b

  12. It's sounding like a <chord> tag for the highlighted section is not needed, just a <handshape> tag that references a valid chord template. Can anybody confirm that? Now the only thing that would determine how I implement this is whether anybody else can confirm whether it matters what chord template is used for these sections. I'm guessing the template should still be accurate enough to have the game show correct fingering at the bottom of the screen. So if each highlight phrase needs to reflect correct fingering I may just make a new arpeggio type or something so most of the existing logic can be put to use.

     

    I've looked over the whole xml document, and the only <chord>  tags I can find are:

     

    <chordtemplates count>

    <chordtemplate>

    <chordscount> (which eof has set to 0 in this case. Don't know if that tells you anything?)

     

    chordcount = 0 means that it's not important/not used.

    <chordtemplates count>  is necessary, otherwise the toolkit does not generate a file

    <chordtemplate>  is necessary for the chordID that the <handshape>  tag refers to, and has information on the fingering/handshape.

     

    Now, in official DLC, the highlighted phrase only has notes that are in that chord/handshape. However, it still works if it has notes that either don't conform to the handshape, or are even completely out of the highlighted area (width. So if the highlighted area's width is from fret 2 to 5, if you have a note on fret 6, it still works. The note will just appear outside of it.)

     

    I hope this clears anything up. If not, I don't know what you mean with the <chord>  tag, as I can't find any other instances of <chord>  in the XML file, other than the ones listed above.

     

    So as I said before, it looks like it's using the same logic as arpeggios, with the only difference being the display name? That is assuming the EoF arpeggio logic isn't using anything that's not important ;)

×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. - Privacy Policy