Get Audio File Length Independent of Audio Looper Start/End Points

[HISEnberg]

How can I get an audio file's true length in samples when it is loaded into the Audio Looper, independent of the start and end points set by the Audio Looper?

Each method I have tried seems distorted by the start and end points set by the Audio Looper (I don't want to use the File System API in this case either).

My best hope was to reference the audio file as an AudioFile the use AudioFile.getNumSamples(), but I still experience the same issues.

Does anyone have any ideas. Here is a small example of what I am referring to:

HiseSnippet 1224.3oc2Ws0aaaCElxNZsw6BV2ZA1iBA6A6tlXY6jztUTLmKNaFKI0HNsa.ECEzRzVDghTfhJsFC6+3dY+O1+fsCEkskRURS7VGVmeSGxy47ct8wiGHEdj3XgDYU6zoQDj0GYObJWErW.lxQ82GY8I1GgiUDoiQztSivwwDejkU0uSKvZ0UPo+9iucWLCy8HKDgPOWP8HGRCopERGz8GnL1AXexozvb2dyt88D78DLQBfmp1tnHr2Y3Ijiw5qUwF8833.j08sa2pia6sGuU6wOpcmNask6laOZb6VttOba+NecmQ9jVdda65hr9fd9TkPNTgUjXj0J6J7mNLP7JtwAOmFSGwH5OZgFBd1H9.AyWGhZon8BnL+AyRTwHjk8fEosplz1csOh5SmKeQ56SSOvYgF4SfVUJBupEfWq7vyMG7JARV4fzJFHcG6gdRZjZwIZ77g184P0bLFpS4gh4tnJ+dE68DvM3pMBwmQNPBeLWi5a559.m1ttMdbsZPsJV4bNV5bnPDAMHOwIs0YiID0NI9TwPbXDiL280Wybu0.kWnKVeyCnLBnt4745qkVO0UMa5rOc7XhDfkSHQEH7iqQ4LJm3LNg6onBtCnlwiGR3STA0aT6Wp4.+fvIVvHaDIob0LP3DqvR023rlyWkysF8GpOpdiFO1w4JL.K0KkagYH.vdIFXdvoU33jPiNw0aXLF9xN9sXMmQI5TTAfUvVY005Mdg6Oug4Vkax0WeccQ5WqUag9wy0eOLiMBFLqegvEzXdsPvOVnHOkmVDVErjyEOZ73ROS6CofwHxROVSXHuJEqySBGQjO.5sXIj4WDFJJNoYe4SZ4IB7LgbtKJ384T0SiH7Kid.kkmzSkYnB3gToyj2KalLsn8i3yIiExPD0WySTPVKTZ.jmJ0GqvHqmX27YwDYbShjShUM2mDelRD0LUamrdklXOQRrh5stuTmOvp02ZivnNHIlOwzeCo.KsUSkzi6m988uGB8r96qcTF3g3.hMn4VQ0oMq8ImCD5FBlUsybd5cCiDbcTacqabn957g4z7e7JpuJXgfocCHzIA4dKg1MZVpuOX5aaaFEgGYdC9PfIV3mvvphzy5GwxN.5jJvIp483wT0z7Ox8OFm80Eh2wd.U4ETNFqTBFgZ26BLl8R2Ga2CnY7TK.3J1G7SuadVKu6+7YtOs4IqLqc+7Z9kuZxuccWMI5ZuZB7TmGTRH4aMRqSmJAtQJeRdWoAXONFhY+7hOQHTZxv7qFk6IHv7EtM4bXtunEzTylsi96wKDpyVFBgP7qmwEv.XWfrfkFGy4JrpdUaW0ZI2tZk+ysc06AjIEV.b0YXbHUW16wOmvfIjTL9Y.o8XbBSMSZqBn7HAWDEH3TuhsdJIcxDhLO1KMf1Qof1+ERta2SHLBNNWO9W18PXuMr7hSO2fbQqa7xvkVu9BaCbczC6Nu+9HP0+e+HvIhDEPndDFZB0bS5chAdXOB3cNmvzqyYUQu3k4a2YzUCIb+zO9S3W1gszeakcXqYG9uhOBwdRwK8LqDp6SucpDHt4oT3qB+Sa3amR18KDX4domWQS8FJ1dYUryxp3lKqhasrJt8xp3CWVEezaWQ8iP6jnDglQSD5nA8R2h1xZ9y9VUQ+05X+bW

[d.healey]

@HISEnberg Looper.getSampleStart() + audioFile.getNumSamples()?

[HISEnberg]

@d-healey Thanks in most situations that would have work, but if I shorten the endpoint the getNumSamples is still updated (thus giving the wrong Sample total).

[d.healey]

@HISEnberg @Christoph-Hart

I noticed the description of getSampleStart is wrong

Returns the samplerange in the form [start, end].

So I suggest adding a new function AudioSampleProcesser.getSampleRange(), and probably also AudioFile.getRange()

However neither of these will help you as they work on the modified buffer.

Now I know how to get the original (unmodified) buffer's range too. So the question is, do I add a .getTotalRange() function - this will return an array [start, end] but seems a little pointless because I think the start will always be 0, unless you can think of a scenario where it won't be.

Or do I add a new .getLength() function? But then won't that be confusing if getLength and getNumSamples return different values?

Or do I modify getNumSamples so it returns the full length? But this might break older projects.

Or is there another suggestion?

[HISEnberg]

@d-healey Hmm I agree it does get somewhat confusing.

I imagine specifically for the audio buffer we want something like .getPlaybackRange() to indicate the modified buffer region.

Even though it sounds a bit useless now I do see some benefits of a proper .getTotalRange() [start, end] since this could allow the user to modify the buffer via scripting if they like (cut some silence at the beginning of the sample, or cut it into different sections, for example).

I agree that you should not modify getNumSamples for backwards compatibility and maybe just clarify in the docs that it returns the modified buffer region (the docs kind of say it but it's not totally clear).

---

As a side note the reason I am asking about this is because I am trying out some modifications to the Audio Looper myself since a lot of users have been asking for a crossfade function be applied. I've gotten pretty far with it but it's still a bit of a blackbox to me how to get new functions out as a new function in the HISE API.

I actually see now why Christoph has been hesitant to add this feature as the AudioLooper doesn't lend itself well to this sort of behaviour. I've resolved to just reading the tail end of the audio buffer (fadeOut region) and cross-mixing it with an equal length portion of the beginning of the buffer (fadeIn region). But it quickly breaks when I start moving the the buffer start position since, as you've pointed out, these aren't necessarily loop points as much as they are the buffer's start and end position.

In my example the paintRoutine applied to the audio looper is scripted on the backend whereas the version on the HISE UI is using HISE-Script which is why it's breaking.

[d.healey]

@HISEnberg said in Get Audio File Length Independent of Audio Looper Start/End Points:

since this could allow the user to modify the buffer via scripting if they like

You can already do that with setRange()