For A.7, I imagine TRestRawSignalToHitsProcess can always be replaced by TRestSignalZeroSuppressionProcess plus TRestSignalToHitsProcess, so this is unnecessary.
For A.15, I think Decay0 is a generator, and generator is not necessarily to be connected with geant4. There are situations that the user wants to write a toy Monte Carlo with Decay0 but without geant4. So I don’t think Decay0 should be integrated into libRestG4.
Yes, although we would need to add a new method to TRestSignalZeroSuppressionProcess to be able to fit the raw data, it is a new method.
Perhaps we should then change the name of TRestSignalZeroSuppressionProcess to TRestRawToSignalProcess, and have a method named zeroSuppression and a method named rawFit.
Ok, perhaps if we know where else it will be used, will be easier to think where it should be placed. This is connected with the generic particle generator @lobis is working on. In the future, it makes sense the particle generator will be placed in framework/physics, probably Decay0 generator could also be placed in framework/physics.
In any case, if Decay0 generator requires external libraries, we should then have a compilation option that allows us to link or not to those external libraries.