d1manson / waveform Goto Github PK

This won't be super-easy to do, but with a little bit of work in the file-organiser and some basic copy-paste-modify of a few functions in parsed-data it may not be too tricky.

Oh, except we suddenly do need to care about sampling rates, where previously we have been able to ignore the possibility of bugs due to mismatched timebases.

I guess there's also the question of continuous recordings..I'm not sure at what point detected spikes are separated from the rest of the data.

I have seen on skype, but not been able to reproduce the following bug:

When tetrode 7 is selected, the files for tetrode 8 of the first trial are incorrectly rendered as selected rather than than those of tet 7.

Perhaps this has something to do with having a very long list of trials.

There is also a bug where the active cut is not shown as being active. This is due to _reassign_trials_denovo (which is called when user does multiple file drops into page and when a drop includes orphaned cut files). This affects both last_used_cut for each tet_obj and selected_cut. This is definitely worth fixing.

You could do this in a variety of ways, but you might want to be able to bundle spike times with xy and dir, say.

You could support a "shopping cart" or multi-select (like a photo gallery mobile app) type arrangement...so you could combine a variety of cells, perhaps across trials/tets even. This would also allow for async operations because there would be one action to request the data and another to drag it out.

Note that currently there is the Utils.array_to_csv function on the console, which can provide some of what might be wanted from this feature.

With the latest version, it's easy to detect when there is a pair of groups active rather than a single group - just observe active_group_a and active_group_b. The tac-plots could thus generate the cross-corr, and if we do spatial-corr's, then we could provide a spatial cross-corr too.

You could display this either in the tiles or with the path data on the left. The latter option is possibly easier to implement and extend as new features are added, but does have it's own issues in terms of what to do with the path resizing.

Need to store the action list and current cut when changing cut files or experiments so that when users comes back they can carry on where they left off.

Trying to drag works once, but breaks everything.
A temporary fix would be to just disable the problematic animation..

The contents of <script is='worker-builder' ... is no longer being found, which means the workers strings no longer have the expected content.

It would be useful if we could have an option to arrange the files by date especially when you have recording over several months...

It hasn't been released yet, but a preview branch is available on the main Polymer repo.

Since everyone is getting into optogenetics, it might be nice to have some support for stimulus-aligned rasters (or whatever it is people use).

I'm sure whether the stimulus settings are general enough as to be able to do this, or whether you would need to give the user a fairly detailed interface for customizing the interpretation of the stimulus data. I guess you could in principle execute a user-written function, but that's perhaps not necessarily much easier than building a complex dialog pane.

Dear Dan,

I find your GUI absolutly handy and I am totally relying on it now. One thing that toubles me a bit is that when I have several clusters stucking close together I cannot really see which is which. TINT solves this by offering highlighting for each cluster so I am going though TINT everytime for double check. So I am wondering whether you think it is worth to add a cluster highlighting function to make it easier for checking cluster space of each cell.

Many thanks and best wishes,
Yi

With right click you should be able to drop and move a ruler around on the rm.

Ideally it would be nice to support having multiple rules on a single map and on multiple maps. And To support rules during and after grabbing a tile. Could also do angle measurements and perhaps even provide a grid of some kind that can be resized, rotated and even warped.

Currently if the new experiment doesn't have a given data file, the data from the previously active experiment remains, which doesn't make any sense.

Want waveforms, clusters and ratemaps to work with a temporal mask. Then implement a number of masks:

• slider/textbox for defining a section of the trial.
• slider/textbox for defining a range of valid speeds
• dial/textbox for defining a range of valid directions
• and more...?

This could either be done as part of the mouse-over, or perhaps as an additional type of ratemap rendered for all groups.

The rm-plots code is already rather long, but it has enough asynchronicity built into its design to support more compute-intensive tasks such as gridness calculation.

• When a large number of groups are rendered some do not appear, probably an issue with the paging of rendering.
• When rendered waveforms are copied from the off-screen buffer to the individual canvases they take a bit too much with them.

Really fast rendering of waveforms is a seriously important part of the application. If we can cut rendering time, the UI can include code that renders more frequently, making it a richer, more interactive experience.

One idea is to make use of instanced drawing (currently hidden behind a flag in chrome and temporarily disabled entierly on windows - chromium issue 288391).

In the end this may actually not help that much, and could be even more complicated than the existing algorithm.

• T - 50 elements of 1-verticies specifying time offsets within the wave, divisor = 0
• C - n elements of 3-verticies specifying x-offset, y-offset, and colormap-index for each of the n spikes (this is the thing we update when the cut is changed) divisor = 1
• V - 50 by n texture of single bytes specifying the voltage at each time for one channel of wave data

The divisor=1 means that the value is fixed while an "instance" of the divisor =0 buffer is rendered, then it increments for the next instance of the buffer.

However, unfortunately, even if it was relatively simple to get the texture coordinates for reading from V (which probably requires additional elements in T and C and is a pain to coerce into a square shaped texture), it is unlikely that a large enough texture can be used [100k waves on a single channel is 5MB, but 1024_1024_4 is only 4MB].Maybe it would be worth looping through multiple textures?

If two cuts have no more than 16 groups each then it is possible to combine the two into one cut with no more than 256 groups. And if the two constituent cuts are each "good" on one channel, then the combined cut will likely have many fewer groups than the maximum possible (e.g. for 8 and 12 you might get 20 in the joint cut rather than 8 x 12 = 96).

Need to find some way to free up the browser at some point during the several hundred milliseconds it can take to render. This is a bit complicated, but I would have thought it could be improved in some way.

Draging a file called something.0 into the application (at least as part of the initial batch of files) confuses the code that generates the list of tetrode buttons.

Probably need to convert inputs to being buttons or basic divs as Firefox doesn't seem to trigger events on checkboxes when ctrl, alt or shift is down.

speed doesn't take account of units_per_m (which is 10,000 rather than 100 for cm in a meter) and doesn't take account of pos sample frequency (which is normally 50hz). The two "bugs" cancel and give speed off by a factor of 2 (it comes out as being too large).

Final list of TODOs:

• drift mode
• sort groups by spike count
• grabbing of path plot
• update colors in "flag" rendering mode when mutating cut
• access ratemap/other settings panes from toolbar (can currently access these panes with alt- prefixed shortcuts)
• allow rotating of definition of "north" in direction plots
• make sure only one cutting tool can be in use at a time
• fix the heavy-zero line in density rendering [bad data not a bug]

and then fix any bugs that are yet to be identified....

• cut dragging bug
• improve quality of path plots
• speed is off by a factor of 2 (see #34)
• incrementing painter dest should find first empty group not just add a group to the end (in order to match old behavior)
• file organiser last_used_cut and selected_cut bug (see #33)

This may require some sort of post-processing of the pos data.

Currently only Chrome is supported, which is probably ok, but it may not be too tough to get FF working as well.

It needs to be better at accepting new files after the initial file dump. It also needs to be easier to use, e.g. clicking on a file ought to select the given experiment (currently you have to click on the background experiment which is confusing). And when you load something it should automatically select that trial (a bit difficult to decide what that means when loading multiple files with synchronicity, but it should be possible).

Although the codebase has undergone multiple restructurings in the past, it is still rather unwieldy and adding plots and other features is a painful process...even though the end result may look painless.

With some work it should be possible to improve upon this situation. Ideally it should get to the point where it only takes a few hours to add a completely new plot type and have it work seamlessly with everything else.

With the latest rewrite, even wav-drift shouldn't be too hard: in density mode we currently use the red channel for counting, but we can use the green channel for summing total times, and then do the division in the second stage of the render.

Not sure exactly what plots to show for the other things.

For rm, might use brightness for rate and red-green for some kind of weighted mean time, with the weighting used to ensure we do normalise by dwell somehow.

For speed and dir, we are currently showing a 1d dataset, so adding a second dimension isn't hard, but has do be done in a useful way.

Currently there is a basic right-click mock-up of the tool, but it doesn't do anything.

also for changing kernel size (and form?)

Have already started working on this