crossfading between loop points?


    Jan 04 2007 | 5:56 pm
    hello,
    I'm pretty sure this subject has been covered but I have the well known 'clicks' when my loop changes 'loop points'.
    in more detail, i use a 'groove' object which chops an audio loop into 16 smaller pieces. In order to succed that i calculate the total duration of the audio sample and then devide this value by 16. Then the start and end points are changing accordingly to the value 'totalduration / 16'. However, when the loop points move I get audio clicks (mainly with bass loops,etc. with drumloops sounds ok for obvius reasons).
    any ideas/techniques are used in these situations?
    thanks,
    mike

    • Jan 04 2007 | 6:11 pm
    • Jan 04 2007 | 6:22 pm
      Hi Francisco and thanks for the reply.
      I have alredy used xgroove~ from this library but as far as I'm concerned this object allows you to fade in and out only at the beginning and the end of the loop. What I really need is 'something' that can also fade between the loop points (when these change).
      thanks,
      mike
    • Jan 04 2007 | 6:36 pm
      Im not an MSP~ guy, but I think the solution was to use to groove
      objects. There was recently a discussion about this however on the
      forum.
      On Jan 4, 2007, at 1:22 PM, michael wrote:
      >
      > Hi Francisco and thanks for the reply.
      > I have alredy used xgroove~ from this library but as far as I'm
      > concerned this object allows you to fade in and out only at the
      > beginning and the end of the loop. What I really need is
      > 'something' that can also fade between the loop points (when these
      > change).
      >
      > thanks,
      > mike
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Jan 04 2007 | 7:08 pm
      Hello,
      I am trying to make a patch that sort of does a similar thing. I want
      to be able to change the loop time in real time without getting
      clicks (I don't need cross-fading). I'v tried many different
      possibilities but still get glitches when there are sudden changes.
      I'v read all the previous posts but there doesn't seem to be a
      solution. could someone please recommend anything?
      Thanks
      Peiman
      On 4 Jan 2007, at 18:36, vade wrote:
      > Im not an MSP~ guy, but I think the solution was to use to groove
      > objects. There was recently a discussion about this however on the
      > forum.
      >
      > On Jan 4, 2007, at 1:22 PM, michael wrote:
      >
      >>
      >> Hi Francisco and thanks for the reply.
      >> I have alredy used xgroove~ from this library but as far as I'm
      >> concerned this object allows you to fade in and out only at the
      >> beginning and the end of the loop. What I really need is
      >> 'something' that can also fade between the loop points (when
      >> these change).
      >>
      >> thanks,
      >> mike
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
    • Jan 04 2007 | 7:22 pm
      I believe the solution was to fade out at the end of the loop in
      groove 1 while simultaneously fading in the beginning of the loop in
      groove 2. Sorry if this is unhelpful, but it sounds (no pun intended)
      like it should work.
      On Jan 4, 2007, at 2:08 PM, peiman khosravi wrote:
      > Hello,
      > I am trying to make a patch that sort of does a similar thing. I
      > want to be able to change the loop time in real time without
      > getting clicks (I don't need cross-fading). I'v tried many
      > different possibilities but still get glitches when there are
      > sudden changes. I'v read all the previous posts but there doesn't
      > seem to be a solution. could someone please recommend anything?
      > Thanks
      > Peiman
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Jan 04 2007 | 7:36 pm
      vade , you are right.
      This is what I'm tryin to do. I use 2 groove~ and for each one i multiply the output with a cycle~. Also, the second cycle~ (for the 2nd groove~) is phase inverted with the first one. Both have an offset to avoid the minus values.
      Unfortunatelly, it doesn't seem to work well..
      thanks,
      mike
    • Jan 04 2007 | 8:41 pm
      you can use the sync output of groove~ for controlling a phase-driven amplitude envelope like trapezoid~
    • Jan 04 2007 | 9:32 pm
      thank you julien.
      This helps a lot! simple and acurate.
      However, I', still getting some 'clicks' periodically.Is there anything I can do to improve it even more?
      thanks,
      mike
    • Jan 04 2007 | 10:04 pm
      To be more specific, I realised that clicks depend on the duration of the sample. for example, the smaller the total duration is, the more clicks I get (unless I increase the Lo and Hi points of trapezoid~).
      Is it possible somehow to calculate the correct values of the Lo/Hi points for each seperate sample?
      Thanks,
      mike
    • Jan 04 2007 | 10:29 pm
      Quote: warp wrote on Thu, 04 January 2007 23:04
      ----------------------------------------------------
      > To be more specific, I realised that clicks depend on the duration of the sample. for example, the smaller the total duration is, the more clicks I get (unless I increase the Lo and Hi points of trapezoid~).
      >
      > Is it possible somehow to calculate the correct values of the Lo/Hi points for each seperate sample?
      >
      > Thanks,
      > mike
      >
      ----------------------------------------------------
      Mike, is it possible for you to post a patch that demonstrates what you've done so far and illustrates your problem?
      Mattijs
    • Jan 04 2007 | 10:33 pm
      Hi Mattijs,
      Thank you for the interest but I'm afraid my patch at the moment it's too messy and complex. It contains about 10 subpatches..
      thanks,
      mike
    • Jan 04 2007 | 10:53 pm
      Thanks for your reply Julien,
      I did try that but the problem is that changing the looping points
      (with control signals) is not precisely synched with the output of
      trapezoid~ which means that I still get the occasional clicks. I have
      not managed to figure out how to use audio signals to change the
      looping points in synch with trapezoid~ (using sah~ I suppose it
      should be somehow possible).
      Best
      Peiman
      On 4 Jan 2007, at 20:41, julienbreval wrote:
      >
      > you can use the sync output of groove~ for controlling a phase-
      > driven amplitude envelope like trapezoid~
    • Jan 04 2007 | 11:00 pm
      Quote: warp wrote on Thu, 04 January 2007 23:33
      ----------------------------------------------------
      > Hi Mattijs,
      >
      > Thank you for the interest but I'm afraid my patch at the moment it's too messy and complex. It contains about 10 subpatches..
      >
      > thanks,
      > mike
      ----------------------------------------------------
      When I post a problem to this forum I isolate it to a minimum that illustrates the problem clearly. This sometimes takes a few hours (the patches I work on are huge) but gives people the possibility to answer very quickly and accurately because they are able to reproduce the problem and see whether I made some obvious mistake.
      Sometimes while making the example I encounter the problem myself ;)
      I would advise you to take that time.
      In the mean time I think the only way to avoid clicks is naturally to use two groove~s (or I mostly use wave~ + phasor~) and fade between them for say 5 ms when the play position encounters a discontinuity.
      But when you change a loop point in real time it's different, theoretically there is no way that you can make your system anticipate an unexpected play cursor change unless you are willing to trade some timing accuracy. Although especially for a bass sound (where clicks are most likely to occur but also exact timing is slightly less important), the latter might be a solution.
      Greets,
      Mattijs
    • Jan 04 2007 | 11:09 pm
      Thank you all for the replies.
      I'll try to simplify my patch and post it as soon as I find some free time...
      Untill then I think I'll adjust manually the lo/hi points of the trapezoid~ for every sample :)
      thanks,
      mike
    • Jan 05 2007 | 1:04 am
      Quote: warp wrote on Fri, 05 January 2007 00:09
      ----------------------------------------------------
      > Thank you all for the replies.
      > I'll try to simplify my patch and post it as soon as I find some free time...
      >
      > Untill then I think I'll adjust manually the lo/hi points of the trapezoid~ for every sample :)
      >
      > thanks,
      > mike
      ----------------------------------------------------
      I somehow felt like trying. The way I would approach a crossfade on loop in general I guess would be like the patch below. Btw this doesn't deal with clicks when changing looppoints yet.
      It's done quickly after bed-time so it might be a bit messy.. but who knows, maybe it gives you some new ideas.
      I also found a nice sample to test with. I attached it.
      Greets,
      Mattijs
    • Jan 05 2007 | 10:11 am
      Your loop points are A and B; your crossfade length will be, let's say,
      100 ms.
      Apply a 100 ms fade in to A - 50 ms and a 100 ms fade out to B - 50 ms.
      This is a matter of peek~ and poke~, ok ? Then, add this two lovers in a
      buffer, and copy them at the exact same place you took them, to A - 50
      and B - 50. To avoid the now coming starting click you could :
      - use the fe.nocut~ abstraction i left on the list a few weeks ago
      - do a copy of the loop (loop x 2) in the buffer, leave the first one
      alone, do the crossfade to the last one. Loop points in groove~ are
      really sexy. You can say "play from the beginning, now loop from 1000 to
      4000"...
      You could also wait for an hypothetical release of my fe.objects which
      will contain an fe.Xfade~ that automatically do this in a blink of an eye.
      f.e
      f.e chanfrault | aka | personal computer music
      > >>>>>> http://www.personal-computer-music.com
      > >>>>>> |sublime music for a desperate people|
      michael wrote:
      > Thank you all for the replies.
      > I'll try to simplify my patch and post it as soon as I find some free time...
      >
      > Untill then I think I'll adjust manually the lo/hi points of the trapezoid~ for every sample :)
      >
      > thanks,
      > mike
      >
      >
    • Jan 05 2007 | 10:37 am
      peiman khosravi wrote:
      > Hello,
      > I am trying to make a patch that sort of does a similar thing. I want to
      > be able to change the loop time in real time without getting clicks (I
      > don't need cross-fading). I'v tried many different possibilities but
      > still get glitches when there are sudden changes. I'v read all
      > the previous posts but there doesn't seem to be a solution. could
      > someone please recommend anything?
      You need to change the looptime while its playing parts which are in
      both loop regions. Or, if that's logistically not possible, use two
      grooves, (if they don't contain similar parts there is no syncronisation
      problem).
      You could also try to do it with play~ instead of groove~, as you have
      better control over absolute position within the soundfile... If you
      jump, you can also fadein/out...
      Of course, you need to change to clickles loop points elsewise your
      claim of "I don't need cross-fading" would be wrong...
      just suggestions...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Jan 05 2007 | 12:30 pm
      have u checked the grooveduck patches in the examples folder?
      specifically designed to "duck" at the loopoints... but they still click occasionally, mainly with sudden large changes in loop length.
      maybe it's possible to improve it...
      j
    • Jan 05 2007 | 12:59 pm
      Quote: warp wrote on Thu, 04 January 2007 23:04
      ----------------------------------------------------
      the smaller the total duration is, the more clicks I get (unless I increase the Lo and Hi points of trapezoid~).
      >
      > Is it possible somehow to calculate the correct values of the Lo/Hi points for each seperate sample?
      ----------------------------------------------------
      As you know the duration of each sample (for example, between 10ms and 100ms), you can program something that changes the parameters of trapezoid~ in function of the sample duration.
      For example, you can decide that the parameters of trapezoid~ are "0.5 0.5" for 10 ms and "0.1 0.9" for 100 ms; then you can use something like zmap for calculating the other values in function of the sample duration (between 10 and 100 ms here).
      If you choose this solution, the calculus must be done just before playing each sample (ie when the amplitude enveloppe has a value of 0).
    • Jan 05 2007 | 1:01 pm
      Quote: peimankhosravi@gmail.com wrote on Thu, 04 January 2007 23:53
      ----------------------------------------------------
      I have not managed to figure out how to use audio signals to change the looping points in synch with trapezoid~ (using sah~ I suppose it should be somehow possible).
      ----------------------------------------------------
      yes, sah~ and probably also delta~ and edge~
    • Jan 05 2007 | 2:36 pm
      Hello,
      Thanks everyone for your replies. I'v written a patch that
      theoretically should work (I think!). But for some reason I am not
      getting any audio. I would appreciate any suggestion.
      Thanks in advance
      Peiman
      Here's the patch:
      max v2;
      On 5 Jan 2007, at 13:01, julienbreval wrote:
      >
      > Quote: peimankhosravi@gmail.com wrote on Thu, 04 January 2007 23:53
      > ----------------------------------------------------
      > I have not managed to figure out how to use audio signals to change
      > the looping points in synch with trapezoid~ (using sah~ I suppose
      > it should be somehow possible).
      > ----------------------------------------------------
      >
      > yes, sah~ and probably also delta~ and edge~
      >
    • Jan 05 2007 | 3:21 pm
      On 05 Jan 2007, at 15:36, peiman khosravi wrote:
      > Hello,
      >
      > Thanks everyone for your replies. I'v written a patch that
      > theoretically should work (I think!). But for some reason I am not
      > getting any audio. I would appreciate any suggestion.
      you can't have a signal-feedback loop like that. you would have to
      introduce at least one signal vector of delay, which in your case
      would spoil the whole idea of the feedback.
      so, why not use somthing else than groove~?
      i think it's much easier when you can control the playback pointer
      yourself.
      below is a solution with phasor~ and play~.
      + no-click-guarantee.
      volker
    • Jan 05 2007 | 3:56 pm
      Hello volker,
      Thanks for the patch it is exactly what I was after. And I can't here
      any clicks which is great :)
      Thanks again
      Peiman
      On 5 Jan 2007, at 15:21, vb wrote:
      >
      > On 05 Jan 2007, at 15:36, peiman khosravi wrote:
      >
      >> Hello,
      >>
      >> Thanks everyone for your replies. I'v written a patch that
      >> theoretically should work (I think!). But for some reason I am not
      >> getting any audio. I would appreciate any suggestion.
      >
      > you can't have a signal-feedback loop like that. you would have to
      > introduce at least one signal vector of delay, which in your case
      > would spoil the whole idea of the feedback.
      > so, why not use somthing else than groove~?
      > i think it's much easier when you can control the playback pointer
      > yourself.
      >
      > below is a solution with phasor~ and play~.
      > + no-click-guarantee.
      > volker
      >
      > #P window setfont "Sans Serif" 9.;
      > #P window linecount 1;
      > #P comment 125 146 100 196617 playbackposition;
      > #P newex 330 231 29 196617 sig~;
      > #P newex 330 314 35 196617 sah~;
      > #P newex 166 207 29 196617 * 1.;
      > #P user multiSlider 71 161 197 21 0. 1. 1 2680 47 0 0 2 0 0 0;
      > #M frgb 0 0 0;
      > #M brgb 206 206 206;
      > #M rgb2 127 127 127;
      > #M rgb3 0 0 0;
      > #M rgb4 37 52 91;
      > #M rgb5 74 105 182;
      > #M rgb6 112 158 18;
      > #M rgb7 149 211 110;
      > #M rgb8 187 9 201;
      > #M rgb9 224 62 37;
      > #M rgb10 7 114 128;
      > #P flonum 185 121 58 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
      > #P newex 107 95 105 196617 info~ pi;
      > #P newex 355 283 39 196617 > #P flonum 197 244 56 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
      > #P newex 233 314 35 196617 sah~;
      > #P newex 197 277 29 196617 sig~;
      > #P newex 233 364 79 196617 +~;
      > #P newex 414 192 49 196617 !/ 1000.;
      > #P flonum 330 159 54 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
      > #P flonum 414 216 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
      > #P newex 414 236 46 196617 phasor~;
      > #P hidden newex 336 83 66 196617 loadmess 77;
      > #P toggle 252 477 15 0;
      > #P newex 285 510 31 196617 dac~;
      > #P newex 285 465 33 196617 *~;
      > #P newex 302 341 38 196617 *~ 10;
      > #P newex 414 405 100 196617 trapezoid~ 0.01 0.9;
      > #P message 123 42 43 196617 replace;
      > #P newex 123 69 82 196617 buffer~ pi 1000;
      > #P newex 285 410 46 196617 play~ pi;
      > #P comment 391 161 100 196617 loop size;
      > #P connect 2 1 19 0;
      > #P connect 3 0 2 0;
      > #P connect 21 0 22 0;
      > #P connect 19 6 20 0;
      > #P hidden connect 20 0 22 1;
      > #P fasten 22 0 17 0 171 233 202 233;
      > #P connect 17 0 15 0;
      > #P connect 15 0 16 0;
      > #P connect 16 0 14 0;
      > #P connect 18 0 16 1;
      > #P fasten 14 0 1 0 238 391 290 391;
      > #P connect 1 0 6 0;
      > #P connect 6 0 7 0;
      > #P fasten 8 0 7 0 257 497 290 497;
      > #P fasten 10 0 5 0 419 272 307 272;
      > #P connect 5 0 14 1;
      > #P fasten 6 0 7 1 290 494 311 494;
      > #P fasten 4 0 6 1 419 455 313 455;
      > #P hidden connect 9 0 12 0;
      > #P connect 12 0 24 0;
      > #P connect 24 0 23 0;
      > #P connect 23 0 5 1;
      > #P connect 10 0 18 0;
      > #P connect 18 0 23 1;
      > #P connect 12 0 13 0;
      > #P connect 13 0 11 0;
      > #P connect 11 0 10 0;
      > #P connect 10 0 4 0;
      > #P window clipboard copycount 26;
      >
      >
    • Jan 05 2007 | 5:34 pm
      i'm a little late in this thread...
      but in case somebody is still wondering how to do the _crossfade_
      version clickless etc.
      here is another way one could go about it.
      volker.
      >> + no-click-Garantie!
    • Jan 06 2007 | 1:45 am
      nice toy :-)
    • Jan 06 2007 | 12:11 pm
      hi fp
      >
      > nice toy :-)
      yeah, nice.
      although for this approach you wouldn't need the x-fade technique i
      posted,
      cause by giving different loop sizes for the two players they are out
      of sync anyway.
      cheers,
      vb
    • Jan 08 2007 | 4:41 pm
      Quote: Mattijs wrote on Fri, 05 January 2007 02:04
      ----------------------------------------------------
      > I somehow felt like trying. The way I would approach a crossfade on loop in general I guess would be like the patch below. Btw this doesn't deal with clicks when changing looppoints yet.
      I was looking at my try again and saw that there was a mistake. Here is an update.
      Mattijs
    • Jan 12 2007 | 11:06 pm
      Hi, Volk, I fianlly noticed that I posted my message under the wrong topic prevsiouly.
      I am still trying to figure out the 2nd patch. I was wondering how does the X-fade length in the 2nd patch affect the result. All if it should always be 114 in that patch ?
      Regarding the 1st patch, I think I figure it out.
      Please let me know if I misunderstood it.
      I think the saw tooth wave generated by phasor~ actually "ramp down" very fast so as long as sah~ hold the sample during the "ramp down" of the saw tooth wave, it is safe.
      And 1000 refers to 1 sec for frequency calculation.
      Does phasor~ actually "abruptly drop down" from 1 to 0 ? Or does it gradually "ramp down" ?
      If it abruptly drops down in no time, then it makes sense to me that sah~ samples the input when comparison result transits from 0 to 1 and makes no click.
      Do I think correctly about the 1st patch ?
      Thank you very much.
    • Jan 13 2007 | 12:44 pm
      On 13 Jan 2007, at 00:06, Cheng Chien-Wen wrote:
      >
      > Hi, Volk, I fianlly noticed that I posted my message under the
      > wrong topic prevsiouly.
      >
      > I am still trying to figure out the 2nd patch. I was wondering how
      > does the X-fade length in the 2nd patch affect the result. All if
      > it should always be 114 in that patch ?
      have you tried changing it? with longer values the crossfade is
      longer and therefore more blurry. with short values you accent the
      loopstart/endpoints. if you have trouble hearing the differences, you
      can observe this visually:
      in the player subpatches, create a second outlet and connect the
      [cycle~ env] object to this outlet.
      connect [scope~] objects to the newly created outlets and obeserve
      the envelopes on overlaps of both envelopes with different crossfade
      lengths.
      >
      > Regarding the 1st patch, I think I figure it out.
      >
      > Please let me know if I misunderstood it.
      >
      > I think the saw tooth wave generated by phasor~ actually "ramp
      > down" very fast so as long as sah~ hold the sample during the "ramp
      > down" of the saw tooth wave, it is safe.
      >
      > And 1000 refers to 1 sec for frequency calculation.
      >
      > Does phasor~ actually "abruptly drop down" from 1 to 0 ? Or does it
      > gradually "ramp down" ?
      >
      > If it abruptly drops down in no time, then it makes sense to me
      > that sah~ samples the input when comparison result transits from 0
      > to 1 and makes no click.
      >
      > Do I think correctly about the 1st patch ?
      yes. there is no "ramp down" when phasor~ approaches the value 1. it
      is an "abrupt" jump back to 0 (to be precise, to some value near 0).
      don't forget that time inside your computer is discrete. so even
      though the sampling interval is a real time-interval (depending on
      the sampling rate), inside your machine there is _no_ data (or ramp
      down in your case) between consecutive sample points.
      try recording the output of a phasor~ to a buffer and look at the
      values.
      hope that helps.
      volker.