Version 3.47.0 "Action Eclipse" along with under the hood updates

With 3.47.0 "Action Eclipse" not much changed visually. Added default action/control python script templates -- more to come. And much more planned on the python level part automated instrument control side.

However, a key addition/new control level on kernel module basis was implemented. Effecting only specific interaction with the MK3 signal control/management topology. So far signal control/management had to be restricted to exactly one task -- and was/could not be enforced. Else missleading signal read back could be the result.
Most users won't care as normal operation is not effected.

Some internals -- only kernel guru's may get the point here...:
So what we have now with the lastest usb-sranger-mk23 module is a new set of IOCTL control commands to enter (on device level) a exclusive access mode in a few different ways. This now allows on kernel level a mutual access control for rescources. But must be high-level managed. As regular DSP and USB transfers are not effected in any means. Stil free read/write on the so far firtst come fist serve basis.
Only a pair or write-read actions is automatically protected only for file descriptors issuing the EXCLUSIVE_AUTO mode via IOCTL which is automatically entered with the next DSP write access and automatically released after a consecutive following read access. For the time waiting for the following read access all other file handles with this mode entered (by a initiating write after mode request/set) are put into a temporary spin-lock via a kernel semaphore for any write attempt -- managed via a spin-lock queue in case of multiple pending requests. This way it is assured that any (signal config read back/management in the current MK3 DSP tolology case) read back request (by a previous write of a request) is actually read back undisturbed by the process initiating it.

Practically this means: now you can safely run even multiple "patch-racks" instances (querying the full signal status frequently) and gxsm3 instances at the same time and all is going to be fine.

[Percy Zahl]

Notes on this update:

To get this into effect -- assuming running a previously up-to-date Gxsm3 + SRanger DSP you only need to do this:

a) terminate all gxsm3 and scripts accessing any MK3's via USB.

b) unload the kernel module as root: "rmmod usb-sranger_mk23"

c) svn update sranger-svn and then rebuild the kernel module, install and load:
cd your-svn-code/sranger-svn/SRanger/SR_MK2_MK3Pro/kernel-module/src/
make
sudo make install
sudo modprobe usb-sranger_mk23

may check via "sudo dmesg" if all is good.

d) svn update you Gxsm-3.0 sourec, rebuild, install...
cd your-svn-code/Gxsm-3.0
make -j8
sudo make install

that's it.

The DSP does not need to be touched and can even stay active/or tunneling/in rnage if you are feeling lucky...

Fire up gxsm3 and if you like the mk3_spm_configuratopr.py script.