Reply to thread

Message: [QUOTE="Bombastus, post: 91775, member: 2178"] IZZY Synth 0.1.0 is a 64-bit Windows VST3 instrument, so a compatible host must discover the plugin package before it can appear. The standalone executable is separate and can open normally even when the DAW has never found the VST3 build. The distinction matters because the [B][URL='https://goldmidi.com/community/threads/abyzor-debuted-the-free-izzy-synth-for-windows.77148/']IZZY Synth Windows VST3 release[/URL][/B] includes both formats. Seeing IZZY launch from Windows only proves the standalone app is present, not that the plugin package sits somewhere your host scans. Most missing-plugin fixes become easier once you stop changing five things at once. Check whether the plugin package exists, whether the DAW scans its location, and whether the scan accepts it. Each answer removes a different cause instead of turning troubleshooting into repeated reinstalls. [HEADING=2]The VST3 package needs to be where hosts actually look[/HEADING] On Windows, the standard global VST3 location is the VST3 folder under Program Files\Common Files. Steinberg also defines a per-user location under AppData\Local\Programs\Common\VST3, although some hosts may not scan that newer user path. IZZY's plugin build is the .vst3 package, while the standalone build is an .exe. Copying or installing the standalone application into a plugin folder does not turn it into a VST3 instrument, and keeping only the executable somewhere else on the machine gives the DAW nothing useful to scan. A good first check is brutally literal. Search the computer for ABYZOR IZZY Synth.vst3 and confirm the package exists in a VST3 location your host supports. If the only result is the standalone executable, the problem is installation rather than the DAW browser. Windows can find the package even when the host cannot, so this check is worth doing before touching preferences. Host compatibility comes next. IZZY currently targets Windows 10 or later and 64-bit VST3 hosts, so a DAW that cannot load 64-bit VST3 instruments will not discover it no matter how many scans you run. [HEADING=2]A rescan only helps after the location is correct[/HEADING] DAWs do not all refresh plugins in the same way. Some scan at launch, some expose a manual scan, and some remember a plugin that failed earlier until you explicitly ask them to test failed or previously scanned entries again. Ableton Live, for example, can have its VST3 system folder disabled in preferences. FL Studio can rescan plugins that previously produced errors and can reverify plugins it already knows about. Those controls solve a different problem from moving files, so use them only after the package location makes sense. A normal rescan may still preserve old scan state. A deeper rescan is useful when IZZY sits in the right folder but remains absent, especially after replacing an earlier build or recovering from a scan failure. Close and reopen the host afterward if its documentation says scanning happens during startup. Do not keep adding random custom folders. VST3 has standard Windows locations, and some hosts treat VST3 paths differently from old VST2 search folders. More paths can make the setup harder to reason about without fixing the one directory the host actually expects. [HEADING=2]A failed scan is different from a missing package[/HEADING] Once ABYZOR IZZY Synth.vst3 exists in the right place, the question changes from installation to validation. Look for a failed-plugin list, blocklist, scan log, or plugin manager entry before deleting anything. A host may know the package exists while refusing to expose it in the normal browser. Search under instruments rather than effects as well. IZZY is a synth, so a browser filtered to audio effects can make a correctly installed plugin look missing even after a clean scan. Clear filters and search the manufacturer name if the host groups plugins by vendor. A hidden browser result is not the same failure as a rejected scan. The logic is ordinary debugging, and [B][URL='https://link.springer.com/article/10.1007/s10664-024-10475-3']empirical software fault-localization research[/URL][/B] treats identifying the source of an observed failure as a distinct step from repairing it. For IZZY, three pieces of evidence matter most. The package exists, the host scans its location, and the scanner accepts the package. If the standalone app opens but the .vst3 package is absent, reinstall the plugin build rather than changing DAW settings. If the package is present but the host never scans its folder, correct the scan source. If the folder is scanned and IZZY is logged as failed, a deeper rescan, host update, or fresh plugin copy addresses the actual failure instead of the symptom. A blank project is a useful final separator. If IZZY appears there, installation and discovery are already working, which points back toward browser filters, project state, or the way the original session was configured. If it remains absent everywhere after the package, path, compatibility, and scan state are verified, the remaining evidence belongs in a support report rather than another blind reinstall. [/QUOTE]

Name