theboxybear / charttools Goto Github PK

If a sustain on a non-open note goes past an open note, cut it up to the open note. With that same logic, a sustain on an open note should be cut on the next non-open note. In its current state, extended sustains are also not being considered.

Replace UniqueList, UniqueListEquatable and UniqueTrackObjectCollection with List<>. This would allow track objects to have their position changed without creating new instances and heavily improve performance on collection edits.

To check for duplicates when reading and writing files, I added the DuplicateTrackObjectPolicy property to ReadingConfiguration and WritingConfiguration. If the policy if set to IncludeAll, no duplicate checks are made. Otherwise, only include the first object or throw an exception depending on the policy.

As for the exception type, it would just be Exception for now until I can think of something better (potentially a custom exception?)

Once done, apply ObsoleteAttribute to UniqueList, UniqueListEquatable and UniqueTrackObjectCollection

Animation events drive the musician models in games with a 3D background. Since they are shared between instrument variants, they should be stored outside of instruments, on the same level as Song.

In order to reduce the size of XML documentation, <inheritdoc> is used for method overloads. However, roslyn triggers false positives of CS1591 as it does not detect the inherited parameter documentation. This has been notified to the roslyn team and is in the backlog

In the meantine, parameters are inherited individually using XPath.

Create an overload which takes a resolution and does more complex logic to find tick positions for anchors before finding which tempo markers to remove. If the existing method without a resolution is called with a collection containing anchors, throw an exception pointing to the right overload.

With the addition of covariant return types, tracks no longer have a setter, thus must be initialised and passed as a reference instead of generated and returned by the parser.

This is a result of the new vocals as an instrument implementation. Syllables are creates with the default pitch so NoteCollection considers every syllable past the first as duplicates and ignores them.

• #45
• #46
• #47
• #48
• #49

AddRange goes through all items once for every item added to remove duplicates. Should go through the items once and remove all duplicates at once.

Once added to C#, review parameters with a backing field and replace the field with the "field" keyword. Unless additional processing is made, replace getters and setters with the auto equivalent.

Parsing and serializing of MIDI is strongly tied with the contents of the ini file. In order to resolve this and make sure both are done correctly according to the ini, a new class would be created to store these rules defined by the charter and specific to the song.

To do:

• #39
• #40
• #36
• #34
• #37
• #38
• #42
• #35
• #41
• #43

Once added to C#, parameters should be defined as paramName!! instead of checking for null and throwing ArgumentNullException.

In order to support .NET 5 and 6, code should be unified to work with both framework so that it can be merged without issues.

• Despite .NET 6 allowing for a simplified namespace declaration, the old syntax should still be used
• Do not remove using directives, as some are needed in .NET 5 but not 6
• FirstOrDefault and Min/MaxBy in Extensions.cs should be kept and marked with the NET preprocessor directive as to only be compiled if running .NET 5

In order to avoid property bloat in the Song class, instruments would be grouped in a InstrumentSet class and animations in AnimationSet. They are to be one of each as properties in the Song class, both gettable and settable.

This would give more purpose to the extra methods using the enum and guarantee compliance, allowing the use of LINQ on a NoteCollection using the enum instead of the note object.

Create a parser for the Guitar Hero 1/2 chunk

In order to broaden compatibility with Rock Band and Guitar Hero, vocals will be added as an instrument.

The Phrase class will be modified to become a chord and Syllable to be a note.

Hello!

I stumbled upon this library as I had an idea for creating a tool to convert CloneHero charts into xLights sequences.

I had planned on parsing the chart files with javascript. But when I saw your library, it appears way more robust than anything I would have built.

I am not familiar with .NET code, but I suspect I wouldnt need to write a lot of it given that it seems like a lot of the processing legwork is done with this library. But maybe I am mistaken?

Initially, as a proof of concept, I would like to convert a set of notes (eg. Guitar) into XML (readable by xlights) that looks like something like this:

    <Element type="model" name="Key 1">
      <EffectLayer>
        <Effect ref="0" name="On" startTime="0" endTime="1000" palette="Green"/>
    </Element>
    <Element type="model" name="Key 2">
      <EffectLayer>
        <Effect ref="0" name="On" startTime="1000" endTime="2000" palette="Red"/>
    </Element>

(In the example output provided above, assume the provided CloneHero Chart would have a guitar green note at zero seconds, red note at 1 second, each lasting 1 second).

So my question. Is there a particular function or class within this library that would give me access to some of these values that could generate an XML output similar to what is show above?

Thank you in advance for any information or help you might be able to provide!

• #58
• #59

The new way of reading and parsing chart would involve the main thread reading lines from the file and has it encounters a part header, creates a parser object running on a separate thread. As lines are read, they are added to a buffer inside the parser until the end of the part is encountered, at which point it stops adding to the buffer, waits for the next part and creates a new parser. There would be different parser classes for the various types of objects to parse and the right type would be chosen based on the name of the part. For the track parser, it would store the difficulty and instrument it is for.

After reading the file, the main thread would await all the parsers it created and add their results to the song object. This approach offers several advantages:

• Faster execution from the reading happening simultaneously with the parsing
• Less concurrent memory usage as the file is never in memory in its entirety
• Smaller impact on the threadpool from less concurrent threads. Threads are only created for the parts that are present and only when the part is encountered, likely after previous parts are done being parsed.

All classes with FromFile or ToFile methods should have one with a configuration parameter and another without which uses the default as specified in the parser class (ie ChartParser.DefaultReadConfig)

Track needs FromFile and ToFile overloads that use the default configuration.

As discussed with mdsitton, several improvements to parsing could be implemented to reduce execution time.

One of the slowdowns comes from the use of a custom FirstOrDefault to find the parent chord of a note or tempo marker for an anchor. Replacing it with binary search would be significally faster than regular enumeration but requires the track objects be in order of position. Clone Hero handles this by giving an error if not in order but in order to respect ChartTool's mission of flexibility with any data for the sake of fixing, it would still need to be able to parse files with out of order track objects. A middle ground would be a property in the configuration to indicate wether to use the fast parse with binary search or slow parse that accepts out of order track objects. A potential third option would try to parse with binary search and if it fails because of out of order track objects, automatically tries again using the slow method.

Another source of slowdowns comes from UniqueTrackObjectCollection which enumerates through all its items in the search of duplicate positions every time an item is added. The eventual fix would be the retirement of such class in favor of the built-in generic list. In order to compensate for the removal of the safety net created by UniqueTrackObjectCollection, the DuplicateTrackObjectPolicy from configuration would be expanded to be used by tracks when reading and writing files.

inheritdoc doesn't pull doc from ChartParser.ReplaceImstrument. Could be an issue with the parameters containing a tuple.