Somehow the shortcut for capturing single image, “r”, doesn’t work in SUMA. Other keys such as shift+r for recording works fine, but when I press “r”, it just changes “oversampling” to 2 → 3 → 4 → 1 → 2… and so on (see the attached screenshot). Any idea why it’s happening? I’m running AFNI & SUMA on Linux.
I don’t think so- I’m using Linux workstation via virtual machine from Mac OS using Mac keyboard, but the number keys in “number pad” in my keyboards presses as “numbers”, so I don’t think the numlock is on.
Hmmm, I wonder if this is an issue of Mac doing things differently than LInux and effectively passing along the wrong information (sometimes on Macs, keypresses work differently, oddly enough).
The AFNI version I have is AFNI_20.1.10 ‘Otho’ (linux_openmp_64: May 26 2020). I also found we don’t have Netpbm installed, but I don’t think it should matter…
I was wondering if we could test this further to see where the issue comes up by trying to drive SUMA with command line input, rather than by keypresses filtered through the Mac interface.
This script will:
find an open port
open suma with that port referenced (with a random image)
have @DriveSuma pass a command to that suma run, and have it snap an image.
So, copy+paste this into a text file called “do_test_suma.tcsh”:
OK, so I think the initial issue is that Mac is doing something funny to your keypress before passing it along.
How to fix that… I am not quite sure. I don’t think the issue is Mac having a keyboard shortcut for “ctrl+r”, because then I would think something totally different would happen. Might be worth checking, though.
If you really want to use keypresses in vivo, but Mac is causing problems (typical…), you could try to open up the image and just use your computer’s screengrab capabilities. On Mac, it is something like shift+command+{1,2,3,4}, I think? In truth, that is a bit close to what SUMA does anyways-- it captures at screen resolution, so making the image “big” effectively makes it higher resolution in the end (because whenever you publish/use it, it will be shrunk+condensed, becoming higher DPI).
Okay, thank you for your prompt help. I’ll try driver scripts. It’s kind of interesting that both “r” and “Ctrl+r” behave as if “Alt+r”, i.e. increasing image oversampling factor. I’ll check whether anything I should change from the Linux machine side too. Anyway, thanks for your help again!
“apple+ctrl+r” also increases the oversampling factor. I also tried “ctrl+shift+r”, which actually turned on/off the disk recording of image, as if it’s normal “ctrl+r”. So in my terminal:
“r” = “alt+r” = “ctrl+r” = “apple+ctrl+r”: changes the oversampling factor, like normal “alt+r”
“ctrl+shift+r”: record the current image directly to the disk (./SUMA_Recordings), like normal “ctrl+r”
“shift+r” (=“R”): toggle continuous recording, like normal “shift+r”
Strange. At least it doesn’t look like AFNI/SUMA problem, but more like setting in my terminal or virtual machine… Anyway, thanks a lot for your help with troubleshooting this issue!
The ‘r’ not working is very strange. Check keyboard shortcuts under preferences and the keyboard language layout.
The
National Institute of Mental Health (NIMH) is part of the National Institutes of
Health (NIH), a component of the U.S. Department of Health and Human
Services.