Skip to content

Conversation

paulfd
Copy link
Member

@paulfd paulfd commented Apr 6, 2020

Missing:

  • Tests as much as possible
  • Compare step behavior to ARIA and others for e.g. the number of steps and the steps for volume or other multiplicative envelopes.

Closes #155 #77

@paulfd paulfd linked an issue Apr 6, 2020 that may be closed by this pull request
3 tasks
@paulfd
Copy link
Member Author

paulfd commented Apr 6, 2020

Ok should be good now! At least from a behavior pov :)

@paulfd paulfd requested a review from jpcima April 6, 2020 20:46
@paulfd paulfd linked an issue Apr 6, 2020 that may be closed by this pull request
@paulfd paulfd mentioned this pull request Apr 7, 2020
@paulfd paulfd changed the title [WIP] Add support for curvecc and stepcc Add support for curvecc and stepcc Apr 7, 2020
@jpcima
Copy link
Collaborator

jpcima commented Apr 13, 2020

one remark: round is certainly desired over trunc for our case

The performance of various rounding functions depends wildly on processor, flags, compiler.
lrint may compile more efficiently on the x86. It uses the current rounding direction.
(which can be set globally at the start of the processing method and restored)

@paulfd
Copy link
Member Author

paulfd commented Apr 13, 2020

You mean here:

    auto quantize = [step](float value) -> float {
        return std::floor(value / step) * step;
    };

and here:

    auto quantize = [logStep](float value) -> float {
        if (value > 1)
            return std::exp(logStep * std::floor(std::log(value) / logStep));
        else
            return std::exp(logStep * std::ceil(std::log(value) / logStep));
    };

?

Can you expand a little bit? I used to have round there but it seemed from the tests I made with sforzando that trunc-type behavior was a bit more precise. I wonder if the first one should be trunc actually, so that the behavior is kept for negative values.

The tests I've tried to do with Sforzando showed that when you have steps, there is one last "step" exactly at the edge of the value range (for CC this would be at 1.0/127, for pitch bends at +/- 8192, ...). This is what led me to the trunc.

lrint could be nice though, I did not know this function, thanks.

@jpcima
Copy link
Collaborator

jpcima commented Apr 13, 2020

This was a remark regarding 3f54a82 titled "Use round rather than trunc; more stable.."
only on topic of performance, and nothing to do with sforzando or the precision

@paulfd
Copy link
Member Author

paulfd commented Apr 14, 2020

I completely messed up the steps actually, I don't know why I treated it as a number of steps but it's actually a step size. Now this matches ARIA's behavior on all envelope types:

  • trunc on the steps on linear envelopes such as amplitude
  • round on the pitch bend envelopes (which avoids most of the practical weirdness when using the pitch bend)
  • trunc on all other multiplicative envelopes

I need to update the tests to match all behavior, and maybe add a couple to check the fine print, or assume that larger-scale tests should check for these.

@paulfd paulfd merged commit 1feb073 into sfztools:develop Apr 14, 2020
@paulfd paulfd deleted the curvecc-stepcc branch April 14, 2020 21:52
essej pushed a commit to essej/sfizz that referenced this pull request Sep 23, 2023
* Issues:   Update bug_report.yml to include an example unit test (sfztools#166)

* Benchmarks:   Added a benchmark for looping ContainerClips

* CombiningNode:   Improved the speed of CombingNode::addInput, particularly with large numbers of clips, by using std::partition

* TempoSequence:   Fixed updating sequences multiple times

* Time:   Added some functions to EditTime & EditTimeRange

* CombiningNode:   Fixed an issue where nodes could be processed without being prepared

* Container Clip:   Refactored to flatten contained clips in to the main Edit. Has some limitations at the moment

* Node:   Made createNodeMap recursive to find nested internal Nodes

* ContainerClip:   Make sure each WaveNode gets a unique ID

* Tests:   Added UBsan to macOS tests

* ContainerClip:   Started adding dynamic offset to WaveNodeRealTime

* ContainerClip:   Started adding support for USE_DYNAMIC_OFFSET_CONTAINER_CLIP (to avoid flattening container clips)

* Container Clip:   Fixed dynamic offset for changing graphs and non-zero loop starts

* Container Clip:   Added a DynamicallyOffsettableNodeBase class and used this to support contained clip fades

* Container Clip:   Avoided hiding DynamicallyOffsettableNodeBase functions

* Container Clip:   Fixed compiler errors

* Container Clip:   Fixed some namespace conflicts

* Container Clip:   Added processing of looped ranges

* Container Clip:   Ensure offset change triggers a wave crossfade

* ContainerClip:   Avoided clicks introduced by chunking loop boundaries

* ContainerClip:   Fixed slightly incorrect loop point by using a local ProcessState

* ContainerClip:   Removed an unused variable

* Container Clip:   Added some tests

* Container Clip:   Worked around a Windows warning

* Container Clip:   Commented out a line that will be eventually removed

* Utils:   Improved createGraphDescription to remove duplicate edges and include Nodes that use memory

* Player:   Added a check for cycles in a graph to prepareToPlay

* Container Clip:   Avoided processing 0 samples

* ContainerClip:   Removed the flattening implementation

* Nodes:   Fixed a potential memory corruption caused by claiming incorrect nodes

* ContainerClip:   Added an additional assertion
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for stepcc and curvecc Controller curves
2 participants