Announcement

Collapse
No announcement yet.

Anyone else having quantize/sync problems 1.36?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Anyone else having quantize/sync problems 1.36?

    I'm having some issues with sync.
    A simple example is taking a basic loop and attempting to clock it.

    1. load the loop
    2. slice the loop (manual or scan, doesn't make a difference)
    3. Quantize loop to 1/16
    4. Sync loop to slice
    5. Pitch loop to taste
    6. Set to trigger mode (so it plays the whole loop)

    Triggering this with the BitBox receiving an incoming clock from the clock out of a Grayscale Algorythm, directly from the clock output of a Doepfer A-154, or directly from a square wave pulse from Pamela's New Wrokout - all the same results.

    Gate being sent from the Grayscale Algorythm at step 1 (8 steps)

    Results:
    Loop will play correctly a few times, and then stop for 1-3 beats and begin to play out of time. After a cycle or two BitBox will "self correct" and get back in sync.

    Seems like there's some sort of quantize timing lag, or delay?

    The frustrating part of this is that it is not consistent. Thus, there isn't anything I can do to produce the error. It just seems to sort of happen sometimes. I have tried increasing the load on the power supply (Intellijel 7u performance case with stock Intellijel power/with the grounded Meanwell power adapter GS90A15 P1M - not the stock ungrounded version) by playing all sort of things and doing stuff.
    Adding a bunch of sounds, taking all the other sounds away, and really there is no predicable rhyme or reason to this.
    I can't seem to "make it do it" any easier than I can stop it from doing it.

    Further:
    Just programming a 4 x 4 kick drum. The kick will play in time, as triggered, but then as things happen, or time passes it will begin to skip kicks.
    Seems like the same problem.

    NOTES:
    This feels, in practice, like a polyphony issue (which doesn't make sense) but if you've ever played with a device which doesn't have enough polyphony for what you're trying to do (notably a sampler) then you know this "feeling" of hitting the snare, and nothing happens, or the snare sounds, but the kick drops out.

    I've tried switching over to different trigger sources, and as I've noted, different clock sources, but the results are the same across the board.
    Interestingly enough this does not seem to happen when using MIDI clock. Naturally the immediate solution would be to just use MIDI clock, right? Well, sure... but that's not ideal.

    If no one else is having this problem, I'm glad to document it with a little clip and upload it here.
    I realize I'm working with beta software, and presumably an update is coming soon. It's ok, I'm not panicking, but I wanted to know if I was alone with this issue, and if everyone was well aware of it or not.

    Please advise?



  • #2
    Following up:
    I've been doing some exploration and learning things and so I thought I would reply here and share what I've found.

    It turns out that the PPQN of the clock being sent into bitbox is more or less the key to solving the problems illustrated above. I moved things around and am now supplying the bitbox with a bona fide 24 ppqn clock coming out of the ALM Pamela's NEW Workout at 4 x tempo (110) and the dropouts and misfires have completely stopped. I just gave it all a good go for about 2 hours and the bitbox didn't miss a beat.

    It's kind of a shame that with lesser clocks it's prone to idiosyncrasies, because most of my clock sources are old school type clocks (Doepfer etc.) and they seem to be the cause here.

    One thing I have not been able to solve is the loop playing after the clock has stopped:

    So I've got a 4 bar loop.
    It's sliced and triggered on the 1 from a gate sequencer (Grayscale Algorhythm) and it's looping great, staying in time and all is well.
    When I press stop anywhere before the end of the 4th bar, the loop needs to continue and play itself out to the end of its total length before it will stop.

    This is frustrating because when I press stop, and stop the clock, I want the loop to stop too.

    I've tried various sync modes - 1/16 seems to provide the best timing, but none of the settings effect when the loop stops.
    I've tried various playback modes:
    Trigger is best - but the loop plays to the end.
    Gate is tight, but only plays the first slice.
    Toggle is interesting, because if I knew where I was going to stop I could toggle it either manually, or with a gate but I don't so this won't really work.
    Repeat is a little mysterious to me, and it seems to work like toggle, however the loop still needs to play to the end before stopping.

    Is there a way to synchronize a loop, and have it stop playback when the clock stops? This would be extremely useful. But as it stands this is in the support section because I still think I'm not doing it right, and there must be something I don't understand here.

    Looking forward to your reply.

    Comment


    • #3
      Hi Sunshine,

      I'm happy to hear you've sorted out the clocking issues. Thanks for sharing the detailed info!

      There have been quite a few threads recently about this behaviour. I can confirm that bitbox doesn't currently support this.

      It's one of those little tweaks that could make bitbox so much better, so hopefully this can be included in a future firmware release.

      Comment


      • #4
        Sunshine,

        Thanks for the detailed notes. It sounds like there are two problems here:
        1) You would like samples to stop when the clock stops. We're using the idea that the clock is separate from playback. So, what you are seeing is by design.
        2) There are problems with loops dropping in and out, which doesn't sound right. Bitbox is meant to track 4PPQ. I'm surprised it works correctly at 24PPQ.

        Let's talk further about this one. Thanks for the help.

        Aaron

        Comment


        • #5
          Originally posted by Aaron View Post
          Sunshine,

          Thanks for the detailed notes. It sounds like there are two problems here:
          1) You would like samples to stop when the clock stops. We're using the idea that the clock is separate from playback. So, what you are seeing is by design.
          2) There are problems with loops dropping in and out, which doesn't sound right. Bitbox is meant to track 4PPQ. I'm surprised it works correctly at 24PPQ.

          Let's talk further about this one. Thanks for the help.

          Aaron
          Thank you for the reply Aaron,
          As I said I am using a 24PPQN source clock to correct the issue, and then dividing it down to 1/8 of clock which comes out roughly at 4PPQN. With this scheme the clocks are solid, and there are no dropouts.

          A source clock of less than 24 PPQN, (doepfer A-154 clock out) divided in some other way (or directly in this case) will reliably introduce dropouts.
          With midi - 24/48/96 PPQN (depending) - it is stepped down again to the desired clocking of 4 PPQN giving us a stable, solid clock source, which is then divided down to what is needed and there are no dropouts.
          Seems like a little ghost in the machines somewhere between quantize and clock is having a party!


          On loops continuing to the end instead of stopping when the clock is stopped, it seems to introduce a conundrum:

          I want to use a gate mode so that I can stop short, or unpredictably and perform dynamically. Yet, a "gate" per se is a very short friend, and will only essentially cause a trigger.

          This becomes semantics doesn't it?

          Gate: On/High = Activity - OFF/Low = No Activity
          Trigger: Pulse/On = Start Playback until the end
          Toggle: Pulse/Gate/On = Start Playback - Pulse/Gate/On again = Stop Playback

          These terms and actions considered, clock has nothing to do with it (hello!)

          I would love to have the ability to tie the clock's activity to the playback. Meaning when the clock stops, the playback stops.
          This is typical behavior for samplers and sampling drum machines and loopers, and thus it's why I expected it and assumed I was doing something wrong.
          It stands to reason that pressing top should in effect stop playback. No?

          The option to tie "stop" or clock ending with playback stop would be a coup for those of us who are hoping for live action loop playing.

          Comment


          • #6
            Hey all has this been addressed in an update? i just purchased a bitbox a couple weeks ago. and have it on the newest firmware. But still experiencing the issues...
            Thanks...

            Comment


            • #7
              Originally posted by Gentleman Bastard View Post
              Hey all has this been addressed in an update? i just purchased a bitbox a couple weeks ago. and have it on the newest firmware. But still experiencing the issues...
              Thanks...
              I have heard of some issues where very short (1ms) clock signals created problems. I'm not aware of a generic problem as of 2.1.1. Am I missing something? What hardware are you using to generate a clock? Thank you.

              Comment


              • #8
                Try triggering from your DAW where you can delay or advance the gate. Expert Sleepers , Reaktor or Reason do loads of great devices. You should be able to send a clock/gate with a DC coupled interface even (they just can't sustain CV's very well)

                Comment


                • #9
                  Originally posted by Aaron View Post

                  I have heard of some issues where very short (1ms) clock signals created problems. I'm not aware of a generic problem as of 2.1.1. Am I missing something? What hardware are you using to generate a clock? Thank you.
                  I'm clocking it with my Xor Nerdseq. I do have the midi I/o module so going to just snag a cable and run it from midi clock and see how that goes

                  Comment


                  • #10
                    There's the problem - the Nerdseq can't change the width of it's output clock. It's also not at 24ppqn.

                    Best just use MIDI. It works really well.

                    Comment

                    Working...
                    X