Jump to content

SmellyOrc

Member
  • Posts

    424
  • Joined

  • Last visited

  • Country

    Netherlands
  • Donations

    0.00 USD 

Everything posted by SmellyOrc

  1. Wouldn't it be easier to save a gp4 file as a gp5 file? Guitar Pro 6 at least supports this.
  2. I'm not changing any tone changes or names in EoF, but simply editing the arrangement. Then the ORIGINAL Eof XML is used by the toolkit (of course, because they have the same name as the altered one afaik), and this generates an error. Except that if you have a ton of tone changes in your arrangement, it'll add those generic names that I use in EoF to the tone list, and after re-assigning the tone, I'll end up with multiple tones with the same name. Also, removing and re-adding an arrangement because I changed a note from non-mute to palm muted (for example) seems a bit over-the-top, does it not? It's not complicated, the fix is easy. But somehow, they're not seeing it.
  3. That's what I did. THEN I changed something in the arrangement, saved it again in EoF, and THEN when I generate a package, I get that error. THEN when I change the XML as described in my previous post, it works just fine. And to add to raynebc's answer, yes it's normal, and it's only there in order to get a song working with only one actual tone change. EoF needs two tone changes in order to export them correctly (afaik), so I set tone change at the start of the song which "changes" to the tone already set. It's aaaaaallll good.
  4. More tone issues! Yay! I've used the workflow that has been prescribed (Tone changes in EoF, load in toolkit, edit the tones and load the tones I want). Now, when I change something in EoF and re-save, I get the following error upon re-generating: http://puu.sh/iYS9k/5165ec8d65.png And I'm getting sick of it. The only way to fix it is to re-add the arrangement and then go to edit tone -> load the tone again. Re-saving the file in EoF does NOT work. And with the tone window taking forever to show up, it's really annoying. Now, if you'd just implement the fix I've set out before, I bet my ass that it will solve EVERY tone change issue that might crop up. I'm talking about this fix in http://customsforge.com/topic/989-custom-song-toolkit-v2600-was-released/page-20?do=findComment&comment=154110 : Guess what I did. I manually changed the XML file from http://puu.sh/iYSrn/f7619b0c53.png to http://puu.sh/iYSt1/9b4971feb9.png And it worked. This is the EoF tone list: http://puu.sh/iYSvi/5994fa5f80.png And here's the arrangement window: http://puu.sh/iYSxH/163b780a89.png
  5. Just you. There are quite a few tutorials on how to use EoF here: http://customsforge.com/forum/78-tutorials/ And as for the red sections: it means that the duration of the notes/rests does not add up to what it should according to the time signature. In GP6, the duration of the note and the duration of the bar you're currently in is noted at the bottom. A full bar would show 4/4, while a read one might show anywhere from 0.5/4 to 3.5/4 or 3.5/8 etc, depending on your time signature.
  6. To the first question: Yes. As seen in this official DLC, chord panes are displayed inside handshape phrases: https://www.youtube.com/watch?v=mI_fniggOS0 Second question: yes.
  7. There is no need to wait for feedback, if you think it's ready, just submit it. Here's a quick checklist though: - Sections - Good sync - Good tones/tone changes - Leading silence - WORKS!
  8. That should not be happening. First off, because when you update, the default settings are the same as any previous versions, and there should not be any change in behaviour. If there are, Press F11, disable "Apply crazy status to...." and set chord density threshold to 10000 (10 seconds) ms. But don't set it to 10000. That's silly. 1000 is good enough, and probably too much already.
  9. True, and disabling that function and setting the chord density threshold to a low value would do the same anyway.
  10. I want a repeat line even if there is a rest between chords, if the former chord is a palm/string muted chord. palm/string muted chords don't ring out, and when you have a lot of switches between muted and non-muted chords, it could clutter up the screen. For example, this is how something like that is currently imported: http://puu.sh/ipHRe/6bcd59a092.png In essence, those palm-muted chords don't need a crazy status, because they don't ring out anyway.
  11. Thank you! lots of great improvements :D Edit: I think you can improve the 'Apply crazy to repeated chords separated by a rest' function by making an exception if the previous chord is a palm or string muted chord. What do you guys think about that?
  12. I have uploaded a project here:https://www.dropbox.com/s/67b3zu5xs18vu6m/Amorphis%20-%20Day%20of%20Your%20Beliefs.rar?dl=0 This is my workflow: 1) Create tone change. 2) Give a descriptive name, like "Acoustic", "Distortion" or "Lead", for example. 3) Save project in EoF. 4) Add XML file as arrangement 5) Toolkit loads the descriptive tone names 6) Add real tones to my tone list 7) Edit arrangement to change the tones to the ones that I have loaded. 8) Make everything else correct in toolkit 9) Save 10) Generate 11) ERROR Note: it does not matter if I load the real tones (the ones that I'll use/try out) before or after I add the arrangement. The problem is that the toolkit changes the XML file to reflect the changed tone names in the <tonebase> <tonea> etc fields, but not in the ones after that, the fields that specify the time of the tone changes: http://puu.sh/i4QN1/e8e89524b5.png So in the above case, the EoF tone names have been changed from Clean and Distortion to Clean_Reverb and endofhope, respectively. Done manually, by me. In the Edit arrangement box. The <tone time> stuff still uses the old tone names, and therefore returns an error. If I manually edit those tone names to Clean_Reverb and endofhope, the package generates just fine, and the song plays just fine as well. If you need anything else, let me know. PS: The project I've uploaded is a different project from the one described here.
  13. There's something broken in RS2014, since turning it off won't always stop the game from leveling you down. Unless of course, you open the riff repeater menu every time you start a song. Which is annoying. That's why I stopped including DD in my CDLC.
  14. It's the closest you can get if you want to slide from an open 6th string. If you're on the 5th string or higher, you can transpose it to one string lower, 5 frets up (or 3-4 depending on which string you're coming from, and the tuning), and then slide up. So for example, if you have an open string note A that you want to slide up, in standard tuning this would be an open note on the fifth string. Fret 5 on the sixth string is the same note (in standard tuning).
  15. You can't. What you could do is have an open string note, then a hammer on to another note, which slides upwards. RS2014 does not support open string slides.
  16. Right... that might be a problem. Maybe start the look-up from the end of a chord instead of the beginning? Or just do the automatic crazy toggle thing. Probably easier.
  17. At the moment. YES. But not if you remove the look-ahead logic that EoF currently uses, which is what I'm basing this argument around. *bangs head on desk*
  18. Except that most charters either don't know about this, or don't care. Ten seconds is a LONG period for forward looking. I believe the easiest way to fix this would be to have EoF import chords with their correct length (so NO truncating chords to 1ms even though truncating short notes is on), and then just doing no look-ahead. This will achieve the following: * No more chord boxes that are 1 ms in length. They look so ugly, and chords don't need to be truncated anyway. * No more incorrect chord sustains * This might lead to slightly increased screen clutter, but this is negligible in 99% of the cases * Rests will now be properly be "imported" (goes back to #2) In short: this will improve the accuracy of a chart. Firekorn's suggestion of automatically toggling crazy status on a chord after a rest is also viable, though that still leaves us with chord boxes that are 1ms long.
  19. You probably have the "Adjust notes/beats" option enabled in the leading silence window, whereas before you disabled it. Anyway, it's better this way. No need to shift notes around if you're importing from a gp file. Also with regards to vocals, you can just go to track_vocals, press ctrl+a to select everything, and then move everything 3 seconds. The Marks (blue lines) that denotes where a line starts and ends does not move with it, so you'll have to remark them (shortcut: ctrl+m). Also remember: LYRIC SUSTAIN. Keep that spacebar pressed for however long that syllable is sung. http://customsforge.com/topic/11210-lyric-tutorial/
  20. It's fine if the first beat starts at 3 seconds. Rocksmith 2014 jumps to a few seconds before the first beat marker, so 3 seconds of silence works just fine. Also, of course the original.mp3 won't have the leading silence. It's the original. You need to convert the .wav file that eof generated to a .wem file (using wwise directly or using the toolkit) for use.
  21. Sigh... I don't know what you did, but my previous tone error is back (latest version, 9312319f): http://puu.sh/i4QGy/ed8971b15f.png How it's set up in EoF: http://puu.sh/i4QHP/d078312cdb.png XML file before generating package: http://puu.sh/i4QKp/bfee0e8f93.png XML after trying to generate package: http://puu.sh/i4QN1/e8e89524b5.png The fix would probably be to change the name of "clean" and "distortion" in <tone time...> to reflect the names as defined in tonebase/tonea/toneb etc. After I did that manually, the package generated without errors.
  22. It's in the song properties window (shortcut: F9): http://puu.sh/hYW1e/6285b92312.png It's enabled automatically for new projects.
×
×
  • 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