H9000 Control timing

Home Forums Products Rackmount H9000 Control timing

  • This topic is empty.
Viewing 5 reply threads
  • Author
    Posts
    • #149229
      nickrose
      Moderator
      Eventide Staff

      There is always a risk of "rubberiness" on a multiprocessor system, due to communication issues.

      But, I can tell you that the Orville UI processor ran at 25MHZ, whereas the one in the H9000 runs at 400MHZ. You can imagine that there is quite a difference in responsiveness.

      Why do we not run a 3GHz Intel ? Because the unit is expensive enough and big enough already. You would not want it to have the noisy fan from a PC.

       

      • #149233
        cbm
        Participant
        nickrose wrote:
        But, I can tell you that the Orville UI processor ran at 25MHZ, whereas the one in the H9000 runs at 400MHZ. You can imagine that there is quite a difference in responsiveness.

        Ignoring the front panel UI, a (very) crude way of analyzing this is that each Orville DSP engine got 12.5 MHz of clock cycles, and each H9000 will get double that. Better, but still not that great.

        At some point in the future, it would be great to be able to throw a DSP engine core at the control stuff in an effects chain. For much of the stuff I do, three DSP engines per chain would be plenty, and having more rhythimic stability is more important. I know that this presents some archetectual challenges, but it’s probably easier than communicating across chips.

         

      • #149239
        ThreeFingersOfLove
        Participant
        cbm wrote:

        nickrose wrote:
        But, I can tell you that the Orville UI processor ran at 25MHZ, whereas the one in the H9000 runs at 400MHZ. You can imagine that there is quite a difference in responsiveness.

        Ignoring the front panel UI, a (very) crude way of analyzing this is that each Orville DSP engine got 12.5 MHz of clock cycles, and each H9000 will get double that. Better, but still not that great.

        At some point in the future, it would be great to be able to throw a DSP engine core at the control stuff in an effects chain. For much of the stuff I do, three DSP engines per chain would be plenty, and having more rhythimic stability is more important. I know that this presents some archetectual challenges, but it’s probably easier than communicating across chips.

        If we take into account that it has 16 DSP, and the available UI computational resources are divided equally among those DSP, then indeed 25 MHz is not enough

    • #114739
      cbm
      Participant
       

      I’m wondering if there’s any improvement on the timing accuracy of things calculated at control rate. On my Orville, things calculated at control rate can get a little “lumpy”. I have patches that should be rhythmic, but only sort of are. I’ve always chalked this up to a week scheduler running on the CPU, which I’m sure can get busy. As I understand it, the H9000 has a fifth CPU that handles the UI and other system stuff. Is it enough faster to get the job done better than on the Orville? Given that there are many more DSP engines to service I worry that timing will stay a little erratic. 

       

      UI response can also be quite sluggish on the Orville. Any improvements on this for the H9000?

       

    • #149256
      nickrose
      Moderator
      Eventide Staff

      I would argue that however much bandwith you have, you can use it all up.

      I would also say that while you might have x amount of remote modulation for one dsp, you are unlikely to have 16x for 16 dsps.

      You would probably saturate the MIDI, if nothing else.

       

    • #149260
      cbm
      Participant

      This track tries to illustrate some of the timing problems when passing signals betweeen the audio and control sides of an Orville.

      In this algorithm, there are a series of 12 delays, in series. Each delay gets “blipped” to the output. The blip envelopes are generated from an LFO which gets passed to the control side to drive a counter and a bunch of comparators to decode the counter. The decoded triggers are passed back to the audio side to drive the envelopes.

      As you can hear, the rhythm is not so steady. If I had to guess, it sounds like a simple main loop scheduler on the control side. Hopefully this sort of thing will be much better in the H9000.

      .sig file upon request.

      https://soundcloud.com/cbm/bubble-timing-ex01/s-7L9P5

      • #149272
        ThreeFingersOfLove
        Participant
        cbm wrote:

        This track tries to illustrate some of the timing problems when passing signals betweeen the audio and control sides of an Orville.

        In this algorithm, there are a series of 12 delays, in series. Each delay gets “blipped” to the output. The blip envelopes are generated from an LFO which gets passed to the control side to drive a counter and a bunch of comparators to decode the counter. The decoded triggers are passed back to the audio side to drive the envelopes.

        As you can hear, the rhythm is not so steady. If I had to guess, it sounds like a simple main loop scheduler on the control side. Hopefully this sort of thing will be much better in the H9000.

        .sig file upon request.

        https://soundcloud.com/cbm/bubble-timing-ex01/s-7L9P5

        This is all over the place… Do the Orville and the H8000FW have the same UI refresh frequency?

        Show More...
        Show Less...
    • #149301
      cbm
      Participant

      After a few days more work on this algorithm, I have managed to migrate most of the timing and cell selection logic stuff to the DSP side, and the timing is solid there. The trouble is, the likely objects that I wanted to use to express the logic of this algorithm are on the control side, and may only have murky counterparts on the DSP side.

      For example, using an LFO to scan through a a bunch of sequencers seemed like a reasonable approach to generate triggers for the envelopes, but the LFO doesn’t have a true sawtooth, so all the sequencer stages fire during the LFO “flyback.” I worked around this by gating the output of the LFO when it was falling, which is a sort of ugly bandaid, involving a PICODELAY, COMPARATOR, BOUND, and CROSSIN.

      This sort of issue popped up a few times when trying to do moderately complex logic things on the DSP side. There are still a couple things I’m trying to improve in this patch, but it’s right on the edge of what the Orville will load. Here are a couple longish examples of the now usable patch in action:

      https://soundcloud.com/cbm/bubble-timing-ex02

      https://soundcloud.com/cbm/bubble-mod

      These are both real-time improvs

    • #149639
      jbamberg
      Moderator
      Eventide Staff

      On the Orville, and H8000FW, the central control processor runs the UI and also the control code of the algorithms.  So, UI responsiveness and control rate are intimately tied together.  The H9000 is different, in that the control code runs on the DSPs, but the UI still runs on the main control processor.  Effectively, what this means is that the control rate of the H9000 should be faster than on the Orville/H8000FW – not only is it not waiting for the UI, but it runs on a much faster processor (1GHz).  I don't have any actual measurements to back this up, but when I have some time to gather some, I will.

      Regarding the occasional slowness of the UI on the Orville/H8000FW, this should also be improved on the H9000 for the same reasons.   The central processor does a lot of tasks, including networking and MIDI, and the UI is also quite a lot more graphically complex, but we've done our best to keep it snappy and responsive.

       

      • #149655
        cbm
        Participant
        jbamberg wrote:

        On the Orville, and H8000FW, the central control processor runs the UI and also the control code of the algorithms.  So, UI responsiveness and control rate are intimately tied together.  The H9000 is different, in that the control code runs on the DSPs, but the UI still runs on the main control processor.  Effectively, what this means is that the control rate of the H9000 should be faster than on the Orville/H8000FW – not only is it not waiting for the UI, but it runs on a much faster processor (1GHz).  I don’t have any actual measurements to back this up, but when I have some time to gather some, I will.

        Regarding the occasional slowness of the UI on the Orville/H8000FW, this should also be improved on the H9000 for the same reasons.   The central processor does a lot of tasks, including networking and MIDI, and the UI is also quite a lot more graphically complex, but we’ve done our best to keep it snappy and responsive.

        It sound like control rate things might be in better shape on the H9000. Can you comment on what sort of scheduler is running the control stuff?

      • #149663
        jbamberg
        Moderator
        Eventide Staff
        cbm wrote:

        It sound like control rate things might be in better shape on the H9000. Can you comment on what sort of scheduler is running the control stuff?

        Well, the control code is run at a lower priority than the audio processing.  So, you can't rely on the control loop to execute with any particular frequency as it depends on how busy the DSP is doing real-time audio processing.  As the DSPs have four cores, the OS can spread the control processing across all of them, so if you have one or two algorithms that are very DSP intensive, they probably won't affect the control code too much, since it will just be scheduled on the cores that are less busy.

         

Viewing 5 reply threads
  • You must be logged in to reply to this topic.