What does RigWave actually do?

RigWave is a suite of Windows tools designed to check supported streaming setups, explain problems and guide setup-specific changes.

No. The product direction is researched rules, measurements, known platform requirements and repeatable coded logic applied to what RigWave can actually detect. AI may be used in development work, but the customer product is not meant to invent streaming or audio settings on the fly.

No. RigWave is there to help the PC, audio path and supported software work together more clearly. It does not replace OBS, your DJ software, your ears, your mixing skill or your creative decisions.

No, and that distinction matters. RigWave is not a generic PC cleaner, antivirus tool or magic repair button. It focuses on supported streaming, audio, routing, performance and workflow problems, and it should stop rather than guess when the evidence is not strong enough.

No. The whole point is to start from your actual PC, devices, routes, software and connection. Different rigs can need different answers.

Beginners who want the technical layer explained, experienced streamers who want faster diagnosis and repeatable setup, DJs and creators who care about sound and reliability, and stations or collectives dealing with different presenters and rigs.

No. The first layer should explain the outcome and next step in normal English. Deeper evidence stays available for people who want to inspect why RigWave reached a recommendation.

It should not. Experienced users are part of the target audience. The aim is a simple surface with enough evidence underneath to judge the recommendation rather than another black box.

No. First-release features, later ideas and features still being tested are labelled separately. RigWave does not call something ready just because the screen exists.

It is a pre-stream check of the supported chain around the stream: Windows, PC resources, audio devices and drivers, relevant DJ/streaming software, versions, routing and monitoring. The point is to find the weak link before the audience finds it for you.

No. “Full System” means the supported RigWave streaming chain, not every file, security threat or hardware fault on the computer. RigWave may verify its own release file and use or request trusted Windows security checks around that file, but it is not antivirus, malware removal, a registry cleaner or a generic PC-cleaning suite.

No. The honest release wording is evidence-based: verify the exact file hash and signature, run the approved security checks, record what those checks reported, and stop on a mismatch or detection. No software maker can honestly guarantee that a file or computer is “100% virus-free” forever.

No. Detection and repair are separate. A finding should tell you what RigWave saw and why it matters. Supported next steps are then reviewed before anything that changes settings.

The scan is designed to inspect first. Any supported settings-changing step belongs in a deliberate apply workflow, not a surprise hidden inside the scan button.

No. Unsupported hardware, an ISP fault, a platform outage, a third-party bug or a problem outside the evidence RigWave can see may still be the cause. A safe “cannot determine” is better than a confident guess.

Before an important stream, after changing hardware or drivers, after a major Windows/OBS change, or when a previously working setup develops a problem.

No. The intended job is to read the supported OBS setup, available encoder options, PC headroom, connection evidence and chosen streaming service, then recommend within those real limits rather than copying somebody else’s settings.

No. OBS remains OBS. RigWave is designed to help configure and verify supported parts of it.

“Best” means the strongest sensible quality the detected rig and connection can support within the selected service’s rules, with enough headroom left for a stable show. It does not mean the biggest number in every box.

No. There is no universal best setting for every PC, scene, connection and platform. The promise is a reasoned, setup-specific recommendation and verification where supported, not a guarantee that one preset suits every setup.

That is not the intended safety model. Settings-changing work should be deliberate and explained. Live conditions can be monitored, but surprise reconfiguration in the middle of a show would defeat the point of making the setup safer.

It should not. Supported services have different rules and useful operating points. Platform-aware logic is part of the bespoke approach, and exact supported-service coverage must be proven for the release build.

That is why compatibility and update evidence matter. A changed service rule should trigger review rather than letting an old recommendation quietly masquerade as current.

No. It is about protecting streaming headroom, not pushing hardware beyond sensible limits.

No. It cannot create CPU, GPU, memory or bandwidth that the machine does not have. It can help choose a lighter route, stage RigWave work and avoid wasting the headroom that does exist.

The intended checks include supported CPU, GPU, memory and disk pressure plus active streaming-app activity. RigWave can then scale its own work and recommendations rather than competing with the show.

No blind app-killing is part of the intended model. The goal is to explain pressure, defer non-essential RigWave work and avoid crash loops, not behave like an aggressive PC cleaner.

Because a powerful setup can still be overloaded by the wrong combination of encodes, effects, scenes and background work. Headroom is useful evidence even when you already know what the CPU meter means.

The classic “where is the audio actually going?” problem. It is designed to show supported apps and devices as a signal chain so silence, duplicate audio, loops, echo and wrong destinations are easier to reason about.

No. When more than one route is valid, the intended approach is to explain the likely best path and alternatives before routing-affecting changes.

No. Routing Guidance is the decision and visibility layer. It should not be confused with one particular third-party driver or cable product.

No. It can reduce avoidable routing mistakes in supported paths, but a physical mixer, unsupported app or external monitor route can still create a problem outside what RigWave can prove.

Where the workflow supports alternatives, experienced users should remain in control. A recommendation should explain the options so you can decide which supported route to use.

A local profile for a particular supported rig or job: its devices, routes, apps, settings, backups and last-known-good information. It keeps the details of setups such as radio and home DJ streaming separate.

No. It is a RigWave setup profile, not a replacement for Windows accounts.

It should not silently make consequential changes. Where switching would affect routes or applied settings, the user should be told and asked to confirm.

Current Rig Profiles are described as local. A future station-profile/standards direction is being researched for group use, but shared station infrastructure is not being sold as a current feature.

Not as a universal promise. Different hardware, drivers and installed software can require different answers. A profile is useful context, not a guarantee that two computers become identical.

No. RigWave can check its own update status, but installation remains user-approved. Third-party compatibility evidence is not permission to patch everything on the PC.

No. Compatibility Check is primarily about version awareness and whether a change deserves another look. It is not a generic third-party patch manager.

No. Compatibility belongs to a tested combination and can change when Windows, OBS, drivers or platform rules change. Major changes can be marked under verification until retested.

Because “it worked last month” is much easier to investigate when you can see what changed between then and now.

No. Genre Master Out is the live OBS workflow your audience hears, using the underlying Output Master component. Genre Master Pro is for tracks, recordings and mixes before you share or upload them.

No. The job is useful level, headroom and clipping protection on the supported outgoing path. Bigger meter numbers are not the target.

It is designed around the final supported stream output, not to remix your set or replace your gain staging and artistic choices at the decks.

No. Protection at the output cannot reconstruct audio that arrived already damaged. It can help stop the final supported path adding another layer of clipping.

Do not assume the music-output workflow and a microphone chain are the same job. Mic processing has different priorities, especially over music. RigWave keeps those use cases distinct.

Not as a final release proof. The exact Windows version still has to load the component in real OBS, attach it to the correct path, measure the result and prove the backup/restore and protection behaviour.

Finished tracks, recorded mixes and other supported audio files you want to prepare before sharing, uploading or archiving. It is not the live OBS tool.

No. The intended logic uses researched, human-chosen audio principles, limits and genre/use-aware starting rules. It is not supposed to improvise a taste judgement each time.

The intended flow works on a copy and keeps the original safe.

No. The aim is useful control, punch, clarity, separation and stereo space, rather than loudness alone.

It should not. Genre awareness is a starting context, not a stamp that erases the character of the source. Your ears and taste remain the final judge.

No. It is a repeatable utility for supported material, not a claim that automation can replace specialist judgement on every release.

No. It prepares the supported file. Publishing it remains a separate job.

It was consolidated into the Genre Master Pro story so the website did not describe the same file-processing job twice. Audacity-related final licensing and field-proof requirements remain separate release checks.

It lets you hear purpose-made synthetic before/after examples of the design idea. It does not prove every source will react the same way or that the final V1 Windows/Audacity path has already passed field testing.

Finding supported beat-grid drift and, where the workflow supports it, producing a processed candidate copy you can inspect and verify before use, especially when a grid that looked fine at the start begins to wander later in the track.

No. It is a preparation/analysis utility. Your phrasing, timing, blends and performance remain yours.

No. The useful problem is not only “what BPM is this?” but whether the grid stays aligned with the music over time.

The supported processing flow works on a candidate copy so the original can remain protected; the copy should be verified before use.

No universal claim is made. Some music genuinely changes tempo or falls outside the supported correction model. RigWave should say when it cannot safely determine a useful supported result.

The website should only publish the final compatibility list after the exact release workflow has been tested. “Beat Grid” does not mean every format and every DJ application by default.

Bring supported Twitch, YouTube and Facebook Live chat into one clearer view, keep the source obvious and reduce the amount of tab-hopping needed to interact with an audience.

Yes. Community Bridge was the working name. The customer-facing name is RigWave Live Chat Hub.

That is not the release model. The target is authorised platform/API connections and permissions that respect each service’s rules.

No. The intended V1 scope names supported Twitch, YouTube and Facebook Live chat. Other services would need their own supported, permitted integration.

Yes. Source identity is part of the point. A combined view should not erase which service a message belongs to.

Only where the relevant service, authorisation scopes and final RigWave connector proof allow it. A platform that does not permit an action will not be treated as though it does.

No. It should not invent cross-platform identity. The source stays explicit unless a future authorised identity feature has real evidence and consent.

Private testing already covers temporary YouTube connection failures, sensible retry behaviour and safe stopping when permission or session problems cannot be recovered. Full live-service testing is still required before customer access opens.

Not yet. It is planned for the first release, but the live-service journey still needs its final end-to-end testing. That is why the website does not use a fake multi-platform “working” screenshot.

No. The intended model is consent-first live alerts for people who actively choose to hear from you.

No. Creating an invitation is not the same as affirmative opt-in. The recipient must choose to join a supported alert route.

No such behaviour is part of the intended release claim. Live Sharing is about explicit recipient choice, not harvesting an audience.

The released flow must respect the supported service rules and recipient control, with consent and privacy checked before launch.

No. Availability depends on the supported service, its rules, permissions and the final production integration.

The interface and consent-first workflow exist, but live messaging remains off until the final service, consent and end-to-end checks pass.

Because regular listeners can miss a show simply because they did not know it had started. A permission-based alert can help bring people who already want to be there into the room at the right time.

No. Several core problems become more valuable in a team environment: different rigs, different experience levels, handovers, consistent output targets, diagnostics and audience fragmentation. The station page separates those current-fit tools from the group-specific pipeline.

The relevant V1 targets include Rig Profiles, diagnostics, routing guidance, Genre Master Out, Live Chat Hub and consent-first Live Sharing, subject to each feature’s release proof. They are not the same thing as a finished station-management platform.

No. That is a future direction for keeping an agreed station technical target as a reference across different supported rigs. It is explicitly pipeline work.

Not as a finished dedicated handover feature. Guest & Resident Handover is a planned workflow direction. Existing rig, scan and diagnostics concepts can support the problem, but the dedicated team workflow still has to be designed, built and proven.

No. Rota & Team Utilities are future ideas, and the DJ Booking Hub is a researched concept rather than a current feature or V1 promise.

That is not the goal. The useful target is repeatable technical quality and safer setup while leaving music, presentation and personality with the presenter.

Do not assume that. The current intended end-user licence is tied to one licensed PC. A future station, team or multi-seat commercial model has not been finalised and should not be inferred from the station roadmap.

Current Rig Profiles are local. Shared station profiles or central standards are future territory, not a current claim.

No. Restore applies only to supported settings and workflows where RigWave has a verified route back. It is not a whole-PC time machine.

That is the intended model: show the supported change, explain the reason, back up what is relevant where applicable, then let you approve or cancel.

Yes. A recommendation should not become compulsory merely because the software found it.

That can affect what a restore can safely prove. The restore claim belongs to the supported workflow and known saved state, not every unrelated change made elsewhere afterwards.

Because streaming PCs are connected systems. A setting that looks wrong in isolation can be intentional in a particular route. Safety is more useful than a dramatic “fixed 37 issues” counter.

Turning a vague “it broke” report into useful facts: relevant versions, findings and supported setup information that can help support understand the problem faster.

No. The intended flow is create, preview and deliberately send. You should be able to cancel if you do not want the report to leave the PC.

It is designed not to include passwords, stream keys, access tokens, private messages or unnecessary sensitive data. Final release testing still has to prove the reporting path behaves as intended.

No. A diagnostic report is evidence, not remote-control permission.

No. It helps identify and communicate the problem. Evidence and repair are different steps.

A structured report can save time even when you know the system well. It brings relevant versions, audio routes and findings together for support to review.

It is not open yet. Public trial access remains behind the release gates and will only open when the released build and customer journey are approved.

The current intended seven-day trial is no-card and does not automatically convert into a paid plan. Final release terms shown at launch will govern the live offer.

The current intended trial is for one licensed PC.

No. Public download stays closed until the release, field-proof, legal, operational and security gates pass.

Because taking money creates a different level of obligation. RigWave is deliberately keeping public checkout, customer download and live messaging closed until the release boundary is genuinely ready.

Do not trust it because the website sounds confident. Judge it by the real screens, the evidence it gives you, the limitations it admits, whether “No change recommended” is allowed to be a good result, and whether the released trial actually earns its place on your machine.