map independent filter setting request

[redhardsupra]

I love the filter function, but I don't want it to be either on ar off for ALL my maps. For example, I like to have a map of dynairflow, ben, and knock loaded up at the same time. The problem is that while the filters are great for the first two, I don't want the filter applied to the knock map, as it's in the transitions where the knock frequently occurs, so I wanna know where the trouble areas are. Now, when I'm switching between maps, I gotta hit the filter button off every time I go to take a look at the knock map.
Hopefully I'm not being a dumbass and overlooking some setting where I can do that already :/
thanks,
Marcin

[ringram]

Good idea, like part of saving the map is to also save the filter that applies to the map. Should be an easy change... well maybe.

I suspect Paul will put it on the list of to do's after the v2 release.

[SSpdDmon]

Why not just do spark before/after fueling? It takes just a few seconds to turn the filter on/off. What's the big rush?

[redhardsupra]

i'm not setting anything yet, just going through a large set of data that's been dumped on me from a slightly detuned car. so i need an easy way (as in not click a lot of buttons for each and every log separately) to go through logs, and click through few predefined views for each of them, to see if everything is consistant and try to see patterns throughout the logs. i should be able to have a full set of maps and their settings (including filter-map tuple) that i do not need to alter every time i try to run through the various views.

[TAQuickness]

sounds like a reasonable request. To add to it, would be cool to have a map that displays instantaneous data as well.

[SSpdDmon]

The reason why I was asking is I don't know if it will be that easy of an upgrade. I believe the filters work by excluding the raw data that you don't want to see. So if you had these huge logs you're going through with multiple unique map filters, each map would essentially need its own copy of the log to exclude the data from for that map. Then, each time you load a new log, you'd have to filter each map individually and it would end up taking longer than if you just used 2 sepearte filters for spark and fuel like you would do now....unless someone comes up with a new way of doing it (or I'm completely full of it, talking out my @$$ and way off base - which is entirely possible).

[ringram]

You are right each filter change forces a reread of the log data.
So I guess a large log with lots of maps will need a nice dual core athlon to chew on. Still the default can be to save maps with no filter. Either way opening a map forces it to read the data anyway, so its not that much of an issue.

[TAQuickness]

not 100% certain, but i believe you can open two instances of the scan tool and run two seperate filters. Not sure if that would help your scenario though RHS

[redhardsupra]

sspddmon is right, once we combine map/filters, they will all have to use a separate and different tables for data storage, so we have up to 10 times the memory used (one data table per each map vs one data table for all of them).
the good part is that when you change the filter on one map, that's the only map that has to be recalculated, not all of them. so it's a tradeoff of space for speed, with an added bonus of extra functionality
if we wanna be really nice, we could spawn some extra threads in the background updating the other tables if there's any updates there, while we're oogling the newly recalculated map.

[redhardsupra]

well, actually, we could just attach an extra column to each piece of data with a list of numbers of maps that this filter is on/off for. then you get to store one table, just with one extra column, and compares are really quick. this would however not be as flexible, as then the number would be connected to a button slot, not an actual map, so if someone switched maps in a given slot, the filter would still apply (or not) regardless of what map is loaded. hmm...screw it, we got plenty of memory