Reply to thread

Message: [QUOTE="Bombastus, post: 92282, member: 2178"] DevOcean can collapse a selected group of modules and their internal wiring into one Capsule without rebuilding the signal path by hand. Cables that cross the selection boundary become Capsule inputs or outputs automatically, so the new node keeps the original connections intact. This is more useful than simply making a crowded canvas look tidy. A Capsule can become a reusable instrument or effect with its own exposed controls, front panel, artwork, labels, displays, and compiled file, which moves the idea from patch organization into something you can actually hand to another user. The distinction matters because [B][URL='https://goldmidi.com/community/threads/ocean-swift-expanded-devocean-modular-1-2-with-35-modules.77648/']DevOcean Modular 1.2 Capsule customization[/URL][/B] adds more surface-level styling, but the deeper workflow already lives underneath it. You decide what stays buried, what reaches the front panel, and how much of the original patch the player ever needs to see. [HEADING=2]Capsules turn patch structure into a usable instrument[/HEADING] Creating one starts with the patch you already have. Select the modules that belong together, group them into a Capsule, and the internal graph folds into a single node while boundary connections are promoted to ports. Open the Capsule again, and you get its own internal canvas rather than a frozen black box. Capsules can also sit inside other Capsules. DevOcean keeps a breadcrumb path through the hierarchy, so a complicated instrument can be split into smaller functional sections without forcing every oscillator, envelope, filter, and utility onto the top-level canvas. Hardware I/O is the exception, since the master audio outputs and DAW Bridge nodes have to remain at the top level. You can even give a Capsule an internal description that appears when someone hovers its header. DevOcean does this through a Text Label named Capsule Description inside the Capsule, which is a small feature but a practical one once your library contains several custom instruments with similar names. The automatic port creation is easy to underrate. It means you can patch the musical idea first and decide on the Capsule boundary later, rather than designing an interface before you know what the patch needs. Moving from experiment to reusable component becomes a cleanup job instead of a second wiring session. [HEADING=2]The front panel decides what the player gets to touch[/HEADING] Capsule Manager is where the sub-patch stops behaving like a private construction and starts behaving like an instrument. Instead of exposing every adjustable value, you choose the parameters worth playing and arrange them on a designed face with controls, meters, artwork, panels, text, and mirrored displays. This selective surface is the important part. A synth may need dozens of internal values to function while only requiring cutoff, decay, movement, tone, and level on the front. The old [B][URL='https://doi.org/10.1145/361598.361623']information-hiding model for modular systems[/URL][/B] fits surprisingly well here because the implementation can stay complex while the usable interface remains deliberately narrow. DevOcean 1.2 pushes the visual side further with font and sprite skinning, styled input and output labels, hyperlink labels, and exposable XY or sample views. Those additions matter most after the control set is already disciplined. A beautiful panel with thirty unnecessary knobs is still thirty unnecessary knobs. [HEADING=2]Compiled modules keep the patch portable and reusable[/HEADING] Once the Capsule is finished, DevOcean can compile it into a single .osmodule file. The package carries the patch and its artwork, and it can optionally carry the samples the instrument needs, which removes a common failure point when a sound leaves the machine where it was built. Installation is correspondingly simple. A recipient places the compiled file in the DevOcean Modules folder and uses it as a module, rather than reconstructing the original graph or hunting for its internal pieces. The underlying patch complexity remains available to the creator without becoming part of the recipient's normal workflow. Sample-based Capsules deserve extra care before compilation. An instrument that depends on local audio files is only portable when those assets travel with it, so the option to include samples is not cosmetic packaging. It is what keeps a sampler-driven module from arriving with a polished face and missing source material. This also changes how you can maintain your own library. A useful filter block, sequenced texture, percussion generator, or complete synth does not have to remain trapped inside the project where you first built it. Compile it once, give it a sensible face, and it can become a repeatable building block across later patches. The strongest Capsule designs usually expose less than the raw patch makes possible. Keep tuning, calibration, routing, and fragile internal dependencies away from the front unless the player genuinely benefits from changing them. Give the outside world the few controls that change the musical result, while the rest stays where it belongs inside the Capsule. [/QUOTE]

Name