Reply to thread

Message: [QUOTE="Bombastus, post: 92289, member: 2178"] DevOcean does not run full audio-rate DSP for every module sitting on the canvas, even when a project has grown into a sprawling modular patch. Its engine evaluates what is actually live, skips expensive per-sample work for sleeping sections, and keeps idle polyphonic voices out of the hot path. Setting the global voice ceiling to 16 therefore does not mean sixteen voices are burning the same CPU all the time. A voice that is idle can be skipped even inside a polyphonic module that is still active for other notes. The ceiling defines how many voices may run, not a permanent processing bill. The [B][URL='https://goldmidi.com/community/threads/ocean-swift-expanded-devocean-modular-1-2-with-35-modules.77648/']DevOcean Modular 1.2 performance changes[/URL][/B] also include work on undo, the browser, and canvas polling. Those changes affect responsiveness around the patch, while the engine's sleep behavior deals with the heavier cost underneath it, the audio-rate math happening every block. [HEADING=2]Sleeping modules cut DSP work, but they still use memory[/HEADING] A module stays active when it belongs to a live signal path reaching an output, when a meter or scope is watching it, or when it still has something audible to finish. A reverb tail is the obvious case. Silence at the input does not instantly make a processor irrelevant if its internal state is still ringing out. Disconnected modules, bypassed effects, muted voices, and unused branches can stop doing their expensive per-sample processing. This lets you leave half-built ideas on the canvas without paying the same CPU price as if every experiment were feeding the output. It is particularly useful in modular work because deleting a branch just to reclaim processing time can wreck the way you explore. Sleep does not reclaim the module's RAM. DevOcean keeps the buffers associated with a module allocated while it exists, so a canvas packed with parked modules can remain light on DSP while still carrying a memory cost. CPU efficiency and memory efficiency are separate problems here. There is also a small baseline cost. Sleeping modules are still visited for lightweight block-level housekeeping such as clearing buffers or queues, checking which voices are live, and deciding whether a tail has finished. Idle means cheap, not nonexistent. [HEADING=2]Meters and scopes can quietly keep a branch awake[/HEADING] Meters, scopes, analyzers, and debug probes need fresh data to remain useful, so DevOcean keeps those observers running. A branch you think is merely parked may therefore stay live because a scope is attached to it. Removing or disconnecting unnecessary monitoring can change the work the engine considers necessary. The same principle applies to endpoint modules. Core anchors such as Audio Output and MIDI sources run every processing block because the patch depends on them as live endpoints. They are not candidates for the same sleep treatment as an abandoned oscillator sitting off to the side. This is where CPU troubleshooting gets more concrete than staring at the total module count. A patch with many dormant modules can be cheaper than a smaller patch whose expensive processors, analyzers, and long effect tails all remain active. The graph matters more than the headcount. Real-time audio always has a deadline to meet before the next buffer is due, and active processing eats into that fixed window. [B][URL='https://www.mdpi.com/2673-4591/134/1/97']Real-time granular DSP measurements[/URL][/B] show the same practical relationship between computational load and the amount of audio work being performed. DevOcean's sleeping strategy attacks the workload rather than pretending the deadline disappeared. [HEADING=2]Heavy patches still depend on buffers, tails, and live voices[/HEADING] Buffer size remains the blunt control when a patch starts struggling. Smaller buffers reduce playing latency but leave less time for the engine to finish each block, while larger buffers give demanding patches more breathing room. DevOcean lets you change buffer size while the engine is running, unlike its sample-rate and voice settings, which require the engine to be powered down first. Long reverbs, delays, dense polyphony, and continuously watched signal paths deserve more attention than modules that happen to occupy visual space. An idle voice can sleep, but an active voice still has real work to do. A delay that is fading out is also active until its tail reaches the point where the engine can stop processing it. Large patches therefore benefit from a simple habit. Leave experiments parked if you want, but disconnect monitoring you no longer need, bypass dead chains, and pay attention to which branches actually reach a live sink. The canvas can stay messy without forcing the DSP engine to behave as if every idea on it is currently playing. [/QUOTE]

Name