Lua - Currently Selected Filter

BECOME PART OF THE COMMUNITY - Sign up here
  • I'm struggling to work out how to (if possible) get the currently selected Filter (from the pool) via Lua.


    The AtFilter of the Userprofile is just blank in the tree, and not sure if FiltersDataObject is what I should be messing with?


    Many thanks to any help as always.

  • Select Filter 2 ; SaveShow ; Reboot

    -> no filter is selected


    my conclusion:

    Last selected filter is transitory and not persistent.

    If this information had existed anywhere in the object-tree it would have survived the reboot.


    Depending on why you want to know the last selected filter, this approach could possibly find it for you:

    Code
    local needle = CurrentProfile().AtFilter
    local haystack = DataPool().Filters:Children()
    for i=1, #haystack do 
      if needle.Attributes == haystack[i].Attributes then 
        Echo(haystack[i].Name)
      end
    end
  • local needle = CurrentProfile().AtFilter local haystack = DataPool().Filters:Children() for i=1, #haystack do if needle.Attributes == haystack[i].Attributes then Echo(haystack[i].Name) end end

    Andreas unfortunately this doesn’t seem to work as expected. It is returning the full list of filters each time.

    Is Attributes the right child to be matching? It seems that it’s maybe seeing the same attributes existing rather than being selected?


    On inspection it appears .Attributes is returning nil and therefore it’s always a match, hence returning the names of all the Haystack

    Edited once, last by Clintos ().

  • You're right, this doesn't work as expected.


    from commandline-list perspective Attributes looks like a property, however from xml-export perspective Attributes looks like a child with subchildren


    I don't know if and how such a hybrid structure can be accessed with the Lua API.

  • At moment there is no permanently selected filter, like Select Filter x was doing in grandMA2.

    Selecting a filter in grandMA3 applies the filter at moment to the command filter/At filter (however you want to call it). The command filter is always reset to filter 1 after store/update, etc.

    The current behavior can be compared with grandMA2 where you had filter 1 permanently selected and then called a different filter for the next operation as command filter.

    The command filter in grandMA3 knows only which attributes are active/not active.


    I agree that the current behavior is not the best, and hopefully gets improved in the future. I only wanted to explain how it works at moment.

  • Thanks for the rundown. Whilst I did know this it’s great to have the explanation all written out here.


    The console does know when the pool filter is ‘matched’ to the active filter settings given if places the yellow box, but unfortunately not possible to tap into this now.


    But we will see an improvement here in the next version :)