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

[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()

[Lindon]

@d-healey said in Get Audio File Length Independent of Audio Looper Start/End Points:

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

how about .getTotalLength() ???

[d.healey]

@Christoph-Hart Do you have any opinion on which route to go?

https://forum.hise.audio/topic/13613/get-audio-file-length-independent-of-audio-looper-start-end-points/4?_=1760264417913

[Christoph Hart]

@d-healey The C++ class that wraps around a audio file object already has the requested methods:

Range<int> getCurrentRange() const;

Range<int> getTotalRange() const;

Range<int> getLoopRange(bool subtractStart = false) const;

so it's just a matter of adding the wrappers to the scripting API to both the AudioSampleProcessor and AudioFile objects.

[d.healey]

@Christoph-Hart Oh yeah I already found those, but I didn't know if it made sense to just make wrappers for them.

For example the total range is always going to return an array with a value of 0 for the start. Is there any value in that, or would it be better to have the function just return the length?

[Christoph Hart]

@d-healey the reason is clarity, so you won't be thinking about whether it's the total range or the selection. However a new method getTotalLengthInSamples() would do the same thing.

It's a bit faster on the performance side because an array will always require memory allocations, but that should be negligible and we should choose the solution that is easier to understand without having to read the documentation.

[d.healey]

@Christoph-Hart said in Get Audio File Length Independent of Audio Looper Start/End Points:

getTotalLengthInSamples

I will make it so

[d.healey]

@Christoph-Hart Tis Done

I think it would be a good idea perhaps to also have a function to set the loop start/end, but I didn't take the time to figure it out.