Latest EOF releases (9-26-2020)

[BHMath]

Is there anywhere a post explaining all this new thing appeared to EoF with handshape, ghost note etc. ?

 

Because I'm reading all your comment and I'm excited by this features but if I don't understand how they work I will be disapointed.

[SmellsLikeMonkey]

Is there anywhere a post explaining all this new thing appeared to EoF with handshape, ghost note etc. ?

 

Because I'm reading all your comment and I'm excited by this features but if I don't understand how they work I will be disapointed.

Here's a post:

 

http://customsforge.com/topic/22596-handshapearpeggio-for-multiple-notes-at-a-time/page-2?hl=ghost+handshape&do=findComment&comment=183033

 

It's really simple. En earlier versions of EOF, you could not define the fingering on ghost notes. Now, in the note menu, you can mark a chord with "ghost handshape" and add ghost notes that are not shown in RS but allow you to define the full fingering. The name of the chord is associated only on touched notes, but you can edit this manually

[albatross213]

@@raynebc - I can see why it might not be simple to reverse engineer the EoF stuff from the XML stuff for chords, given that there are a ton of possible exceptions. It would be great if chord-wide techniques (especially palm mutes and slides) could import correctly, but I can manage without that.

 

Another thing I forgot to mention is that it also seems that the time signatures didn't get imported. Is there a chance that could change?

 

 

Anyway, regarding the FHP copying over thing, I actually came up with a good example of one for which FHP copying would be hugely helpful. This is from Symphony X - Nevermore (which I made before I started caring at all about FHP).

 

Riff 1 with auto-generated FHP, vs. Riff 1 with desired FHP. This riff repeats 8 times on all paths (guitar is slightly different from bass). Each time through I have to remove 3 FHP and add 4 (two of which are offbeat, and annoying to navigate to. Is there a better way than clicking on a neighboring note, then going to the next/previous?). Repeat 24 times and it gets quite annoying.

 

Riff 2 with auto-generated FHP vs. Riff 2 with desired FHP. This riff (or a variation of it on lead guitar) repeats 4 times on bass, 6 times on both guitar paths. Each time through the riff I have to remove 3 FHP and add 6 (because of the time signature, at least they're all on beats!). Again, repeating this ritual 16 times would become quite a drag.

 

 

Lastly, with regards to the possibility of this leading to bad things in FHP, exactly what types of things are you imagining? If there's not an FHP at the start of what you're copying and you paste it somewhere else, then yeah, there's a chance you'll be below the pre-existing FHP, or well above it and stretch it out. The first case will be caught when you save, and the latter I'd expect most people who care enough to edit FHP to catch whether in EoF or in testing. I don't think it would be that big of a problem.

[firekorn]

Since you can generate on a partial part of the chart, you could easily avoid all the deleting FHP part of the process right now which is basically half of the time it takes you today.

 

I'm not against the idea but i just feel like it's a cute function that maybe 2/3 charter will actually have a good benefit from it and that does not include me. I can also find exemple where it could have been a bit useful, but that would represent maybe 2 customs over the 70 i've made... Is it really worth it? That's for raynebc to judge.

[albatross213]

@@firekorn - If I remove FHP from those riffs, then I have to place 6 FHP per time for riff 1 and 8 FHP per repeat with riff 2. I don't see that improving the calculus much, especially since removing FHP (for these riffs, Ctrl+Shift+F, remove those with FHP of 3, click Done) can often be done much faster than adding FHP (navigate to note position, Shift+F, enter fret number). I'd say that at least in this song the auto-generated FHP does enough right to make it useful to start with that as a base.

 

And yeah, it won't provide much utility for most songs and for most charters, so it shouldn't be among raynebc's highest priorities. But for that matter, how many people do you expect to really use the ghost handshape capabilities (to start: how many charters actually use handshapes?)? I haven't personally seen many instances in my charting where I've thought I needed a function like that (maybe one song I can think of off the top of my head), but I haven't been arguing against its inclusion as a feature either, since other people have made the case that it would be quite useful for them and it wouldn't adversely affect anything I do.

[Chlipouni]

Hi raynebc,

 

  I am using the [handShape][Mark] functionality in EOF and I have a few questions about it :

  - to create the handShape, we select the starting event and the ending event.

  - if the handShape needs to start before the first event and/or to finish after the endding event, we have to add ghost notes to mark the handShape. Is it the right way ?

  - to avoid the creation of too many ghost notes for the handShape feature, it would be nice to have the ability to set two optional parameters (for each handShape) like :

    - start before (in ms) for the starting event

    - start after (in ms) for the ending event

    These values could be used to calculate the starting and ending positions of the handShape

    With a negative value, the meaning could be change regarding the selecting event

    My ultimate goal would be to use the same event as the ending of a handShape and the starting of an another one.

 

Thank you

[firekorn]

@@albatross213 The thing about handshape is that it was impossible to display some element the same  official DLC did without getting your hand in the XML file while the FHP position included in the copy fonction is just a small improvement over something already working well.

 

I'm not saying i'm against it (every improvement for making charter work a bit less tedious can be interesting), i'm just saying it doesn't seems to be worth the hasle in my own little point of view and situation :)

 

@@Chlipouni The ending event might just be the end of a sustain too so the ending event is not always on a note but for the starting point it will always be on a note event

 

But i like your idea which would allow smooth handshape transition. Not sure how useful it would be though as i would have propably used it once or twice.

[raynebc]

Another thing I forgot to mention is that it also seems that the time signatures didn't get imported. Is there a chance that could change?

Rocksmith XML files do not formally define time signatures. At most they define the number of beats in a measure, but that's only half the signature.

 

I am using the [handShape][Mark] functionality in EOF and I have a few questions about it...

You should be able to just temporarily add a note or a ghost note to define the start position of the phrase, and a tail or a new note to mark the end position, and then just clean up or remove the notes/tails after you mark the handshape. This should make it easy enough to position the handshapes exactly as desired. The suggested system for defining timestamps for the separation points for handshapes is very different from how EOF handles them, so I'd prefer not to implement something like that. Additionally, I know handshapes can overlap completely, but I don't know if there would be any strange or unwanted in-game behavior from having a handshape start at the same millisecond as another ended.

 

There's a dialog I'd created for the fret catalog that allowed the start and end timestamps for the currently displayed entry could be changed, and I could make that available for handshape/arpeggio phrases pretty easily. I can't imagine it would be a very heavily used feature, but it would allow some insanely fine control over timing. Does anybody think that would be useful?

 

As for whether FHPs copy/paste with notes, I could probably make it a user preference, but I'd probably make it off by default.

[Chlipouni]

Thank you very much for the advice of removing the note used to mark the handShape  ;)

[albatross213]

@@firekorn - I think that's an unfair standard to hold suggestions to at this point. The game has been out for over 2 years now, and we've had an active charting community (from what I can tell from the past 8 months, and judging by this thread's 67 pages), and @@raynebc has come up with solutions for almost every topic proposed. Thus, you'd expect that pretty much everything that is both helpful to many people and not impossible to solve to be implemented already.

 

My point with the handshape stuff was that it also won't affect too many people's charts. I realize that it's a novel thing that has been used in some official charts, but the fact that it took almost two years (I think? Not sure when it first was discussed) and however many customs to be brought up and addressed says a lot about how many people will find it useful. And as you noted, the same could be said of my suggestion.

 

Another factor to consider is that most of the changes implemented at this stage of the life cycle won't be incorporated into improving existing charts, as a lot of customs get abandoned by their creators. This includes many (but not all) of the most downloaded customs. Doesn't mean we shouldn't still try to improve the tools, but it is a bit of a shame.

 

 

@@raynebc - That will work for me for FHP. Thanks!

 

Also, odd about the time signatures. I didn't realize the .xmls were like that. If I understand correctly you're saying that to decide whether a measure is actually 7/4 or 7/8 you'd have to make a guess about whether the tempo has changed?

[raynebc]

The measure numbering in the XML files goes like this:

    <ebeat time="0.000" measure="1"/>
    <ebeat time="0.500" measure="-1"/>
    <ebeat time="1.000" measure="-1"/>
    <ebeat time="1.500" measure="-1"/>
    <ebeat time="2.000" measure="2"/>

So the time signature numerator is made obvious, but the denominator (beat unit) is anyone's guess. If the beat unit changed, the distance between one beat and the next might change significantly, but it doesn't have to if there is also a tempo change on that beat. If the time signature doesn't change at all, there's even less variation to look at. Either way, EOF would only be able to guess.

[firekorn]

@@albatross213 Well i'm sure i've waited some time before seing some of those handshape improvement, damn even the handshape tag took some time to show up in EOF and it was really beneficial to chart clarity when it did. I can also think about one suggestion i've made about FHP and tapping section that is not yet implemented to avoid deleting a bunch of FHP and make any new chart look better. 

 

I'm confident everything will be perfect one day as Raynebc do an impressive job so far that i'm sure many of us won't be able to thank him enough for everything he did so far and will do in the futur :D

 

 

 

Another factor to consider is that most of the changes implemented at this stage of the life cycle won't be incorporated into improving existing charts, as a lot of customs get abandoned by their creators. This includes many (but not all) of the most downloaded customs. Doesn't mean we shouldn't still try to improve the tools, but it is a bit of a shame.

 

That's sadly very true but i'm sure that i'll redo my old chart and that they will all greatly benefit from those improvement and it sure doesn't mean the tool should stop evolving.

 

But i'm gonna repeat myself here, I won't benefit from the FHP being copied with the way i work. If Raynebc is confident about making it possible and can make it an option, then sure, i'm all for it. It just won't change anything for me at all :)

[Chlipouni]

So the time signature numerator is made obvious, but the denominator (beat unit) is anyone's guess. If the beat unit changed, the distance between one beat and the next might change significantly, but it doesn't have to if there is also a tempo change on that beat. If the time signature doesn't change at all, there's even less variation to look at. Either way, EOF would only be able to guess.

 

  I aleady thought to add specific attributes in the XML file, only for our tools.

  We could add an attribute on each main measure to define the complete time signature.

  These attributes should have a naming rule to distinguish them from the original ones.

 

  With the magic of XML, RSToolkit and DDC keep these specific attributes without error.

[raynebc]

That would be fine with me, although I'd been keeping the XML about as close to official chart formatting as possible.  Would the other toolkit developers be OK with EOF defining new ebeat tag attributes (perhaps called "numerator" and "denominator") for this purpose?

[Alex360]

@@raynebc, @@Chlipouni, give me example song with odd TS so I could analyze it's sng, maybe there's way to encode "full" TS or we could do our tag for xmls only

[Chlipouni]

If the specific XML attributes are allowed by the RSToolkit Dev Team, I suggest to use namespaces to distinguish clearly the official nodes and attributes to those added by us.

 

As an example :

<?xml version="1.0" encoding="utf-8"?>
<song xmlns:eof="eof" xmlns:ddc="ddc" version="7">
  ...
    <ebeats count="593">
    <ebeat time="0.000" measure="1" eof:numerator="4" eof:denominator="4" />
    <ebeat time="0.537" measure="-1" />
    <ebeat time="1.074" measure="-1" />
    <ebeat time="1.611" measure="-1" />
    <ebeat time="2.147" measure="2" eof:numerator="4" eof:denominator="4" />
    <ebeat time="2.684" measure="-1" />
    <ebeat time="3.221" measure="-1" />
    <ebeat time="3.758" measure="-1" />
  ...
</song> 

 @@Alex360, the "version" attribute in the "song" element has already been added for the Toolkit usage, isn't it ?

 What do you think about using a "rst" XML namespace for it ?

 

 For now, the tools seem to work fine with these new attributes (even if they don't use it).

 As expected, only the unpack CDLC in "SNG to XML" mode don't generate again these new attributes (works fine without "SNG to XML" checked).

 

 EDIT : @@raynebc, I would prefer an explicit attrribute like the following one to define the time signature :

<ebeat time="2.147" measure="2" eof:timeSignature="4/4"/> 

Thank you

[Alex360]

@@Chlipouni
 

 

the "version" attribute in the "song" element has already been added for the Toolkit usage, isn't it ?

Nope, version tag met in rs2014 lessons xml so we used it for ourselves too

Is there less ":" way of doing attribs magic? :D

[albatross213]

give me example song with odd TS so I could analyze it's sng, maybe there's way to encode "full" TS or we could do our tag for xmls only

Do you mean an official song or a custom song? If customs are OK, any of The Dance of Eternity, Synaptic Plasticity, or E.E.G. Tracings  (which I could also get you source files for), would be extreme tests. Dream Theater, Symphony X, and Between the Buried and Me would be bands who reliably switch time signatures in their songs.

[Alex360]

@@albatross213, I guess there is no Officials with those unique TS

EDIT
we could use events to keed your custom TS alive tho

Edited December 9, 2015 by Alex360
bright idea

[Chlipouni]

we could use events to keed your custom TS alive tho

 

 I agree with that idea.

 Use of events would be less verbose because we can define the time signature only when it changes.

[raynebc]

Maybe something along the lines of:

Edit: Regarding copy/paste FHPs, the easiest way for me to implement this would be to only copy FHPs that were at the same timestamps as notes that were pasted. Do many people place fret hand positions at positions that don't have notes?

[PC Plum]

Totally off recent topic, but presumably 12-02-2015 (or since the last time I tried new ones) has went back to defining slides by the fattest string?

[raynebc]

I didn't make any changes to how slide end positions are interpreted. EOF's handling of that information should still be as described here:

http://customsforge.com/topic/1529-latest-eof-releases-12-2-2015/page-60?p=175697&do=findComment&comment=175697

[albatross213]

Got a new error to investigate for you, @@raynebc. The relevant files are in the folder here, and I hope it has what you need.

 

The basic gist of it is that what were supposed to be triplet eights got imported (from the "(Pro)" GP file) as triplet 16ths, as can be seen at measure 35 of "badnotes.eof". I looked at the tab and noticed there was a repeat there, so I "unpacked" that repeat (and eventually) all others to generate the "(Edited)" GP file, and imported that to generate "goodnotes.eof", where everything is as it should be.

 

Looking at the original tab, I see that in the measure after the troublesome repeats there was a time signature change to 11/8. Is it possible that EoF picked up on the time signature change before it was supposed to (at the end of the first repeat, rather than at the end of the repeats), and adjusted something that it shouldn't have, relating to either note spacing or beat spacing?

[PC Plum]

I was looking and realised I meant unpitched slides.  That looks like its still on thickest string?