Do visualizers impact processing overhead?

edited April 2023 in How to's

tl;dr: should I be deleting oscilliscopes, midi monitors, etc from my patch if I want to gain processing overhead?

I realized I've been doing this instinctively, but I don't know if these are done on a separate thread or what. A bunch of oscilloscopes does seem to raise the processing overhead bar (the 5 dots in the top right) but I also know that this metric is flawed. I assume they have some impact, but is it enough that its worth thinking about?

Comments

  • A follow-up question: does hiding these with a section or in a folded rack change the impact much?

  • Do you mind me asking a question because Im not as advanced as you and I have been wondering about those upper right corner dots and whatnot. Why does it seem to capture audio when doug in the sound test room is recording? Also, what would processing overhead affect and why are you concerned about it? Like is there some performance issue or output mixdown issue you noticed (what device/processor+ram are you using)?

    Thanks for letting me ask you a question about the issue so as to know what to look for myself (as i had issues lately myself).

  • edited April 2023

    As I understand it those dots indicate the amount of processing iOS is using (I think on the specific core?). But I think iOS will do things as you use more of a core to give heavier processes more cycles (e.g. maybe move other processes off the core), so the bar can be misleading.

    I'm worried about this as a performance issue. I have an iPad Air 4th generation and I'm fairly near hitting the max I can safely use without glitches for a set I'm working on.

    There are things you can do to make things better (like sampling tracks you aren't going to edit again), but this set is all about live modulation of more drone-y patches so I'm trying to eek out whatever performance I can.

    I asked about oscilloscopes specifically because I am using them to monitor LFOs I am tweaking, but if they are taking like... multiple % of the processor I'd get rid of them. I have 32 currently lol

  • I also wonder about this, and whether it helps to hide the oscilloscopes inside layers or foldable sections etc, and whether I should worry if I put lots of lfos in my rack, since they can go to destinations that can be audio-rate modulated, or whether the implementation of these are always super-efficient since they are low frequency and don't need so high sample rate.

    Have never noticed that those dots had any meaning:)

  • Well I can safely say that adding 32 oscilloscopes to a heavy (3-4 dots) project can push it over the edge into being overloaded and glitching (5 dots yellow). So it goes. More motivation to pick up an M3 iPad when they come out.

  • It would definitely be interesting to know whether elements like oscilloscopes are still eating cpu when they aren’t visible. I guess the question is whether they are optimised and I see generally @giku being quite good at making things efficient.

    I have 1 or 2 of them here and there so not too worried about it but 32 is a respectable figure 💪

  • edited April 2023


    what do you need 32 scopes for?

    the new probe mode shows me what I want to see ... 😃

    basically delete every unnecessary module ...

  • I have a live set where I am controlling everything via 24 LFOs and 8 euclids. Its nice to have feedback on what those modules are doing. Loading scopes manually while performing is not really an option.

    Its reasonable that 32 scopes causes a hit to the processing for sure :) its definitely a bit "overkill". If there was a module that was a grid of LEDs we could light up I'd just use that.

  • One thing I may try for my use case is to create 4 scopes and use N-to-1 modules to pipe the outputs for the track I am actively tweaking to the scopes.

Sign In or Register to comment.