most of the things I already do, like the 0-64 controls, as this is widely used within the axo environment.
At the moment the sample-data and sample length info are saved in the same module, but I'll change this to 2 array's. Also because at the moment I'm saving to an array that's not called array, so saving/loading the table ain't possible yet without a dedicated table-save/load code.. I first wanted to get the code working nicely.
So in the end I'll just use the factory table modules to save the info into, so different modules can read/write to it.
Also, all the controls on the module are inputs, not knobs/buttons, most are floats (-64 to 64) and some are integer (eg. sample number), so these could also be controlled by universal table-preset-modules/pattern generators.
About the "float-values".. I think you mean the blue fractional outputs? As these are just integer values that are shown as decimal values on the knobs and displays. An actual float-value costs more cpu to calculate, so I mostly try to not use them if possible (or only as k-rate or updated at input-trigger/gate/change).
The start, end, loop-start and loop-end of the sample is already done in 0-64 values, but the offset is saved as the integer offset in the table to prevent mis-calculations. If you'ld use 0-64 values(of course with the <<21 behind it) with scaling, you'll probably have some mistakes at some points about where to start/end the sample, possibly adding unwanted clicks (-1/+1 sample and perhaps even more if more bits are lost in the calculation process) .
This sample-start-position info should be enough information to calculate the 0-64 offset and range in the module that's reading the array (that's what I'm also doing now).
As the recording rate is always the same (48000hz), all the needed read-out values should able to be calculated using known scalings.
Next to this, if somebody would use a smaller/larger array then the table is saved as, all these offset and range positions would be off. By saving the actual positions, you can just make your table smaller with a loss of some samples if you need the sdram space for something else.
About the playback speed, I'm using a phazor that is rescaled back to the right size using the start-position of the sample and starting position of the next sample ("next sample start"-"current sample start"-1=width) and use the width to rescale the frequency of the phazor, so a 0 for pitch is the normal play rate. The ratio-play-rate can easily be done by just multiplying the frequency. So the playspeed can be adjusted in ratio, integer multiplications and in semitones.