Yep, makes sense it would/should work now. However, to be clear wrt to what I mentioned above: while it now works, you’re still using the 2016 version of the algorithm now (without the 2019 improvements I referred to above). That’s ok, but it can certainly be improved upon, in my experience and that of collaborators.
No, that makes sense: what you’re seeing there is the WM response for b=0, which is indeed isotropic (a perfect sphere) at that b-value. You can see this is the first b-value of 2 total b-values in the response function by looking at the title bar of that window; i.e. where it says
[ 1/2 ]. You were probably expecting to see the b=1000 part of it. You can navigate between b-values in that viewer by using the left and right arrows on your keyboard. So just pressing the right arrow on your keyboard should reveal the b=1000 part, which should look like a medium-fat-ish disk(-ish). Definitely not a sphere though; you’ll see.
Sorry, this must’ve not been sufficiently clear from my above explanation; I kept it short on purpose to not bother people. SS3T-CSD is not available in MRtrix3, but only in that particular personal fork. It’s set up as such because it relies on specific functionalities which are only available in a certain state of the further development code. This fork is in that particular state, to allow the command to work reliably in the environment it expects. Copying and pasting the command into another install won’t work, for that very reason. Even if it would seem to work, it’s not reliable currently. To install this, you should create a separate install; the essence of the instructions for this fork are found here. If this is confusing, I hope this explanation would give some insight in where the fork is currently positioned version-wise. I’ll get in touch privately to help, if needed, with this bit; I’m not keen on triggering sensitivities over here unnecessarily.
This is not per se a huge problem. Until a few years ago, this correction step didn’t exist yet, so there’s lots of people who ran pipelines without it for sure. That said, I would always recommend this step though: it’s a very robust Gibbs ringing correction method, and if you’re interested in quantifying subtle or very local or specific effects, Gibbs ringing can certainly mess a bit with that in very local particular areas. So it’s in principle always a no-brainer in any preprocessing pipeline at this stage.