Stems is a Stem Player (Sample Player) where all samples (tracks) are replayed in sync.
This can be useful for processing stems you export from another DAW, like Cubase or Ableton Live.
Use the right-click-menu to either load individual files, or load the first (in alphabetical order) 6 wave/flac-files from a folder.
Some DAWs will name track with a track-number at the end when exporting multiple tracks. You could say it’s optimized for the case described in this post:
As some might have noticed 48k(Hz) is becoming increasingly popular on more and more platforms, and many (most?) DAWs still default to 44.1k. I other words, there is a decent chance you will be faced with files of both sample rates. (And maybe you like to run your projects at 96k)
If a file has a sample rate that is not exactly the same as the engine sample-rate the sound will be re-sampled with a high quality algorithm.
Each Track has a vu-meter where the color describes some details about the sound.
Green = Sound has same sample rate as project, no sample-rate-conversion has happened when loading this wave.
Orange = Sound has been up-sampled. (no information present in the source data is being lost, but some very subtle change could occur)
Red = Sound has been down-sampled. (high-frequency data in the source data is thrown away)
The inputs are:
Stop (stop playback and reset play-head to beginning)
(Re)-Play (play from the beginning)
Play (play from current play-head position)
Pause (stop playback and leave play-head position)
Reset (reset play-head to beginning without stopping playback)
Beware of memory consumption with long pieces, since the entire file will be loaded into memory at 32 bit resolution. If it needs to be resampled the entire resampled sound will be in memory too.
As an example: a full hour of 48k stereo would eat 1GB of ram, if the project sample-rate is at 96k, the resampled copy would eat 2GB, so 3GB in total)
Also be aware that loading tracks that need resampling will spawn temporary worker threads (one per audio-channel). The resampling is CPU-intensive, and putting the work in threads is done to not block the GUI or cause audio-glitches. If you do not have many cores on your CPU you might notice the CPU-spike. Don’t be alarmed and there should be a “progress-bar” looking thing to indicate the progress.
This looks very cool! Two Q: 1) what is the “very high quality” sample-conversion algorithm? and 2) Why don’t you discard the original after you have processed it?
Then the polynomial (link above) to match 4x of the target-rate and then
4x decimation
I keep the original so that switching sample-rate wouldn’t trigger a reload… i realize (now) that seems like rare case… it was very common while testing
wow, that’s impressive! 512 point brute force, or some clever trick? 512 brute force would take a lot of cpu! And, yeah, optimizing for changing same rates - not so common…
When doubling sample-rate, every other sample is exactly the input, so only the new samples (every other) need calculating
The sinc-function is symmetrical around its center, so you can add the left and right sample and only multiply with one coefficient (since left and right are the same).
If I was really clever I’m sure I would have put some FFT in the mix too…
Block convolution with fft isn’t so bad. Once you have your windowed impulse. I didn’t realize before that of course you only need to convert once, ahead of time. So of course the cpu usage is not affected. Brilliant module! Btw, at least for hacking it would be nice to be able to directly load a file, rather than a folder of them.
The browse for folder dialog that appears on Windows doesn’t start at the previously selected folder but at the root. So you need to drill down all the way again if you want to pick a different sub-folder
My personal preference is to select the individual files specifically rather than have the module pick the first six in a folder. As it is, I need to construct a dedicated folder for a patch to get the right files. E.g. the way you can pick files in NYSTHI QuadSimpler
I have multichannel FLAC files I have created for surround, e.g. 5.1 (6 channels), 7.1 (8 channels). With my Dolby Atmos experiments I might even have a few more channels. I’d like a variation of the player module that could take a multichannel audio file and output all the channels. It could have a single poly out jack rather than needing separate jacks for each channel, which would avoid hard-coding a limited number of output jacks. I don’t think the module would need to handle more than one file, since I could use more than one instance of the module if needed. If it could handle FLAC and WAV that would be great. [N.B. For anyone interested, NYSTHI’s PolyRec/PolyRec64 save multichannel WAV files]
Thanks!