I’m wondering how sample files are referenced on an Octatrack project (specifically sampled loaded in the Slot Lists):
will OT projects will be able to load files successfully if i move files around on the CF card ?
will the “Collect Samples” functionality collect samples that are assigned to a Flex or Static Sample Slot despite them not being assigned to a Trig or Lock key ?
I know that on the Digitakt is referencing files using a hash which allows to move/rename files without any consequence on projects. Does the Octatrack works the same ?
The manual isn’t crystal clear in that concern. For tests, use samples in slots above slot 8, because Flex and Static slots 1-8 are assigned to tracks by default.
COLLECT SAMPLES copies samples that are used by the currently active project into the project directory, which will effectively disconnect the project from the audio pool.
PURGE SAMPLES will remove all unused samples from the project. Note that samples are only removed from the Flex and Static sample slot lists of the project; the actual samples will not be deleted from the audio pool.
will OT projects will be able to load files successfully if i move files around on the CF card ?
Only if you correctly modified the project.work file and change the PATH settings to match the new relative file path.
The project.work file is what gets loaded when the project is opened / the machine boots up. Don’t need to worry about project.strd unless you want to change the previously saved state of the project.
Moving a file from the project pool to the AUDIO pool, you would need to do something like:
my_sample.wav ==> ../AUDIO/my_sample.wav
I’m wondering how sample files are referenced on an Octatrack project (specifically sampled loaded in the Slot Lists):
Some low level detail for you (and anyone else interested)
‘Attributes’ data
Slot ‘Attributes’ are stored in the project.work and project.strd file, as mentioned above, storing the following data
slot_type
slot_id
file_path
trim_bars_x100
timestretch_mode *
loop_mode *
trig_quantization_mode *
gain *
bpm *
A slot is only ‘active’ or ‘loaded’ in the UI if it has data in the slots list in the project.work/project.strd files.
Slot ‘Markers’ i.e. Trim Start/End, Loop Points and Slices are stored in the markers.work and markers.strd file. This is a binary file (reading in a text editor will look like nonsense).
For the 136 flex slots (includes 8x recording buffers) and 128 static slots the data looks like this:
Any of the fields for each of the different data type with an asterisk next to them get written to the Sample ‘Settings’ file (my_sample.ot) when saving the sample via the menus.
Do I get it right that attributes correspond to EAD sample settings
Not sure what you mean by ‘EAD’?
Do I get it right that attributes correspond to …, as well as sample position in slot list?
Meaning it’s possible to reorganize samples in slot list by editing project files? (which is a pain to do in OT UI for a lot of samples)
Ehh… no. If you need to edit slot type or slot ID (i.e. move the slot) you’ll probably have to update the markers.* file at the same time to ensure the trim/loop/slice config is carried over.
so if you want to move a slot from STATIC 126 ==> STATIC 5
change the slot ID in project.* file (one-indexed)
move the slot trim/loop/slice data from position STATIC 126 ==> STATIC 5 in markers.*
if you want to move a slot from STATIC 126 ==> FLEX 5
change the slot ID in project.* file (one-indexed)
change the slot type in project.* file
move the slot trim/loop/slice data from position STATIC 126 ==> FLEX 5 in markers.*
If you change the FILE PATH of a slot, then you might need to update the markers.* file as well – because any existing trim/loop/slices data for that slot may not make sense anymore (e.g. a slice might exist beyond the maximum length of the audio file).
Anything else in the project.* file for a slot (i.e. not slot ID or slot type or path) you can edit kinda freely without touching the markers.* files. Changing time strech mode / loop mode / trig quantization etc you don’t need to touch the markers.* files …
late edit – also – if the slot is used somewhere in a bank, you then have to think about whether you support automatically updating all the bank files that use the existing slot.
side note – is a bit of an annoying design decision in the data files, having to load both project.*/markers.* files and modify each of them in a completely different way just to move a slot.
but i can see the benefit of project.* files being string data – i’ve just had to manually rebuild about 25 projects after the OT borked patching some old projects from 1.25E ==> 1.40B.
would have been an absllute nightmare to sort out if the project.* files were binaries.
bash script. the patched projects had no sample file paths loaded in project.work files, all empty for some reason. Had some old OctaEdit backups for the projects which did have the sample file paths listed.
basically csplit the project.work files on # Samples section header, then appended the split tail from backup into live project version. then some diff checks to make sure nothing was missing.
now i just have to go through and manually save 672 banks to force the bank files to latest data file version – octatrack doesn’t seem to patch the bank data files with new OS data structure updates unless you explicitly save the bank. Pretty sure I tried a SYNC TO CARD and … nada (might be wrong and deffo gonna check cos 42x SYNC TO CARD buttons presses are way less than 672 SAVE CUR BANK button presses )
I just tried to update the .work files ( and found that I am unable to simply move a folder to a new location on the CF card, then redefine the path in the .work files. This seems to yield errors in the relevant sample slots for FLEX or STATIC machines. When I edit the files, put the old paths back in, and modify the folder structure to what it was previously everything works fine.
Did you find a way to do what I describe?
Also: is it “bad” to edit the files the way I did? Like, does it downgrade the project .work files in any way that you know of? My understanding is that they are just ASCII text and that the way the octa interprets them, paired with the proprietary format of the .ot files etc are where the secret magic lies…
)
