it appears that Samplv1 was recently implemented with a different looping system and the choice was made for that one.
This means this Ticket can be closed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i was reading up on why the decision came to be to drop the small fade in and out to make a seemless loop. I do understand why the decision was made to look for the zero-crossing method only, as you mention in that Github issue #12.
Quote from this issue: 'good news are micro-fade-in/outs on loop points are now gone ( c226562 ) bad news are that other, more atonal but looped samples may now click harder than before :( '
We on the other hand work with ambient sounds, that falls into the catagory 'more atonal but looped samples'. And yes, the clicks are louder in these sounds.
Why not let the user have the option to choose between the zero-crossing method OR the fade in fade out method?
The user can decide which of the 2 methods works best for him and Samplv1 will be the choice for ANY sound material that needs to be looped....
(And if this option became available for the user, it would be great to have a knob where he can set the fade in and fade out time to find the best setting for minimizing clicks.)
Last edit: Menno 2018-04-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
can you post at least one of the sample files where loop-points with current zero-crossing alone is more glitchy than with the former crossfade strategy?
btw. the micro-fade-in/out code is back but for the time being only on the [xfade] branch--maybe you can tell whether it's a slight improvement or else.
thanks && cheers
Last edit: Rui Nuno Capela 2018-06-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
we (Harry and me who both attended LAC2018) are very happy you are willing to look into this!
Next Monday and Tuesday we will have our musical sessions and it is then that we will write to you in detail about this issue. We will make some examples as well, because on Monday we will have one machine with one looping method at zero crossings and a second machine with the xfade branch.
Luckily I was able to build and install samplov1 from the xfade branch without probs. And noticed that you changed the looping code back to:
const float xtime = 32.0f; // nframes.
Is 32.0f the no. of frames or no. of samples? What is meant by frames in this case if it is not the same as 'samples'?
I'd like to experiment with these 32.0f settings as well. Can i change this value somewhere once samplev1 is installed or do i have to recompile samplv1 every time using a different setting?
thanks a lot!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
xtime = 32 is about the the number of samples (or frames if you consider that the sample file may have more than one channel eg. stereo); it corresponds to the time of fade-out at the loop-end and fade-in on the loop-start points.
it is this value that shall be acessible to the user as a control parameter option; must be greater than 1 to make the xfade effective.
yes you have to re-compile samplv1 every time you change that for the time being.
byee.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i couldn't wait until Monday and had some time on my hands, so....
for testing i changed the value of xtime =2400, recompiled AND made another one with xtime = 4800, then recompiled. Every time i deleted the version and installed it anew.
What i notice are the holes - see attachment.
The sawwave above has xtime = 4800, while the second one has xtime = 2400
Clearly one can see the difference in the holes.
This means that the xfade is not working as i expected. The fade out of the end of the sampleloop should be fading out WHILE the fade in of the sampleloopstart should fade in.
SO, fading out slowly WHILE fading in slowly the loopstart. This would make a seamless mix. With this one can mix any sound with anything and would not create ticks or plops...
Now, i the attachment it seems there is a fade out at the end loop and then the fade in of the loopstart sets in --> creating a hole. It is not mixed.
while the xfade branch may be a misnomer, please note that the back-ported implementation is not about cross-fading at the loop points. rather it's currently supposed to be just a small length fade-in/out on loop-start/end resp.
and yes the waveforms confirms just that (using super-longer fade-in/out lengths).
proper cross-fading is more complicated to implement but don't give up hope ;)
cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, DCoffset is the result of Samplv1 i recorded in AUdacity.
I have made a video and will wetransfer it to you, along with the loop i use. Perhaps you can replicate it.
I think it has to do with the end of the loop when this is set at the very end of the sample. I tries to find the beginning of the loop (which is in this case the very beginning of the sample also) .
Please have a good look at the sample counter, when i change to one sample shorter, it loops all right, but one sample longer the DC oddfset starts and the sample loops no more - as you can see while i continue to play the note on the keyboard.
Here is the sample i use so you can try out for yourself.
I'll send the video to you at your address: rncbc at rncbc dot org
my bad, cross-fading on loop-edges that are over or very near the end of the sample was indeed FUBARing the audio rendering--making up for dang loud and way over the top 0dBfs
No problem, i am used to smoking speakers....i am doing some betatesting for other programs as well...
Because i am not a programmer but a user, i feel betatesting is the one thing i can do in return. I'm a betatester for another program as well and the goal is always to make things better :)
And, of course, in this case, i want Samplv1 to work fantastically because it is the only Linux sampler that i know of. and the basic functionality is nearly complete.
(At one point, i want to write a manual for the program. Not a manual that only explains the functions, but more what you can do with it musically)
i will continue the betatesting once i get rid of all the smoke in my room and report back -
Q: is it your intention to be able to set the amount of xfade in time (or samples)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Q: is it your intention to be able to set the amount of xfade in time (or samples)?
yes. it probably will be exposed as property parameter; currently it's given in number of frames(samples) with (old) default value of 32 (it will be 0 in near future; only a value greater than 0 enables the loop cross-fading.
byee
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i have done some new tests with the sample file you already have, 'plopmono.wav'.
I have recorded the result in Audacity.
First, i have set a loop in the sample and play it. When i play the sample lower, you can hear and see in Audacity that there are sudden changes in the sound caused by the loop - for example as second 7.828.
The fade out/in are possibly long long enough to smooth this out?
Attached are the .samplv1 file and the AUdacity mp3
i have tested and will tell:
yesterday and today when recoding the loops in Audacity, i notice 3 samples out-of-line. They spil all the fun. They are not in line with the rest of the fades and i do not have a clue why this is happening.
When the sample is loaded at its original place C4 and played at C4, all goes well - perfect fades.
Playing lower ánd higher notes reveales those 3 samples that wish not to be tamed!
Please have a look at the attachment.
when played lower than C4:
- 4.72840
- 8.72514
- 14.11655
all goes well with C4 - at:
- 16.52370
again, 3 samples not in line when higher than C4:
- 19.13562
please try to provide at least the original audio sample (.wav) the .samplv1 preset files whenever you find something not sounding right as it should :)
let here be told that this new loop-crossfade is just an option in addition; most of the time and to my subjective ears perhaps, the current zero-crossing-auto-adjustment-of-loop-points default strategy--which is still in place nevertheless--is in overall the best strategy alone: fact is, i do also get this kinda annoying glitches and artifacts whenever the crossfade option is active (ie. xfade > 0) and only on some non-trivial/non-tonal samples...
as always, of course, YMMV.
you tell me.
Last edit: Rui Nuno Capela 2018-06-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sure.
I'll give you
1. the sample plopmono (sorry as i thought i had already send it)
2. the plopjes .samplv1 file
3. 3. the wav and times of ticks you have already: sunday_version.mp3
What does YMMV mean? My gues is Your then something...
your findings seem to go back from this late sunday;
code in xfade branch has changed a bit since then, i hope for the better but it does not invalidade any of what i told on my previous comment (before the YMMV:))
cheers
Last edit: Rui Nuno Capela 2018-06-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
just in case you've been missing the (bleeding) edge... the "xfade" branch is on a so called "cliff-hanging" stage, about to merge into master very, very soon... also, the vee-one bunch release will follow shortly thereafter...
however, sf.net git repos are experiencing some intermittent out-of-sync issues... please retort to github, gitlab or bibucket repos if you wish to be on par to the latest code, whatever ;)
all the best
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it appears that Samplv1 was recently implemented with a different looping system and the choice was made for that one.
This means this Ticket can be closed.
i was reading up on why the decision came to be to drop the small fade in and out to make a seemless loop. I do understand why the decision was made to look for the zero-crossing method only, as you mention in that Github issue #12.
Quote from this issue: 'good news are micro-fade-in/outs on loop points are now gone ( c226562 ) bad news are that other, more atonal but looped samples may now click harder than before :( '
We on the other hand work with ambient sounds, that falls into the catagory 'more atonal but looped samples'. And yes, the clicks are louder in these sounds.
Why not let the user have the option to choose between the zero-crossing method OR the fade in fade out method?
The user can decide which of the 2 methods works best for him and Samplv1 will be the choice for ANY sound material that needs to be looped....
(And if this option became available for the user, it would be great to have a knob where he can set the fade in and fade out time to find the best setting for minimizing clicks.)
Last edit: Menno 2018-04-21
hi Menno,
can you post at least one of the sample files where loop-points with current zero-crossing alone is more glitchy than with the former crossfade strategy?
btw. the micro-fade-in/out code is back but for the time being only on the [xfade] branch--maybe you can tell whether it's a slight improvement or else.
thanks && cheers
Last edit: Rui Nuno Capela 2018-06-13
Hi Rui,
we (Harry and me who both attended LAC2018) are very happy you are willing to look into this!
Next Monday and Tuesday we will have our musical sessions and it is then that we will write to you in detail about this issue. We will make some examples as well, because on Monday we will have one machine with one looping method at zero crossings and a second machine with the xfade branch.
Luckily I was able to build and install samplov1 from the xfade branch without probs. And noticed that you changed the looping code back to:
const float xtime = 32.0f; // nframes.
Is 32.0f the no. of frames or no. of samples? What is meant by frames in this case if it is not the same as 'samples'?
I'd like to experiment with these 32.0f settings as well. Can i change this value somewhere once samplev1 is installed or do i have to recompile samplv1 every time using a different setting?
thanks a lot!
xtime = 32 is about the the number of samples (or frames if you consider that the sample file may have more than one channel eg. stereo); it corresponds to the time of fade-out at the loop-end and fade-in on the loop-start points.
it is this value that shall be acessible to the user as a control parameter option; must be greater than 1 to make the xfade effective.
yes you have to re-compile samplv1 every time you change that for the time being.
byee.
i couldn't wait until Monday and had some time on my hands, so....
for testing i changed the value of xtime =2400, recompiled AND made another one with xtime = 4800, then recompiled. Every time i deleted the version and installed it anew.
What i notice are the holes - see attachment.
The sawwave above has xtime = 4800, while the second one has xtime = 2400
Clearly one can see the difference in the holes.
This means that the xfade is not working as i expected. The fade out of the end of the sampleloop should be fading out WHILE the fade in of the sampleloopstart should fade in.
SO, fading out slowly WHILE fading in slowly the loopstart. This would make a seamless mix. With this one can mix any sound with anything and would not create ticks or plops...
Now, i the attachment it seems there is a fade out at the end loop and then the fade in of the loopstart sets in --> creating a hole. It is not mixed.
What do you think?
while the xfade branch may be a misnomer, please note that the back-ported implementation is not about cross-fading at the loop points. rather it's currently supposed to be just a small length fade-in/out on loop-start/end resp.
and yes the waveforms confirms just that (using super-longer fade-in/out lengths).
proper cross-fading is more complicated to implement but don't give up hope ;)
cheers
That is disappointing :(
I asked the Csound forum http://csound.1045644.n5.nabble.com/Csnd-how-to-floop-td5762234.html#a5762254 and someone came up with the math how to do it: http://www.csounds.com/udo/displayOpcode.php?opcode_id=55
Also, in the code from the looping opcodes from Csound i see some crossfading done around line 600: https://github.com/csound/csound/blob/develop/Opcodes/sndloop.c
but that's all abracadabra to me....
that's all about xfading i could find on the internet.
todays latest commit [001738] on "xfade" branch has some real cross-fading at loop-points cooking in...
as said, don't give up :)
cheers
Related
Commit: [001738]
wow...didn't realize you were still at it :)
I'll be happy to do the betatesting tonight and report back!
even more bumming under the radar [0c43be]
cheers
Related
Commit: [0c43be]
This time i get some ticks in the loop, probably some DC offset - see attachments
How many samples are the fade outs/ins at the moment?
Last edit: Menno 2018-06-15
somehow a read that DCoffset.wav has serious bad audio data: it clips way over the +inf/nan on the last half...
i fear is no good evidence here :/
Yes, DCoffset is the result of Samplv1 i recorded in AUdacity.
I have made a video and will wetransfer it to you, along with the loop i use. Perhaps you can replicate it.
I think it has to do with the end of the loop when this is set at the very end of the sample. I tries to find the beginning of the loop (which is in this case the very beginning of the sample also) .
Please have a good look at the sample counter, when i change to one sample shorter, it loops all right, but one sample longer the DC oddfset starts and the sample loops no more - as you can see while i continue to play the note on the keyboard.
Here is the sample i use so you can try out for yourself.
I'll send the video to you at your address: rncbc at rncbc dot org
my bad, cross-fading on loop-edges that are over or very near the end of the sample was indeed FUBARing the audio rendering--making up for dang loud and way over the top 0dBfs
that is now fixed on [f3186d]
sorry for the disturbance it may have give you
hope no speakers were smoked down there:)
cheers
Related
Commit: [f3186d]
No problem, i am used to smoking speakers....i am doing some betatesting for other programs as well...
Because i am not a programmer but a user, i feel betatesting is the one thing i can do in return. I'm a betatester for another program as well and the goal is always to make things better :)
And, of course, in this case, i want Samplv1 to work fantastically because it is the only Linux sampler that i know of. and the basic functionality is nearly complete.
(At one point, i want to write a manual for the program. Not a manual that only explains the functions, but more what you can do with it musically)
i will continue the betatesting once i get rid of all the smoke in my room and report back -
Q: is it your intention to be able to set the amount of xfade in time (or samples)?
yes. it probably will be exposed as property parameter; currently it's given in number of frames(samples) with (old) default value of 32 (it will be 0 in near future; only a value greater than 0 enables the loop cross-fading.
byee
i have done some new tests with the sample file you already have, 'plopmono.wav'.
I have recorded the result in Audacity.
First, i have set a loop in the sample and play it. When i play the sample lower, you can hear and see in Audacity that there are sudden changes in the sound caused by the loop - for example as second 7.828.
The fade out/in are possibly long long enough to smooth this out?
Attached are the .samplv1 file and the AUdacity mp3
Last edit: Menno 2018-06-16
todays latest commit [f1bb0c] might get smoother results
cheers && thanks
Related
Commit: [f1bb0c]
hi, loop crossfade control is now accessible on the UI, stored and restored as a parameter, as same as the loop start/end points.
check [512a6e] on 'xfade' branch.
please test && tell.
cheers
Related
Commit: [512a6e]
i have tested and will tell:
yesterday and today when recoding the loops in Audacity, i notice 3 samples out-of-line. They spil all the fun. They are not in line with the rest of the fades and i do not have a clue why this is happening.
When the sample is loaded at its original place C4 and played at C4, all goes well - perfect fades.
Playing lower ánd higher notes reveales those 3 samples that wish not to be tamed!
Please have a look at the attachment.
when played lower than C4:
- 4.72840
- 8.72514
- 14.11655
all goes well with C4 - at:
- 16.52370
again, 3 samples not in line when higher than C4:
- 19.13562
hi,
please try to provide at least the original audio sample (.wav) the .samplv1 preset files whenever you find something not sounding right as it should :)
let here be told that this new loop-crossfade is just an option in addition; most of the time and to my subjective ears perhaps, the current zero-crossing-auto-adjustment-of-loop-points default strategy--which is still in place nevertheless--is in overall the best strategy alone: fact is, i do also get this kinda annoying glitches and artifacts whenever the crossfade option is active (ie. xfade > 0) and only on some non-trivial/non-tonal samples...
as always, of course, YMMV.
you tell me.
Last edit: Rui Nuno Capela 2018-06-19
sure.
I'll give you
1. the sample plopmono (sorry as i thought i had already send it)
2. the plopjes .samplv1 file
3. 3. the wav and times of ticks you have already: sunday_version.mp3
What does YMMV mean? My gues is Your then something...
Last edit: Menno 2018-06-19
Your Mileage May Vary :)
your findings seem to go back from this late sunday;
code in xfade branch has changed a bit since then, i hope for the better but it does not invalidade any of what i told on my previous comment (before the YMMV:))
cheers
Last edit: Rui Nuno Capela 2018-06-19
fyi.
just in case you've been missing the (bleeding) edge... the "xfade" branch is on a so called "cliff-hanging" stage, about to merge into master very, very soon... also, the vee-one bunch release will follow shortly thereafter...
however, sf.net git repos are experiencing some intermittent out-of-sync issues... please retort to github, gitlab or bibucket repos if you wish to be on par to the latest code, whatever ;)
all the best