System : Linux, MacOs, Windows?
REST version : v2.2.X
Currently TRestReadout will perform readout optimization when we generate it from an rml. We recommend reading TRestReadout from root file to speed it up. However, during hardware debugging, it is very frequent to change readout module’s electronics sockets, and we must change the firstDaqChannel in rml file and re-generate the readout file. This process needs to be optimized.
If I remember well the optimisation of the readout in the RML initialisation is more related to identify a regular squared mesh with the physical readout pixels of each channel.
I understand you need to change the decoding (relation between physical channel and daq channel)?
This might be probably modified online (inside a dedicated process) once you get a TRestReadout *readout instance?
I might imagine a TRestModifyReadoutProcess dedicated to fine-tune different readout parameters.
You may add this to the list in TODO.md.
I have added process TRestDaqChannelSwitchingProcess to do the job.
I see, however, a more generic TRestModifyReadoutProcess could be more interesting. In my case I will soon need to modify the cathode position of an existing readout. So, a more generic name for the class could cover both, switching channels and modify the decoding, and/or change other parameters as the cathode position.