1. What did you do this week?

This week i tried to adapt the computation of the `tfr_multitaper` function to give out the correct data field when feeding it with `SourceEstimate` objects.
Later, i switched to adapt the `tfr_morlet` function in the same way i did with `tfr_multitaper`, since i noticed that this would be a better place to start in terms of comparability (There's an already premade function existing for morlet wavelet transforms in source space to which i can compare my work, while for multitaper, there exists none).

2. What is coming up next?

I'll try to create exact results from the morlet data now. it already looks very good (let's say the data fields are about 80 - 90 % similar, however there are still some small differences i haven't figured out yet).

3. Did you get stuck anywhere?

Yes. When getting `tfr_multitaper` to read `SourceEstimates`, i thought that testing the data on artificially created frequency data seemed a good idea. However, i noticed that this is not an optimal solution to test, especially since it's better to use valid `SourceEstimate` data. This was also the reason i switched to working on  `tfr_morlet` before getting `tfr_multitaper` done entirely.

Last week, i got the first `SourceTFR` draft far enough to actually use it for TFR functions, which was the other main task this week.
The process was more or less like force feeding this alien object into a function constantly complaining, checking out every error it makes and trying to correct it. Yay!
The main task for now was pretty much juggling data fields around, until everything's fine and introducing new if cases for the `SourceEstimate` data types.
I don't really expect the function to produce correct time-frequency transforms at this point, but i think i'm getting closer and closer.

Unfortunately, i also had to work on another MNE pull request last week which cost me A LOT of time, yet i wasn't able to make much progress on it.
So this week, i'm going to focus more on the GSoC project, which is of course the more important thing to work on.

So for this week, I'm going to continue working on the multitaper TFR function and hope to produce some first results of time frequency transforms.

1. What did you do this week?

This week i started creating a `SourceTFR` class to work with, as well as making some first tries to feed `SourceEstimates` into mutlitaper the TFR function.

2. What is coming up next?

I'll continue to work on the `SourceTFR` data, up to a point where i can use them for the TFR functions (that means plotting might not yet be involved). Then i'll try to make an entire multitaper function work for one case of `SourceEstimate`.

3. Did you get stuck anywhere?

As expected, there were several walls i ran into. One Aspect is of course the difference of dimensionality and type of data that `SourceEstimates` can contain, but are not easily adapted to time frequency functions. Another type of problem certainly is to make sure the function works correctly and works well for all kinds of tunable parameters (which is of course a big part of the goal of this project).

This week i started creating a `SourceTFR` class to work with, as well as making some first tries to feed `SourceEstimates` into mutlitaper the TFR function.
It already looks like it's going to be a lot of work to do, not only because new types of data need to be feed into the functions, but also concerning the time-frequency transforms themselves.
The main motivation behind this project is to allow users to be able to handle time-frequency transformed source space data with as little restrictions as possible, so I'll try to make sure all of these options are covered well for source data (i.e. all the options that are theoretically possible). But that surely will require a lot of work to be done.

So, I'll keep on making small steps, working my way through the multitaper functions and then later make sure it works nicely for every case.

See you next week,
Dirk

Hey there and welcome to my Google Summer of Code blog!

For the next months, I will be working on improving Time-Frequency Analysis for source space projected data in MNE-Python.

After having set up my developing environment as well as working on some unrelated commits, I'm currently making the first steps for the actual project. Over the last weeks, me and some of the MNE members were discussing a more precise outline for the kind of data container object, in which we would like to store our newly created time-frequency transformed source data. The result of this discussion was a pretty cool type of container, that would store source space data in a very memory efficient way, which at the same time could drastically reduce the time needed for computing a time-frequency transform on it. However, creating such a class could even be made bigger, as to include any kind of `SourceEstimate` data type, and might lead to a significant restructuring of the entire source space API. While this task is probably too large to be handled within one single GSoC project, I'm currently starting out on creating a kind of a 'draft' class, which for now will only be used for the `SourceTFR` objects that i'll create during my project.

So there's a lot of interesting stuff coming up right now and I'm very excited to find out how it's going to turn out...

Stay tuned,
Dirk