-
Notifications
You must be signed in to change notification settings - Fork 14
Appendix B: Sampling duration deep dive
"Ok...well what about sampling duration? Why's it so short when sampling in trackers?", we hear you ask. Like the previous question, this pertains to all sample carts (not just ours) but unlike the previous question, it's much more straightforward to answer.
You'll have noticed that when sampling at e.g. tracker note A-3 (which we've established is usually the highest note/sample rate that you'll want to use for anything melodic/pitched) you get only a few seconds before sampling ends and you're dropped back to the main screen. But you've got acres of chip mem available! Entire continents of fast ram! All those old bundled sampler programs let you program at higher rates than this for aaaages!
Well, this is partly a limitation of the MOD format - established by Karsten Obarski for SoundTracker and then refined slightly over the years by successive NoiseTracker and ProTracker coders. Almost all MOD trackers will cut off sampling just before it hits 64KiB (even though the format can technically support 128KiB - but that's another story). It is what it is; we're not entirely sure why this limitation exists, but we're used to working around it and so is everyone who's ever composed a module.
You might find that sampler programs suit your workflow better, in that you prefer to record a much longer duration in one go and then save out selected chunks for loading into ProTracker later (ProTracker and its fellows will just read the first 64KiB of a >64KiB sample and discard the remainder, so don't worry about overloading it with samples that are too big). Or you can get used to doing what we do: looping your source material on whatever device you're sampling from and having a quick mouse-trigger-finger on the Amiga's record button.
But remember: even with the dedicated sampling programs you'll eventually run up against the limit of your system's chip mem - the main Amiga RAM type that's optimised for fast DMA access by the custom chips. Unless a program does some fiendish and CPU-intensive data juggling, most sampling programs won't be able to use your fast mem for this, so beware of splashing cash on fast RAM expansions if all you want to do is tracking. Find out much more about different Amiga RAM types and what they mean for ProTracker by reading the guide I wrote in bootPT's documentation.
**UPDATE: ** Protracker 2.3F now supports sampling up to 128KiB! Lots of 128KiB compatibility patches had been introduced by h0ffman and 8bitbubsy but 128KiB sampling was broken until I found and submitted a fix in Jan 2021. The official release of PT2.3F has been updated, as has my custom bootable ADF version, bootPT.
The above information still applies to most other trackers, but OAS (or any parallel port sampler) and PT2.3F now make great companions: with extra continuous sampling time it's much easier to e.g. sample entire phrases and decay tails from external instruments, or to sample longer percussion loops without having to compromise on samplerate. The sample offset commad (9XX) no longer works on samples greater than 64KiB but even if your final sample ends up being <64KiB it's good to have double the maximum workspace for editing.
- How do they work?
⚠️ WARNING- That WARNING sounds serious. How did you test your design without risking Amiga hardware?
- Why is this sampler design mono, not stereo?
- What's the aim in terms of quality and application?
- What about those edge cases? Who is OAS not aimed at?
- How compatible is OAS with existing software? (Work in progress, submissions welcome)
- Current status