Hi Santiago,
No worries :)
By default, each gene will have its own clock rate and these clock rates will be multiplied by the clock.rate I described above (which I think is close to what you originally wanted).
At the XML level, the gene tree likelihoods will look like this (one gene clock rate rate per gene):
<distribution id="treeLikelihood.29" spec="TreeLikelihood" data="@29" tree="@Tree.t:29">
...
<branchRateModel id="GeneTreeClock.c:29" spec="starbeast3.StarBeast3Clock" clock.rate="@clockRate.c:29" geneTree="@treePrior.t:29" sharedRateModel="@branchRatesModel.Species"/>
</distribution>
<distribution id="treeLikelihood.47" spec="TreeLikelihood" data="@47" tree="@Tree.t:47">
...
<branchRateModel id="GeneTreeClock.c:47" spec="starbeast3.StarBeast3Clock" clock.rate="@clockRate.c:47" geneTree="@treePrior.t:47" sharedRateModel="@branchRatesModel.Species"/>
</distribution>
And these gene tree rates will be multiplied by the scalar clock rate of the clock model:
<sharedRateModel id="branchRatesModel.Species" spec="starbeast3.evolution.branchratemodel.SharedSpeciesClockModel">
<branchRateModel id="strictClockModel.Species" spec="starbeast3.evolution.branchratemodel.StrictClockModelSB3" tree="@Tree.t:Species">
<parameter id="SpeciesTreeStrictClockRate" spec="parameter.RealParameter" estimate="false" lower="0.0" name="clock.rate">1.0</parameter>
</branchRateModel>
</sharedRateModel>
By default, the gene clock rates are sampled from a fairly tight lognormal distribution with a mean of 1. In theory, this could lead to non-identifiability problems between heights and rates, but this has not been an issue in my experience
Cheers,
Jordan