Skip to content
Snippets Groups Projects
  • Ryan Maloney's avatar
    58c8797d
    Saving Parameters · 58c8797d
    Ryan Maloney authored
    Uses the parameters array to create XML data for parameter settings on
    each channel when saving.
    
    This only works for processors that use the parameters array, though I
    updated LFP and Signal Generator to update that in parallel (LFP seems
    to have an unrelated bug in dealing with channels that is causing some
    problems). Eventually, all parameters should be used in the parameters
    array, since it opens up a lot of possible holes when using default
    values (they need to be specified twice), and once loading is
    implemented. I've fixed some of the problems with parameters, so this
    should be easier to do.
    
    As part of this, I also fixed the implementation of
    addParameterEditors. The old way of implementing a custom parameter
    editor was to rewrite the virtual function, but because it was called
    in the constructor, this didn't work (constructors use the type of the
    parent). Instead, all editors now also pass a bool
    "useDefaultParameterEditors" which is used by addParameterEditors() to
    determine whether to do anything. I think this is the best way to do
    it. It's initialized to default as true, though I had some trouble with
    it implicitly taking the argument and so had to add true to most of the
    editor functions (which is probably good practice anyway).
    
    I also fixed some of the functions for generic processor to get
    parameter index and parameter name.
    
    Obviously, this is of considerable less use without functions for
    loading parameters, but I figured it'd be better to make available for
    testing with just the loading in case the changes to Parameters broke
    anything I missed.
    58c8797d
    History
    Saving Parameters
    Ryan Maloney authored
    Uses the parameters array to create XML data for parameter settings on
    each channel when saving.
    
    This only works for processors that use the parameters array, though I
    updated LFP and Signal Generator to update that in parallel (LFP seems
    to have an unrelated bug in dealing with channels that is causing some
    problems). Eventually, all parameters should be used in the parameters
    array, since it opens up a lot of possible holes when using default
    values (they need to be specified twice), and once loading is
    implemented. I've fixed some of the problems with parameters, so this
    should be easier to do.
    
    As part of this, I also fixed the implementation of
    addParameterEditors. The old way of implementing a custom parameter
    editor was to rewrite the virtual function, but because it was called
    in the constructor, this didn't work (constructors use the type of the
    parent). Instead, all editors now also pass a bool
    "useDefaultParameterEditors" which is used by addParameterEditors() to
    determine whether to do anything. I think this is the best way to do
    it. It's initialized to default as true, though I had some trouble with
    it implicitly taking the argument and so had to add true to most of the
    editor functions (which is probably good practice anyway).
    
    I also fixed some of the functions for generic processor to get
    parameter index and parameter name.
    
    Obviously, this is of considerable less use without functions for
    loading parameters, but I figured it'd be better to make available for
    testing with just the loading in case the changes to Parameters broke
    anything I missed.