Hello
I have different loop samples (length 2 - 20sec, 48.000 Hz, 16bit raw, stereo) streaming with wave/play stereo objects. The start is triggered by an LFO. Even if I set the LFO rate to the exact length of the sample there is always a short "click" at the looping point. The samples on the computer are looping fine. It's possible to avoid the "click"? Is the LFO the correct object to trigger the wave/play?
thanks 
I havent tried my self, but I read in here that some other people removed the click by moving start position 0.01....
I've definitely gotten rid of the click by moving the position. Try very small numbers (between 0-1).
Another way is to run the output through an Attack / delay filter.
The problem is that there is an abrupt transition from nothing (not playing) to playing.
Best of luck. Let us know what works for you!
Thanks guys!
but it's not working. I have to mention that I don't use the loop for audio but for oscillographics ...
I tried to redo the loops from scratch but there is always a little glitch.
I think the problem comes from a discontinuity between the end of the loop and the beginning. You might try adjusting the speed of the lfo, but with such implementation you'll still have a 16-sample precision. It's unlikely that you find the exact loop point, maybe you can get close to it, but no more than that.
If you saved the sample as raw (headerless) there's no click at the beginning of the sample to eliminate with the pos workaround
can you email me your wav and raw file (Ive PM'd you my email address), I'll take a look
also do you know for sure if its the start of the end causing the glitch?
(perhaps use a envelope to give you fade in/out... though they maybe a bit too 'slow', but might given an idea....)
@Sputnki I think you are right ... perhaps I could try to make shorter loops and loading into a table? Or is there another technique to make precise looping points?
@thetechnobear I mailed you an example loop
Unless you want to delve into the obscure depths of object modding i suspect there is none, but you can try with the table
Id go with @Sputnki, I think its a start/end discontinuity.
theoretically if you get the right LFO rate it should work, as there is no discontinuity in the file, ,as its a multiple of 16.... but finding the exact rate will not be easy. you could also play with pos... (not because this will avoid a start glitch, which as @Sputnki also pointed out, is only relevant to wav files) to find a different 'start point'.
it might be between the two you can 'stumble' on a good combination.
moving to a table wont help really, unless you start processing with a custom C object, to determine suitable start/end points.
shorter loops might help, just because its a little more manageable to see whats going on.
I think without a custom object, its a bit trial and error on the lfo rate/pos and and an envelope to fade the beginning and end.
The other way to solve this is potentially to modify the player, so that it has an option to automatically loop.
it knows when the end of the file is, so assuming no discontinuity in the file (which there isn't in this case) it could loop seamlessly
Found this custom wave/play object on the forum from the user @constantin https://sebiik.github.io/community.axoloti.com.backup/t/looping-samples-via-play-fn/2202
It's almost working ... only a minimal glitch at the looping point... but is certainly more comfortable as trying to find the loop point with the LFO.
ok, Ive extended the factory wave/play objects to have an 'end of stream' output, which is basically what the above does. (Id been meaning to add for a while, just forgot about it)
so if you sync libraries, you will pick it up.
yes, it wont completely solve your issue...
I assume your using the end of stream, to then reset the play, the issue with this is its one k-rate cycle too late... i.e. you end up with a one buffers worth of zeros, what you really want to happen, is for the player to loop back to the beginning to get the first buffer immediately.
(but doing that is a bit more involved... we are reading in a different thread, so that needs to see the end, and then automatically read the first bytes again)
Thanks @thetechnobear!
How long is a k-rate cycle? Perhaps it's possible to read the exact length of the loop after the first 'end of stream' and then subtract 1 k-rate cycle length. The first loop would be wrong but the following should be right.
k-rate is 3000/sec.
hmmm, possibly if you ran a counter on the first run, to count the length , then subtract 1,
then use this on subsequent cycles to reset the wave/play , assuming the sample length is divisible by 16.
the issue I see is, that when you set start (to reset it) , I dont believe this is immediate.
basically it sets a flag, which means on the next k-cycle it will do a seek to the beginning of the file, and then the read thread will pick it up when its next executed, so then the next k cycle after than its sent as output.... the upshot, if this is the case , is you get a 1 k-rate cycle delay after you call start.
anyway, its possibly worth a try... it will probably reduce the glitch.
