Skip to content

Generative AI Full Course Lecture 1 From a Fresh Windows PC to Your First AI Image

FurkanGozukara edited this page Oct 17, 2026 · 1 revision

Generative AI Full Course - Lecture 1: From a Fresh Windows PC to Your First AI Image

Generative AI Full Course - Lecture 1: From a Fresh Windows PC to Your First AI Image

image Hits Patreon BuyMeACoffee Furkan Gözükara Medium Codio Furkan Gözükara Medium

YouTube Channel Furkan Gözükara LinkedIn Udemy Twitter Follow Furkan Gözükara

Build your Windows generative AI environment from scratch and generate your first local image with ComfyUI and Z-Image Turbo. This is Lecture 1 of the 14-lecture Generative AI Tools and Techniques full course. I explain the setup and how to save a reusable workflow. No previous Python or command-line experience is needed.

🔗 Links:

Windows AI requirements guide: [ https://www.patreon.com/posts/111553210 ]

📦 Full course & Lecture 1 companion files: [ https://github.com/FurkanGozukara/Generative-AI-Tools-And-Tecniques-2026-2027-Fall ]

ComfyUI auto installer (optional): [ https://www.patreon.com/posts/105023709 ]

Official ComfyUI manual installation: [ https://docs.comfy.org/installation/manual_install ]

Z-Image Turbo workflow and model downloads: [ https://docs.comfy.org/tutorials/image/z-image/z-image-turbo ]

SECourses Discord: [ https://discord.com/invite/software-engineering-courses-secourses-772774097734074388 ]

🎯 You will learn how to install Python, Git, C++ tools and CUDA, set PATH, isolate packages, install ComfyUI and Manager, download models, restore seeds and PNG workflows, share model folders, and back up before updating.

🧩 Main topics include cuDNN, FFmpeg, Node.js, TensorRT, page files, GPU memory, troubleshooting, and an overview of image, video, speech, music and 3D tools.

Use the chapters to jump to the step you need.

⏱️ Chapters:

00:00:00 Windows setup to your first AI image

00:00:31 How Windows, Python and models connect

00:02:34 CPU, RAM, VRAM and storage explained

00:03:46 Resolution, quantization and memory

00:04:28 Plan apps, models and output folders

00:05:43 Show file extensions and full paths

00:06:24 Local PC or cloud GPU: costs

00:07:25 Official downloads and compatible versions

00:08:29 Choose an NVIDIA Studio driver

00:09:15 Install 7-Zip and extract archives

00:11:25 Python interpreters and packages

00:11:58 Download Python 3.12.10 for Windows

00:12:53 Customize Python components and paths

00:14:23 Finish Python setup and enable long paths

00:15:13 Install Python 3.10 alongside 3.12

00:16:11 Add Python 3.11 and 3.13

00:16:51 List versions with the py launcher

00:17:58 Find your Python executable and pip

00:18:59 Keep global Python packages separate

00:21:22 Set PATH and choose default Python

00:22:57 Why PATH changes need a fresh terminal

00:23:56 Install Git for Windows

00:26:02 Clone a repository and inspect commits

00:27:21 Why AI packages need C++ tools

00:28:08 Download compatible Visual Studio 2022

00:29:44 Select the C++ workload and components

00:31:48 Export your Visual Studio configuration

00:32:08 Open the x64 Native Tools prompt

00:33:11 Compile and run a C++ program

00:35:30 Driver, Toolkit and PyTorch CUDA versions

00:37:09 Download compatible CUDA Toolkits

00:38:24 Install CUDA 12.9: custom components

00:39:37 Install CUDA 13.1 alongside 12.9

00:40:18 Download and install cuDNN

00:41:33 Set cuDNN folders and library paths

00:43:15 Fix missing or incompatible libraries

00:44:26 Page file, RAM and VRAM differences

00:45:27 Set a custom Windows page file

00:47:29 Enable Windows long-path support

00:48:55 Download and extract FFmpeg

00:49:43 Add FFmpeg to PATH; check versions

00:51:13 Test FFmpeg, FFprobe and FFplay

00:52:51 Install Node.js, npm and npx

00:53:54 Download and extract TensorRT

00:54:55 TensorRT libraries, wheels and PATH

00:55:39 Create Python virtual environments

00:56:52 Activate a venv; locate its Python

00:58:05 Isolate different NumPy versions

00:58:52 Use pip check, deactivate and freeze

00:59:42 Fix Python mismatches; rebuild a venv

01:01:04 Clone ComfyUI and select its source

01:02:00 Create ComfyUI's venv; upgrade pip

01:02:54 Install PyTorch and CUDA packages

01:03:46 Install ComfyUI and Manager requirements

01:05:04 Start ComfyUI and open its interface

01:06:15 Download Z-Image Turbo model files

01:07:35 Place the VAE, encoder and model

01:09:12 Load the Z-Image Turbo template

01:10:06 Set prompt, resolution, steps and seed

01:11:01 Generate your first local AI image

01:11:39 Restore the seed before saving

01:12:29 Load a workflow from its original PNG

01:13:38 Reload and run after restarting

01:14:20 Fix missing-model names and folders

01:14:36 Move models into a shared library

01:15:13 Configure extra_model_paths.yaml

01:16:32 ComfyUI memory and startup flags

01:17:28 Back up workflows and environment files

01:19:28 Update ComfyUI and its packages

01:20:35 Save versions for update recovery

01:21:42 Troubleshoot startup and generation

01:23:47 AI image models and FLUX.2

01:24:36 Video models: Wan 2.2 and LTX

01:25:26 Speech, music and 3D tools

01:26:31 Open weights, APIs and model licenses

01:27:05 Local GPUs, RunPod and Comfy Cloud

01:28:27 Interfaces and custom-node sources

01:29:00 Model formats, access and next steps

This video is for anyone getting started with local generative AI on Windows.

💬 For help, check the pinned comment, join our Discord, or leave a comment. Support SECourses on Patreon for more guides, scripts and resources.

#ComfyUI #GenerativeAI #ZImageTurbo

Video Transcription

  • 00:00:00 Welcome to the 1st week of Generative AI  Tools and Techniques. Today we will build the  

  • 00:00:05 working environment behind the course, verify  its parts, and finish with an image generated  

  • 00:00:12 on our own computer. You do not need previous  experience with Python or a command line. The  

  • 00:00:18 links and command handout will be in the  description below. We will also show how  

  • 00:00:22 to find the official pages through Google,  check their addresses, and locate the files  

  • 00:00:29 after downloading them. Some projects require  another operating system, a particular compiler,  

  • 00:00:35 or a specific graphics architecture. Think  of the environment as several cooperating  

  • 00:00:41 layers. Windows manages the computer. A driver  communicates with the graphics card. Python runs  

  • 00:00:48 the application, while packages provide  operations that the application needs to  

  • 00:00:53 perform. Some operations arrive already compiled  inside packages. Others must be built locally  

  • 00:01:00 from source code. That is why a course using  Python also installs a C++ compiler and the CUDA  

  • 00:01:07 developer toolkits. The model is another layer.  Its weights contain learned numerical parameters,  

  • 00:01:13 usually in large files. The application loads  those weights and performs inference, which means  

  • 00:01:19 using the trained model to produce a new result.  A workflow describes how those operations connect.  

  • 00:01:25 In ComfyUI, the connections become visible boxes  and links. We can inspect the text encoder, image  

  • 00:01:32 generator, decoder, and output instead of treating  generation as 1 mysterious button. By the end,  

  • 00:01:39 you should be able to identify your Python  executable, explain the different CUDA numbers,  

  • 00:01:45 inspect a startup log, and locate the model  and workflow files responsible for your 1st  

  • 00:01:52 generated image. For a generative workflow,  consider 3 questions. Can we produce the  

  • 00:01:58 result? Can we reproduce the process? And do  we have permission to use the models, inputs,  

  • 00:02:04 and outputs for the intended purpose? Reproducing  a process means retaining more than a prompt. We  

  • 00:02:11 need the model version, workflow, software  environment, settings, and source assets.  

  • 00:02:16 A random seed helps, but it does not erase  differences between hardware and software  

  • 00:02:22 versions. The habit to build today is simple: make  1 change, inspect what happened. When an error  

  • 00:02:29 appears, read its exact wording before changing  unrelated settings. Before installing anything,  

  • 00:02:35 separate 4 resources: the processor, system  memory, graphics memory, and disk storage. Their  

  • 00:02:42 capacities describe different limits. Increasing  one does not automatically solve a shortage in  

  • 00:02:48 another part of the machine. The processor handles  general work, including parts of loading and  

  • 00:02:54 preparing data. The graphics card performs many  parallel calculations. Modern generative models  

  • 00:03:00 often rely on that parallel hardware to finish  inference in a useful time. Graphics memory,  

  • 00:03:06 or VRAM, sits on the card. System RAM belongs to  the computer as a whole. Moving model data between  

  • 00:03:13 them can help a workload fit, but transfers  may make generation substantially slower.  

  • 00:03:19 Disk storage keeps the files after applications  close. A model stored on a fast drive still has  

  • 00:03:26 to be loaded into usable memory. A large SSD  therefore helps capacity and loading without  

  • 00:03:32 becoming extra graphics memory. Smaller cards  can run selected models and settings. The exact  

  • 00:03:38 requirement depends on architecture, precision,  resolution, batch size, and memory-saving options.  

  • 00:03:46 A small image workflow and a long video workflow  can have very different memory requirements,  

  • 00:03:53 even inside the same application. Video increases  the number of frames that must be represented and  

  • 00:03:59 processed. Higher resolution adds more spatial  information. Longer clips, more frames, and larger  

  • 00:04:05 batches can each increase memory demand and the  time needed to finish. Quantization stores some  

  • 00:04:11 numerical values with fewer bits. It can reduce  memory requirements, with tradeoffs that depend  

  • 00:04:18 on the method and model. A working graphics setup  needs compatible hardware, a suitable driver,  

  • 00:04:25 and application packages that support the card.  Check storage before a large setup. Installers,  

  • 00:04:31 extracted archives, virtual environments,  cached packages, and model weights can coexist  

  • 00:04:37 temporarily. Free space must cover that peak, not  merely the size of the final application folder.  

  • 00:04:44 Our ComfyUI project uses a separate application  folder and Python environment. We will download  

  • 00:04:50 the required model files into its standard  folders first, then explain optional model sharing  

  • 00:04:58 after the basic workflow runs. When starting  fresh, a short location such as C colon, AI,  

  • 00:05:04 then ComfyUI is convenient. Keep the application  path simple, and know where its output,  

  • 00:05:11 configuration, and environment folders will be  created. Use short installation paths with basic  

  • 00:05:16 English characters as a compatibility precaution.  Windows supports spaces and Turkish characters,  

  • 00:05:22 but some build scripts handle them poorly, so  simple paths reduce avoidable troubleshooting.  

  • 00:05:29 Your account folder can also appear in temporary  build paths and caches. Check it early. If a  

  • 00:05:35 specific package fails on that path, preserve  the error and consult its support guidance  

  • 00:05:41 before making account changes. Open File Explorer  and distinguish a file's name from its complete  

  • 00:05:47 path. 2 folders called models on different  drives are different locations. The application  

  • 00:05:52 must search the location containing the files you  actually intend to use. An extension identifies a  

  • 00:05:58 file type, such as an executable installer or a  compressed archive. Showing extensions makes it  

  • 00:06:04 easier to distinguish a configuration file from  a similarly named text document saved with an  

  • 00:06:11 extra extension. Keep separate places for source  applications, shared weights, generated outputs,  

  • 00:06:17 and project backups. You do need to know which  files can be downloaded again and which represent  

  • 00:06:23 your work. A cloud service is another practical  route when local hardware is insufficient.  

  • 00:06:29 Renting a GPU can make an occasional large  job possible. Compare its memory, storage,  

  • 00:06:35 availability, and billing model before deciding  whether it suits your workload. For example, the  

  • 00:06:40 recorded price page lists an RTX 4090 at  74 cents per hour in its selected mode.  

  • 00:06:48 10 hours would be 7 dollars and 40 cents  for that advertised compute rate alone. Storage  

  • 00:06:54 and other charges can change the total. Prices  and availability also change over time. Use the  

  • 00:07:00 dated example to practice budgeting, then read the  current offer before starting a real paid workload  

  • 00:07:08 of your own. Local execution avoids a service  charge for each generated image, but hardware,  

  • 00:07:14 electricity, and storage still cost money. The  useful comparison is the cost of your actual  

  • 00:07:20 workload, including the time needed to maintain  it. We obtain software from its official publisher  

  • 00:07:27 or a clearly identified package source. A search  result is only a starting point. Check the domain  

  • 00:07:34 and product name before downloading an installer  or following an update instruction. The companion  

  • 00:07:40 source list gives the download pages and versions  used here. It separates the versions required by  

  • 00:07:49 these examples from newer releases. Python 3.12.10  is our course baseline. The official release page  

  • 00:07:57 identifies that exact version. A newer release  on the main download page does not automatically  

  • 00:08:02 become the right interpreter for an existing  application. For an application you already use,  

  • 00:08:07 first read its supported Python range and update  procedure. Changing the interpreter can require  

  • 00:08:13 a new virtual environment. Installing a newer  Python beside the old one preserves a clear  

  • 00:08:20 migration path. The same principle applies to CUDA  toolkits. NVIDIA's archive keeps older releases  

  • 00:08:27 with their documentation. For a driver download,  select your graphics card and operating system,  

  • 00:08:33 then inspect the release details. Studio releases  emphasize creative application validation. Game  

  • 00:08:40 Ready releases emphasize support for current  games. Download the Studio driver that matches  

  • 00:08:46 your graphics card and Windows version. Open the  installer, follow its installation steps, and wait  

  • 00:08:54 for the completion screen before closing it or  starting another graphics application. Restart  

  • 00:09:00 Windows when the installer requests it. Then  open the graphics information utility and read  

  • 00:09:06 the installed driver version. Compare that number  with the version you downloaded before continuing  

  • 00:09:12 with the application setup. An installer normally  ends with dot exe or dot msi. A compressed archive  

  • 00:09:20 is different: it contains files that must be  extracted. Some tools are portable archives,  

  • 00:09:26 while others need an installer to register  components and dependencies. Here we install  

  • 00:09:31 7 Zip using its normal Windows installer.  Once it is available, we can inspect and extract  

  • 00:09:37 the larger archives used later. Opening an  archive lets us examine its structure before  

  • 00:09:44 choosing the destination. Extract files into  a named staging folder first when the archive  

  • 00:09:50 contains an extra top-level directory. This makes  it easier to locate the actual bin, lib, include,  

  • 00:09:57 and documentation folders without accidentally  creating a confusing nested installation. The  

  • 00:10:03 bin folder commonly holds executables and runtime  libraries. The include folder usually contains  

  • 00:10:09 headers for developers. A lib folder may contain  libraries used during linking. Those names are  

  • 00:10:16 conventions, so inspect the actual distribution  you downloaded. We keep the documentation and  

  • 00:10:21 license files with the extracted software. They  explain the package's version and distribution  

  • 00:10:27 terms, and can be useful when a downstream  application requires a specific library rather  

  • 00:10:33 than just an executable. Download integrity and  publisher identity answer different questions.  

  • 00:10:39 A matching hash shows that a file matches the  recorded bytes. A valid publisher signature helps  

  • 00:10:46 identify its signer. If a download fails, retain  the exact error and verify the destination has  

  • 00:10:53 free space. Retry through the official source  when practical. A mirror should have traceable  

  • 00:10:59 provenance, with a hash comparison against  the expected file. Avoid treating every  

  • 00:11:05 download problem as an antivirus issue. Network  failures, missing permissions, incomplete files,  

  • 00:11:12 and full disks require different responses. Do  not disable system protection to work around  

  • 00:11:18 a download failure. Keep the original installer  names and a compact version record. Python is the  

  • 00:11:26 interpreter that executes much of our application  code. Packages extend what it can do. Installing  

  • 00:11:33 Python is therefore different from installing  ComfyUI, and installing ComfyUI is different from  

  • 00:11:39 downloading its model weights. We will install  4 Python releases beside one another. The  

  • 00:11:45 course uses 3.12.10 as its  base. The other interpreters remain available  

  • 00:11:51 for applications whose requirements specify a  different supported Python version. Search Google  

  • 00:11:58 for the Python release used by the lesson, then  open the result on the official Python website.  

  • 00:12:05 Check the version heading and the address before  choosing a Windows installer. On the release page,  

  • 00:12:11 find the Windows installer for 64-bit systems.  This demonstration uses Python 3.12.10. The page  

  • 00:12:18 also identifies newer releases; select versions  according to your application requirements. After  

  • 00:12:24 the transfer completes, open the browser download  menu. Right click the installer and choose Show  

  • 00:12:30 in folder. Explorer selects the downloaded file,  so you can see its location and open it directly.  

  • 00:12:38 Double clicking an installer for a version already  present opens its maintenance options, as shown  

  • 00:12:43 here. Modify changes selected features, and Repair  repairs that installation. Next, we follow the  

  • 00:12:50 installation choices for a fresh setup. The 1st  installer is the 64-bit Windows installer for the  

  • 00:12:56 course baseline. Confirm the version in its title  before continuing. The destination will be a short  

  • 00:13:03 folder directly under the C drive. On the 1st  screen, enable the option that adds Python to the  

  • 00:13:09 environment path. We also retain the launcher.  Then choose the customized installation route so  

  • 00:13:15 that we can inspect the components and destination  explicitly. The component screen includes pip,  

  • 00:13:22 documentation, the test suite, and the  graphical toolkit. Keep these selected.  

  • 00:13:28 Pip installs Python packages, while the graphical  toolkit is useful for applications that depend on  

  • 00:13:34 its standard interfaces. The Python launcher  provides explicit interpreter selection. It  

  • 00:13:40 is the program invoked by the short command  py. Retaining it will let us choose a version  

  • 00:13:45 without relying on whichever executable happens  to appear first in PATH. Continue to the advanced  

  • 00:13:52 choices and select installation for all users on  this demonstration machine. Check the destination  

  • 00:13:59 carefully. Our baseline goes into the Python  3.12 folder directly under the C drive,  

  • 00:14:06 as shown. We retain the normal associations and  compilation options used by this installer. Debug  

  • 00:14:12 binaries and debugging symbols remain optional  and are left off. These specialized developer  

  • 00:14:18 files are not required for the course's ordinary  Python environment. Now start installation and  

  • 00:14:24 let the installer copy its files. On your machine,  let it finish and inspect the completion message  

  • 00:14:30 before opening another installer or trying the  verification commands. The completion screen  

  • 00:14:35 offers to disable the path-length limit. We use  that option here. It enables Windows long-path  

  • 00:14:42 support for participating applications. Open a  fresh Command Prompt after closing the installer.  

  • 00:14:49 This is where we enter necessary commands  and read their results. For these checks,  

  • 00:14:55 select the interpreter explicitly with the Python  launcher. Request Python 3.12 explicitly through  

  • 00:15:03 the launcher and read the version result.  This identifies the interpreter that ran,  

  • 00:15:08 independently of the default chosen when you  type Python alone. The next installation adds  

  • 00:15:14 Python 3.10.11. Its purpose  is compatibility with selected older applications.  

  • 00:15:21 We keep it separate from the baseline and  use its own short destination folder on the  

  • 00:15:27 C drive. Follow the same component choices:  pip, the graphical toolkit, documentation,  

  • 00:15:33 test files, and the available launcher options.  A newer launcher may already be installed,  

  • 00:15:39 so an older installer can show a launcher control  as unavailable. An unavailable installer option  

  • 00:15:46 does not necessarily mean the launcher is  missing. After installation, use the launcher  

  • 00:15:52 to list the installed Python versions. Choose the  corresponding Python 3.10 destination and let  

  • 00:15:58 installation finish. Do not put different releases  in the same folder. Separate destinations make  

  • 00:16:04 interpreter identity visible and reduce confusion  when an application asks for a particular version.  

  • 00:16:10 We then install Python 3.11.9. This  is another explicit compatibility  

  • 00:16:15 option. Again, inspect the version, components,  and destination, then wait for the installer to  

  • 00:16:23 report completion before moving to the next  release. Our final additional interpreter is  

  • 00:16:28 Python 3.13.14. It  uses its own Python 3.13 folder. We  

  • 00:16:34 keep the standard build for this course and leave  the optional free-threaded build unselected here.  

  • 00:16:41 Free-threaded Python is a separate compatibility  decision. A library that works with the usual  

  • 00:16:47 interpreter may not support every alternative  build. After all 4 installers finish, open  

  • 00:16:53 a new terminal and run the launcher list command.  Adding the path option to that command shows both  

  • 00:17:01 the registered version and the full executable  location for each interpreter. The list should  

  • 00:17:06 contain the 4 releases we installed, each in  its own directory. The asterisk identifies the  

  • 00:17:13 launcher's default. That default is a separate  concept from the executable found when you type  

  • 00:17:19 the word python. In this fresh setup, the newest  installed interpreter initially answers the bare  

  • 00:17:27 python command. That is expected from the current  search order. Now compare 2 ways to ask for  

  • 00:17:33 a version. A bare python command uses executable  discovery in the current environment. The launcher  

  • 00:17:39 command with 3.12 requests that  registered interpreter explicitly, regardless of  

  • 00:17:45 the normal PATH ordering. Use the same explicit  launcher selection to check the other versions.  

  • 00:17:52 The earlier interpreters remain available after  adding the later releases. Next, ask Python to  

  • 00:17:59 print its executable path. The small command  imports the standard system module and prints  

  • 00:18:05 its executable field. That path identifies the  running interpreter directly, which is especially  

  • 00:18:11 useful when multiple environments exist. Version  output answers which release is running. The  

  • 00:18:17 executable path answers where it is running  from. 2 environments can use the same Python  

  • 00:18:23 version while containing very different sets of  packages. Pip belongs to an interpreter. Calling  

  • 00:18:30 Python with dash m pip asks that Python to run its  package manager module. This form removes a 2nd  

  • 00:18:37 search-order guess that would occur if we invoked  a bare pip executable. For example, checking pip  

  • 00:18:44 through the 3.12 interpreter tells us  about that installation. Checking it through the  

  • 00:18:50 3.11 interpreter tells us about another.  Their package lists can differ even though  

  • 00:18:56 they coexist on the same Windows machine. Do not  install every application into these global Python  

  • 00:19:03 folders. We are creating base interpreters from  which separate virtual environments will be built.  

  • 00:19:09 Most course packages belong in those application  environments, which we will create later. When an  

  • 00:19:15 application requests another interpreter, create  a new environment using the corresponding launcher  

  • 00:19:21 selection. Changing PATH does not transform an  existing environment into a different Python  

  • 00:19:27 version. It only changes how commands are found  in that shell. An existing Python installation  

  • 00:19:34 can offer maintenance choices such as Modify,  Repair, or Uninstall. Modify can add a missing  

  • 00:19:40 component. Repair addresses that installation's  files. When upgrading an existing application,  

  • 00:19:46 preserve its working environment first. Read its  supported version range and test the replacement  

  • 00:19:53 separately. Once the replacement works, you can  decide whether an older environment still serves  

  • 00:19:58 any active project. Avoid deleting an interpreter  simply because it is no longer the newest. Virtual  

  • 00:20:05 environments may still depend on its files. Record  the environments using it before changing that  

  • 00:20:12 installation, and retain a reproducible route for  rebuilding them. Official application instructions  

  • 00:20:18 may support Conda, embedded Python, or another  installation route for specific purposes. If  

  • 00:20:25 Windows says Python cannot be found, inspect the  command and search path before reinstalling. The  

  • 00:20:31 program may be installed correctly but absent  from that terminal's environment. A fresh  

  • 00:20:36 terminal can also be necessary after changing  PATH. If the launcher itself cannot be found,  

  • 00:20:41 check whether it was installed and whether a fresh  shell can discover it. An explicit executable path  

  • 00:20:48 provides another diagnostic route, because it  avoids ambiguity about command lookup altogether.  

  • 00:20:54 We now have the 4 interpreters available. The  remaining task is to make the course baseline win  

  • 00:21:02 the ordinary search order. We will inspect both  environment-variable lists, move its directories  

  • 00:21:09 to the top, and verify the result. Keep the  launcher commands in your notes even after fixing  

  • 00:21:16 PATH. Explicit selection remains the clearest way  to create a new environment. PATH is a list of  

  • 00:21:22 directories that Windows uses when searching for a  command. The order matters. If several directories  

  • 00:21:28 contain an executable with the same name, the  1st applicable match can determine which program  

  • 00:21:34 runs. The Environment Variables window separates  values for the current user from values for the  

  • 00:21:40 whole system. New processes receive an environment  derived from those settings. Applications can  

  • 00:21:46 also modify the environment they give to their  own child processes. Inspect both PATH lists,  

  • 00:21:54 change only the entries you need, and avoid  duplicates. First inspect the user PATH without  

  • 00:22:01 discarding its existing contents. We locate the  course Python directory and its Scripts directory.  

  • 00:22:08 The interpreter lives in the 1st location, while  installed command-line utilities commonly appear  

  • 00:22:14 in Scripts. Move those baseline entries to the top  of the demonstrated list. Keep the other Python  

  • 00:22:21 versions available below them. This changes  discovery order; it does not uninstall those  

  • 00:22:27 interpreters or change the version stored inside  their folders. Apply the corresponding order in  

  • 00:22:35 the system PATH as shown. Read each selected row  before moving it. Confirm the dialogs to save the  

  • 00:22:42 values. An already-open terminal still has the  environment it received earlier. It does not  

  • 00:22:49 necessarily replace its own PATH simply because we  changed the persistent Windows settings in another  

  • 00:22:56 window. The older shell still finds the previous  interpreter. In a fresh terminal, the bare Python  

  • 00:23:03 command uses our chosen baseline. Its executable  path shows the installation folder. This is why  

  • 00:23:11 a successful installation can appear unavailable  in an old terminal. Before changing more settings,  

  • 00:23:17 open a fresh process and repeat the check. Also  consider whether its parent application was  

  • 00:23:24 itself running before the change. The Windows  where command lists matching executable paths.  

  • 00:23:30 We use where.exe explicitly here. Compare the  results with the folders inspected in Explorer to  

  • 00:23:38 identify which installation a command will use.  Use this check for Python, Git, the compiler,  

  • 00:23:45 or a media utility. It tells you where discovery  leads. Then run the application's version command,  

  • 00:23:51 because finding a file and confirming that it  starts are separate checks. Search for Git for  

  • 00:23:57 Windows and open the official Git website. Choose  the Windows installer matching your system. The  

  • 00:24:03 site shows the release being downloaded, so check  that label before starting the transfer. Click the  

  • 00:24:08 64-bit setup link and wait for the browser to  finish downloading it. The download menu shows  

  • 00:24:14 the completed installer. Right click its entry  and choose Show in folder to find it. Explorer  

  • 00:24:22 now selects the Git installer in Downloads. This  is the file to open for setup. We now install Git  

  • 00:24:29 for Windows from its official distribution.  Git manages source-code history. A repository  

  • 00:24:35 contains a project's files and recorded changes,  while cloning creates a local copy that we can  

  • 00:24:42 inspect and later update. The installer offers  several choices for editors, terminal behavior,  

  • 00:24:47 line endings, and authentication helpers. We  retain the demonstrated defaults. These choices  

  • 00:24:54 affect Git's tools and behavior, but they are  separate from the Python environments we have just  

  • 00:25:02 prepared. The default editor in this installation  is Vim. Beginners may prefer another editor when  

  • 00:25:10 configuring their own workflow. Git's credential  helper can assist with authenticated repositories.  

  • 00:25:17 A public clone does not require publishing a  token in a command or configuration file. The  

  • 00:25:24 installation also includes Git Large File Storage  support. Some repositories use that extension for  

  • 00:25:30 large assets. Its availability does not mean  every model is automatically included when  

  • 00:25:36 cloning a repository, so inspect the project's  download instructions. After installation,  

  • 00:25:41 we add the demonstrated Git command and binary  directories to the course PATH lists. Preserve  

  • 00:25:49 the existing entries and use a fresh terminal  again. Then check Git's version and check the  

  • 00:25:56 executable locations. The recorded version is Git  2.55 for Windows. We clone a small  

  • 00:26:03 sample repository before the larger application  install. This gives us a quick way to practice the  

  • 00:26:09 relationship between a remote source and a local  directory, without waiting for a large project  

  • 00:26:16 download. Inside the cloned folder, the status  command describes the working tree. The revision  

  • 00:26:22 command prints the current commit identifier.  Together, they help establish whether the local  

  • 00:26:28 files are clean and which recorded source version  we are using. A commit identifier is more precise  

  • 00:26:34 than saying we used the latest source. The  latest source changes over time. Saving the  

  • 00:26:40 identifier lets us explain exactly which revision  was installed when a particular test or output  

  • 00:26:47 succeeded. Before updating a repository, fetch the  remote changes, inspect the local working tree,  

  • 00:26:54 and use a pull command that allows only  a fast forward. If the histories diverge,  

  • 00:27:00 this command stops instead of creating a merge.  Here the sample repository is already up to date.  

  • 00:27:07 Do not confuse Git updates with Python dependency  updates. New source code can require different  

  • 00:27:13 packages. Read the project's documented sequence,  and apply package changes only in the environment  

  • 00:27:19 belonging to that application. Many AI packages  expose Python functions while performing their  

  • 00:27:26 expensive operations in compiled code. If  a compatible package wheel is available,  

  • 00:27:31 installation can reuse that build. Otherwise,  a package may attempt compilation on your  

  • 00:27:37 machine. A wheel is an installable Python package  distribution. Some wheels contain pure Python and  

  • 00:27:43 work across platforms. Others include compiled  components that require compatible interpreters,  

  • 00:27:50 operating systems, or processor architectures  to install and run. When an installation says  

  • 00:27:55 it failed to build a wheel, read the earlier  compiler messages. That final line describes  

  • 00:28:00 the failed result. The useful cause may be  a missing header, an unsupported compiler,  

  • 00:28:06 or another dependency. Search for Visual Studio  2022 release history, then open the Microsoft  

  • 00:28:13 Learn result. This official page identifies the  release channels and provides installer links,  

  • 00:28:19 helping us choose the version used by the course.  Find the evergreen bootstrapper table and choose  

  • 00:28:25 Community for this demonstration. Build Tools  is listed separately for installations without  

  • 00:28:31 the full editor. Our Community installation will  include the desktop development workload for C++.  

  • 00:28:39 The Community download is a small bootstrapper,  which later obtains the selected components.  

  • 00:28:45 Wait for it to finish, then choose Show in folder.  Explorer displays the installer and its location  

  • 00:28:51 in Downloads. You can open the selected installer  properties and inspect Details to confirm its  

  • 00:28:57 product identity. Here it identifies Visual Studio  2022. We will use this Community route and select  

  • 00:29:03 the development components during setup. We use  Visual Studio Community 2022 because  

  • 00:29:08 its mature compiler toolchain supports the older  CUDA versions and native extensions used here.  

  • 00:29:16 Match the compiler to your application's CUDA  requirements when setting up other projects.  

  • 00:29:21 Community already includes the toolchain we need,  so our route does not require a 2nd Build Tools  

  • 00:29:27 installation. The Microsoft bootstrapper first  prepares the Visual Studio Installer. Confirm  

  • 00:29:33 the publisher and wait for that preparation to  finish. The installer then presents workloads,  

  • 00:29:38 individual components, language choices, and  locations for the selected product instance. On  

  • 00:29:44 the Workloads tab, select only Desktop development  with C++. Leave every other workload unchecked.  

  • 00:29:52 This gives us the native development environment  for these generative AI tasks, and we will choose  

  • 00:29:59 its components on the right. Keep the selected  compiler, build, debugging, profiling, and  

  • 00:30:04 testing tools at the top of the list. The Windows  development kit supplies headers and libraries,  

  • 00:30:10 while CMake helps projects configure their builds.  Clear GitHub Copilot, then select the additional  

  • 00:30:17 libraries and tools shown here in the optional  component list on the right. Include MFC, modules,  

  • 00:30:25 managed C++ support, Clang, and JavaScript  diagnostics. Leave Incredibuild unchecked as  

  • 00:30:32 you work down the list. Select the additional  Windows development kits and the 3 older  

  • 00:30:37 compiler toolsets shown below. Include the Windows  App SDK templates too. These choices keep multiple  

  • 00:30:44 toolsets available for projects with different  build requirements. Check the complete component  

  • 00:30:49 list before continuing. All the options shown  are selected except GitHub Copilot, Incredibuild,  

  • 00:30:57 and Live Share. The companion checklist  lists their names and versions, including  

  • 00:31:03 the older Windows kit marked out of support. Use  English on the Language packs page, then inspect  

  • 00:31:09 Installation locations. Check the space needed on  the destination drive. Here, keeping the download  

  • 00:31:16 cache is unchecked, so downloaded installation  packages will be removed afterward. Return to  

  • 00:31:21 Workloads for a final look, keep Install while  downloading selected, and click Install. A warning  

  • 00:31:27 identifies the older Windows kit and compiler  as out of support. Choose Continue to keep this  

  • 00:31:33 component selection. The installer now downloads  and installs the components. We shorten this wait  

  • 00:31:39 in the video, so let it finish on your computer  before opening the developer tools or continuing  

  • 00:31:46 to the next installation. When installation  completes, inspect the product instance and  

  • 00:31:51 any restart recommendation. Save ongoing work  before restarting. The installer can export  

  • 00:31:57 a configuration file listing the selected  components. Save it to reuse those workload  

  • 00:32:03 choices. Keep separate backups of your project  files and any other files you need. From Start,  

  • 00:32:09 find the native tools Command Prompt supplied  with Visual Studio. Choose the 64-bit shortcut  

  • 00:32:16 for this demonstration. It opens a prepared build  environment using the development components  

  • 00:32:22 selected during installation. The supplied  shortcut configures the compiler together with  

  • 00:32:27 the headers and libraries it needs. Keep  this developer prompt open for the test.  

  • 00:32:33 Adding only the compiler folder to a search  path would not establish the complete build  

  • 00:32:38 environment. Use the 64-bit developer prompt  to inspect the small C++ source file and its  

  • 00:32:46 standard header. The code calculates a simple sum  and prints a success message with the expected  

  • 00:32:54 result 42. In the developer Command Prompt,  change to the folder containing our source file.  

  • 00:33:01 Copy the folder path from Explorer and paste it  after the directory command. Confirm the prompt  

  • 00:33:08 shows that folder before compiling. Microsoft  supplies this native tools shortcut with the  

  • 00:33:14 installed development components. It configures  the compiler, include directories, libraries,  

  • 00:33:20 and Windows development kit together. Use the  shortcut matching the intended 64-bit build  

  • 00:33:26 environment. Enter the compilation command shown  here in the developer prompt. The source file  

  • 00:33:32 remains unchanged. After the compiler finishes,  run the resulting executable and compare its  

  • 00:33:39 output with the expected sum of 42. The  source compiles successfully, and the resulting  

  • 00:33:46 executable prints the expected sum of 42.  It exercises source reading, header discovery,  

  • 00:33:52 compilation, linking, and execution. Many build  systems detect the compiler, SDK, and developer  

  • 00:33:59 environment automatically. Manual build commands  still need that supporting environment. A virtual  

  • 00:34:06 environment does not replace the native compiler  toolchain. It isolates Python packages. A package  

  • 00:34:12 being built inside that environment can still  invoke external compiler tools and depend on the  

  • 00:34:19 environment variables inherited by its process.  If a build says the compiler cannot be found,  

  • 00:34:25 check its executable location and the shell  that launched it. If it finds the compiler but  

  • 00:34:31 cannot locate headers, investigate the developer  environment and selected SDK next. Do not copy  

  • 00:34:38 a compiler folder number from this video without  checking your installation. An update may install  

  • 00:34:44 another version directory. Use the installed  product's tools to locate its environment. For  

  • 00:34:50 an existing Visual Studio installation, the  official update guide shows the Update action  

  • 00:34:56 on the matching product instance. Review pending  changes, close applications that use the tools,  

  • 00:35:02 and follow any installer or restart prompts. After  updating, repeat a small real compile and record  

  • 00:35:08 the compiler version. If an application pins a  particular toolset, check that requirement before  

  • 00:35:14 changing it. The newest available compiler and  the required compiler are not always identical.  

  • 00:35:19 The native toolchain builds code. The graphics  driver and runtime handle GPU execution. Next, we  

  • 00:35:27 will look at the different CUDA version numbers.  CUDA appears in several version labels, and those  

  • 00:35:34 labels describe different things. We will separate  the graphics driver, its supported CUDA level,  

  • 00:35:39 the local developer toolkit, and the runtime  associated with the installed PyTorch build. Start  

  • 00:35:45 with the graphics driver. This is the software  Windows uses to communicate with your NVIDIA card.  

  • 00:35:51 The graphics utility lists its version beside  the card name and memory information. The CUDA  

  • 00:35:57 number near the top of that utility describes  the driver's supported CUDA level. It does not  

  • 00:36:02 list an installed developer toolkit. A machine can  display that number even when the toolkit compiler  

  • 00:36:10 is absent. The local toolkit includes the CUDA  compiler, headers, libraries, and developer tools.  

  • 00:36:17 Asking nvcc for its version reports that compiler  installation. It can therefore show a different  

  • 00:36:24 version from the driver's reported support level.  PyTorch has another CUDA version, associated with  

  • 00:36:29 the build and runtime it uses. A supported  binary distribution can provide the runtime  

  • 00:36:34 components needed for inference without requiring  a separate local toolkit installation just to run  

  • 00:36:40 that workload. Local compilation is different. A  CUDA extension may need the developer toolkit and  

  • 00:36:46 a compatible host compiler. Its build instructions  can impose precise framework, toolkit, compiler,  

  • 00:36:53 and architecture requirements that go beyond  simply matching 1 major number. Your graphics  

  • 00:36:58 card also has a compute capability. Ours is  12.0. When choosing a framework package, look  

  • 00:37:05 for support for your card as well as the required  CUDA version. Search for the NVIDIA CUDA Toolkit  

  • 00:37:10 archive and open the official NVIDIA result.  The archive lists earlier releases individually.  

  • 00:37:16 Choose the version required by the project,  rather than assuming every project needs the  

  • 00:37:22 newest toolkit. For this download, select Windows,  the 64-bit architecture, and Windows 11. Choose  

  • 00:37:28 the local installer option shown on the page. Its  complete download can then be opened from Explorer  

  • 00:37:36 for setup. Click Download and keep the browser  open until the transfer finishes. This installer  

  • 00:37:42 is several gigabytes. The completed download entry  provides the route back to the saved file. Right  

  • 00:37:49 click the completed installer and choose Show in  folder. Explorer selects the file in Downloads,  

  • 00:37:55 with its version in the filename. Open  that file for the toolkit installation,  

  • 00:38:01 then verify the installed components separately.  Begin with the 12.9 installer and  

  • 00:38:07 confirm its publisher. It extracts installation  files before opening the component choices.  

  • 00:38:15 Allow extraction to finish and inspect the  system-check result instead of assuming the  

  • 00:38:20 1st progress window is the installation  itself. Choose the custom installation route  

  • 00:38:26 so the component groups are visible. We retain  the CUDA development, runtime, documentation,  

  • 00:38:32 and profiling selections used by this course.  The installer also shows its Visual Studio  

  • 00:38:39 integration components. Here we leave the bundled  display driver and PhysX groups unselected while  

  • 00:38:46 installing the toolkit components. The graphics  driver is managed separately through its vendor  

  • 00:38:51 installer and must be checked before running  graphics workloads. The selected destination  

  • 00:38:56 is the versioned CUDA folder under Program Files.  Its version suffix lets this toolkit coexist with  

  • 00:39:04 another release. Keep that distinction visible  rather than extracting different toolkit versions  

  • 00:39:10 over the same application directory. Start  installation and wait for the component table  

  • 00:39:15 to complete. Profiling and integration tools can  take time to install. The integration summary  

  • 00:39:22 recognizes our installed Visual Studio version.  It also mentions older product versions that are  

  • 00:39:28 absent. An absent optional integration target  does not automatically mean the core toolkit  

  • 00:39:34 or compiler installation has failed. Next, launch  the 13.1 installer and inspect its  

  • 00:39:42 custom selections. The installer offers the  CUDA components and developer integrations.  

  • 00:39:47 It does not offer the same display-driver group  seen in the older installer. NVIDIA changed that  

  • 00:39:54 packaging for newer Windows toolkits. Install  and check the graphics driver separately before  

  • 00:40:01 running GPU workloads. Use the new toolkit's  separate versioned destination and continue  

  • 00:40:06 through its checks. The recorded installer  warns that an existing CUDA path variable  

  • 00:40:11 may require attention. After installation,  check which toolkit the CUDA path variable  

  • 00:40:17 points to. The neural-network library belongs to  the native software layer alongside the toolkit  

  • 00:40:24 and other runtime components. Some Python  distributions provide their own dependencies,  

  • 00:40:29 while other applications require an external  installation. Open the official library archive  

  • 00:40:35 and find the course release, which is version  9.19. Select that release,  

  • 00:40:40 then follow its Windows instructions to download  the graphical installer for your application.  

  • 00:40:46 Use the Windows executable when following the  installer sequence shown next. The separate  

  • 00:40:50 zip downloads provide library archives with a  different setup route. Keep your chosen package  

  • 00:40:56 and its installation instructions together. We  install the course's 9.19 release  

  • 00:41:02 from the official Windows installer. Confirm  the publisher, allow its extraction to finish,  

  • 00:41:08 and inspect the installation choices. This  demonstration uses the installer's express  

  • 00:41:13 defaults for the supplied components. The  completion table shows development files,  

  • 00:41:18 runtime files, and samples. Those categories  serve different purposes. Runtime libraries  

  • 00:41:23 support execution, while headers and related  developer files support applications that compile  

  • 00:41:30 against the library's documented interfaces.  Inspect the actual installation directory  

  • 00:41:35 before configuring any library paths, because the  layout can differ between releases. This version  

  • 00:41:41 contains separate runtime folders associated  with the 2 toolkit branches in our setup. The  

  • 00:41:47 recorded folders include the 12.9 and  13.1 branches, each with a 64-bit  

  • 00:41:54 directory. Check that the library files exist in  both locations. A directory name and a library's  

  • 00:42:00 file version are separate observations. The folder  identifies the installed release layout, while the  

  • 00:42:07 file properties identify the actual binary.  Recording both helps diagnose an application  

  • 00:42:12 that loads an unexpected copy. Open Environment  Variables through the Windows settings dialogs,  

  • 00:42:19 then inspect the system Path list. Copy the actual  library folder from Explorer. This recording shows  

  • 00:42:25 an existing entry, so we confirm its value without  adding a duplicate. Each Path entry should name  

  • 00:42:32 a real directory. Keep existing unrelated entries  intact, and inspect the list before adding another  

  • 00:42:39 folder. After confirming the dialog, newly opened  applications receive the updated environment;  

  • 00:42:46 already running programs may not. The additional  system variable shown here points to the bin  

  • 00:42:51 directory of this installed library release. Read  its exact name and value in the reference panel,  

  • 00:42:58 then verify that the directory exists.  Open the library folder in Explorer,  

  • 00:43:03 then the file's Properties and Details tab to read  its binary version and filename. An application  

  • 00:43:09 can use its packaged runtime or another library  search mechanism instead of PATH. Identify the  

  • 00:43:15 library version expected by an application and  follow its documented installation method when  

  • 00:43:22 resolving a missing dependency. Copying arbitrary  libraries into unrelated folders can introduce  

  • 00:43:29 incompatible binaries and harder failures. For a  Python application using a packaged GPU runtime,  

  • 00:43:36 a separately installed cuDNN release may  not be the copy it loads. Installing the  

  • 00:43:43 external library does not automatically replace  that environment's dependencies or change the  

  • 00:43:48 framework's build configuration. Before updating,  save the working application and library versions  

  • 00:43:54 and a recoverable configuration. After the update,  run the application in its intended environment.  

  • 00:44:02 If an error mentions a missing library, confirm  its exact filename, expected location, and the  

  • 00:44:08 process environment. If the library is found but  an operation fails, investigate the framework  

  • 00:44:14 and hardware compatibility rather than adding more  unrelated paths. Next, we inspect the Windows page  

  • 00:44:21 file and compare memory commitment with physical  memory. Windows memory commitment is another  

  • 00:44:27 resource to check before loading large models. An  application can reserve committed memory backed by  

  • 00:44:34 physical memory and the page file. Reaching that  commitment limit differs from exhausting dedicated  

  • 00:44:42 graphics memory. The page file occupies disk  space that Windows can use as part of its memory  

  • 00:44:48 management. It does not become physical RAM, and  it does not add VRAM to the graphics card. Disk  

  • 00:44:54 access remains much slower. First, let us look at  the current page-file setting. Windows is already  

  • 00:45:02 managing a page file automatically. You can keep  automatic management, or choose a custom size when  

  • 00:45:08 an application needs more committed memory. Open  the advanced system settings and the performance  

  • 00:45:14 options. Within the advanced performance page,  locate virtual memory and choose Change. Follow  

  • 00:45:19 the visible sequence carefully because several  dialogs use similar headings and their own  

  • 00:45:25 confirmation buttons. The automatic management  checkbox controls whether Windows chooses the  

  • 00:45:30 page-file settings. We turn that off for this  course demonstration, select the intended drive,  

  • 00:45:37 and choose a custom size with the values shown  in the reference panel. The initial and maximum  

  • 00:45:44 fields both receive the same  large value: 102,400. The dialog  

  • 00:45:51 labels these fields in megabytes. Click Set  to apply those entries to the selected drive.  

  • 00:45:57 Simply typing numbers into the fields is not the  entire procedure. Inspect the updated drive entry,  

  • 00:46:03 then confirm the remaining dialogs to retain  the configuration. Before reserving that much  

  • 00:46:09 space on your own machine, check the drive's  capacity and free space. The operating system,  

  • 00:46:16 installers, caches, models, and outputs still need  room. A large page file can substantially reduce  

  • 00:46:23 available storage. Reopen the Virtual Memory  dialog and compare its displayed values. The  

  • 00:46:29 initial and maximum fields show 102,400 MB. The  current allocation is also visible, confirming the  

  • 00:46:37 saved configuration on this computer. Windows may  request a restart after a memory setting changes.  

  • 00:46:45 Follow that actual message and check the dialog  again afterward. Here the requested allocation  

  • 00:46:50 is already displayed, so we confirm the existing  state without changing it again. A failed model  

  • 00:46:57 load needs investigation of the exact error and  memory state before changing settings. Possible  

  • 00:47:04 causes include insufficient memory, damaged  weights, or application problems; increasing the  

  • 00:47:10 page file is not a universal remedy. Offloading  can make some workloads possible by moving data  

  • 00:47:17 away from the graphics card, but transfers may  increase runtime. Observe the application and  

  • 00:47:24 memory usage before attributing an unexplained  slowdown to 1 setting. Long path support  

  • 00:47:30 affects installations with deeply nested package  directories. The Python installer offers 1 route  

  • 00:47:36 to this setting. Here we show the Windows policy  interface, following the system folders to the  

  • 00:47:42 filesystem options. The Local Group Policy  Editor shows Enable Win32 long paths under  

  • 00:47:49 the system filesystem policies. We select Enabled  and apply it. Applications still need compatible  

  • 00:47:55 path handling, and this editor is not included  in every Windows edition. Keep application paths  

  • 00:48:02 short even when long-path support is enabled. It  makes commands easier to read and reduces room  

  • 00:48:10 for mistakes. Generative media applications need  utilities around the model itself. Images, video,  

  • 00:48:17 and sound must be decoded, inspected, and saved.  In this section, we install the media tools and  

  • 00:48:24 additional runtime components included in  the course environment. Our media toolkit  

  • 00:48:30 processes audio and video, while its inspection  utility reports file properties including codec  

  • 00:48:38 and duration. The static distribution provides  standalone executables for command-line media  

  • 00:48:43 work, while the shared distribution also supplies  separate runtime libraries. Some applications load  

  • 00:48:50 those libraries directly instead of launching  a media executable. Search for FFmpeg Windows  

  • 00:48:57 download and open the official FFmpeg result.  Under Windows executable files, choose the Gyan  

  • 00:49:04 build provider. This opens the page with release  archives for Windows. Scroll to release builds and  

  • 00:49:12 download the essentials archive. The recording  selects version 9.0.1. Wait for the download to  

  • 00:49:20 finish, then open the archive in Explorer. Extract  the downloaded archive into the course folder,  

  • 00:49:31 then open its versioned folder and bin directory.  Copy the full bin path from Explorer's address  

  • 00:49:38 bar. This directory contains the media programs  we'll use next. Search Windows for environment  

  • 00:49:44 variables and open the system properties result.  Choose Environment Variables, select Path, and  

  • 00:49:50 open its editor. Add the copied bin directory as  its own entry, keeping the other required entries.  

  • 00:50:05 Check for an older FFmpeg entry in the system  Path as well. Here we replace that older entry  

  • 00:50:11 with the new bin folder. Save the Path editor,  Environment Variables, and System Properties  

  • 00:50:17 with their OK buttons. Open a fresh Command Prompt  from the course folder after saving the dialogs.  

  • 00:50:38 Run where ffmpeg and then its version command.  Here the path points to our extracted folder and  

  • 00:50:46 the version is 9.0.1. Repeat the location and  version commands for ffprobe. Both programs now  

  • 00:50:58 come from the same essentials build. If an older  location appears first, correct that Path entry,  

  • 00:51:05 save the dialogs, and open another fresh prompt.  Use the 1st media command in the companion sheet  

  • 00:51:16 to create a 2 second tone at 440 Hz. It saves  a wave file with a 48 kHz sample rate and 1  

  • 00:51:26 channel. Run the ffprobe command on the saved  wave file. Its output reports the audio codec,  

  • 00:51:35 sample rate, channel count, and duration. Read  these fields together to check that the file has  

  • 00:51:41 the properties you requested. Now run the playback  command from the same folder. It plays the saved  

  • 00:51:53 file and returns to the prompt when finished. Set  a comfortable speaker volume before running it,  

  • 00:52:00 then find the wave file in Explorer. When  an application uses shared media libraries,  

  • 00:52:22 check its supported library versions separately.  A command line executable and a shared library are  

  • 00:52:29 different dependencies. Follow the application's  installation instructions for the particular  

  • 00:52:34 component it needs. If a library fails to load,  read the missing library name in the error  

  • 00:52:40 message. Check its required version and search  location, then restart the application after  

  • 00:52:47 correcting them. Keep this information with your  installation notes. Node runs JavaScript outside  

  • 00:52:52 the browser, and some applications need it for  their web tools. Open the official download page,  

  • 00:53:00 then choose the release your application supports  and the Windows package. In the prebuilt section,  

  • 00:53:07 select Windows and your computer's architecture.  The Windows Installer button provides the setup  

  • 00:53:11 package. Our course checks use version  22.20, available through the previous  

  • 00:53:18 releases archive. Run the downloaded installer,  keep Node and npm selected, and allow the normal  

  • 00:53:25 PATH setup. Finish the wizard, then open a fresh  Command Prompt so it picks up the installation  

  • 00:53:32 before running these checks. Use a fresh terminal  to check the JavaScript runtime and both package  

  • 00:53:38 utilities after their installation finishes.  The recorded version results identify the  

  • 00:53:44 programs actually available for later application  dependency checks. We also run a tiny JavaScript  

  • 00:53:51 calculation that prints 42. Search for  NVIDIA TensorRT and open its official Get Started  

  • 00:53:58 page. Select Download Now. If NVIDIA asks you to  sign in, complete that sign-in before choosing the  

  • 00:54:06 package for your installation. Choose the Windows  archive for the TensorRT release and CUDA version  

  • 00:54:12 your application supports. Download it, then  extract the complete folder. Next we'll inspect  

  • 00:54:18 the saved archive, its libraries, and the Python  wheels. TensorRT is another optional dependency  

  • 00:54:24 for particular applications. The course prepares  its archive layout, but a program must support  

  • 00:54:31 the specific runtime and GPU combination. We  inspect the course's TensorRT archive and extract  

  • 00:54:39 its contents to the versioned directory shown on  screen. Preserve the complete archive structure,  

  • 00:54:47 including libraries, headers, tools, and Python  distributions, rather than selecting only a  

  • 00:54:53 familiar-looking file. The library directory  contains the inference DLL. Check that the  

  • 00:54:58 file exists and use the archive's release version.  This DLL does not expose a useful Windows version  

  • 00:55:05 value. The archive also includes Python wheels  for specific interpreter combinations. A wheel  

  • 00:55:11 tagged for 1 interpreter is not interchangeable  with every Python installation. Inspect the tags  

  • 00:55:17 and the application's required distribution  before installing any of those packages. Copy  

  • 00:55:22 the TensorRT library folder from Explorer, then  inspect its entry in the system Path dialog. This  

  • 00:55:30 setup already contains the required entry. Confirm  the real directory and retain existing entries  

  • 00:55:37 without creating another duplicate. A virtual  environment gives an application its own Python  

  • 00:55:42 package location and command entry points. It is  created from a chosen interpreter. This lets 2  

  • 00:55:48 applications keep different dependency versions  while sharing the same Windows computer. A Python  

  • 00:55:55 environment keeps a project's packages separate  while using the same Windows installation and  

  • 00:56:00 graphics hardware. Drivers and native build tools  remain system components. The project interpreter  

  • 00:56:06 manages its own installed Python packages. We  create the 1st environment using the launcher  

  • 00:56:12 to select the course's 3.12 interpreter.  The destination is a named folder inside our  

  • 00:56:18 demonstration project. The command creates the  environment files without downloading a complete  

  • 00:56:24 AI application. We create a 2nd environment  from the installed 3.11 interpreter.  

  • 00:56:30 It remains separate from the 1st environment,  with its own executable path and its own package  

  • 00:56:36 directory. Before activation, we can run  either environment's Python directly through  

  • 00:56:42 its full path. That is a useful diagnostic  technique because it avoids relying on the  

  • 00:56:47 current shell's search order or the success of  an activation script. Keep the lesson handout  

  • 00:56:52 beside Command Prompt so each instruction has  a visible source. Copy the activation command  

  • 00:56:59 for the 1st environment and paste it into the  prompt. This uses the supplied batch activation  

  • 00:57:05 file. Activation is a convenience that adjusts  the current shell's environment. It is not a  

  • 00:57:12 requirement for invoking that Python directly, and  it does not install the application's packages by  

  • 00:57:18 itself. The activation command changes  this Command Prompt session. It places  

  • 00:57:23 the environment's tools earlier in its search  path. We can then call Python normally, while  

  • 00:57:29 keeping the full executable path available for an  explicit identity check. After activation, inspect  

  • 00:57:35 the executable search results and the package  manager location. The environment label helps  

  • 00:57:40 you follow the sequence, while the paths confirm  which interpreter and package directory will  

  • 00:57:46 receive the commands that follow. An activated  shell should resolve Python to the environment's  

  • 00:57:52 Scripts directory. Asking that interpreter to  run pip reaches its own package manager. This  

  • 00:57:59 is the practical reason for using Python dash m  pip throughout the application installation. We  

  • 00:58:05 install a selected NumPy version into the 1st  environment. NumPy provides numerical array  

  • 00:58:11 operations and makes a convenient small dependency  example. Inside the 3.12 environment,  

  • 00:58:18 the recorded NumPy version is 2.1.3.  We inspect the imported package and  

  • 00:58:24 executable together. The 2nd environment uses  NumPy 1.26.4 with the  

  • 00:58:31 3.11 interpreter. Both are compatibility  choices for this demonstration. The 2 package  

  • 00:58:37 results differ while the environments coexist.  Installing the 2nd version did not replace  

  • 00:58:42 the 1st environment's package. This is the  benefit that prevents unrelated applications  

  • 00:58:47 from continually changing one another's working  dependency sets. Return to the 1st environment  

  • 00:58:53 after checking the 2nd one, and inspect its  imported package version again. It still reports  

  • 00:59:00 the original version. The pip check command  looks for inconsistencies among installed  

  • 00:59:06 package requirements. Both demonstration  environments pass that check. The deactivate  

  • 00:59:11 command restores the earlier environment of this  Command Prompt session. It does not delete either  

  • 00:59:17 environment folder. We can still call their Python  executables directly, as the separate package  

  • 00:59:23 checks demonstrate on screen. The freeze command  saves the installed package list into our working  

  • 00:59:30 folder. In Explorer, open the demonstration folder  and locate that requirements file beside the 2  

  • 00:59:37 environments. Keep it with the interpreter version  and installation instructions. If an application  

  • 00:59:43 says a package is missing after you installed it,  compare the interpreter used for installation with  

  • 00:59:49 the interpreter launching the app. This mismatch  is common, and another installation attempt can  

  • 00:59:55 hide it instead of solving it. If a project needs  a different Python version, create a separate  

  • 01:00:01 replacement environment from that interpreter.  Do not point an existing environment at another  

  • 01:00:07 version and assume its compiled packages  remain compatible. Rebuild and verify the  

  • 01:00:14 intended package set. Keep the working environment  until its replacement passes the necessary checks.  

  • 01:00:21 Preserve the requirements, source revision,  and configuration before removing anything.  

  • 01:00:26 Other package tools can manage environments  and dependencies too. For example, some  

  • 01:00:33 projects document uv or Conda. Follow the chosen  project's instructions while preserving the same  

  • 01:00:40 core discipline: explicit interpreter identity  and an isolated set of application dependencies.  

  • 01:00:48 Keep instructions and versions that can recreate  your environment, because its working folder can  

  • 01:00:54 depend on this machine. Preserve workflows, source  assets, outputs, and configuration separately as  

  • 01:01:01 the project files that represent your work. Next,  build a dedicated ComfyUI installation from its  

  • 01:01:08 official repository. We'll put the source and  a separate Python environment in 1 folder,  

  • 01:01:15 install its requirements, and launch the browser  interface. Open the educational videos folder in  

  • 01:01:21 Explorer. Click the address bar, type cmd, and  press Enter. The new Command Prompt starts in  

  • 01:01:28 this folder, ready for the clone command from  the companion sheet. The 1st command clones  

  • 01:01:34 the official ComfyUI repository. Confirm the  organization and repository name before using  

  • 01:01:39 it. Cloning retrieves the application source;  it does not include every model or prepare  

  • 01:01:45 all the Python dependencies automatically.  The companion commands select the course's  

  • 01:01:49 recorded source snapshot. Run the checkout  command, then print the commit identifier.  

  • 01:01:55 Keep this identifier with your installation notes  so you can return to that version. Open the cloned  

  • 01:02:01 folder and start Command Prompt there. Create the  environment, activate it, and print the Python  

  • 01:02:08 version. The prompt now shows the environment  name before the following package commands run.  

  • 01:02:22 Run the pip upgrade command inside the  activated environment. Wait until the  

  • 01:02:29 installation finishes and the prompt returns.  The successful result lists the new pip version,  

  • 01:02:36 ready for the application's package installation.  If a download request retries, let the current  

  • 01:02:42 command finish. When it stops with an error, check  your connection and the reported package source,  

  • 01:02:50 then repeat that command before moving to the next  step. Now install the PyTorch packages using the  

  • 01:02:56 CUDA package source documented for this route. The  command includes the framework and related vision  

  • 01:03:02 and audio packages. Its destination remains  the new environment's Python, not a global  

  • 01:03:07 package manager. Here the documented command  uses the CUDA 13 package source. Choose  

  • 01:03:14 the package source supported by your application  and graphics card. Install the framework, vision,  

  • 01:03:20 and audio packages together inside this  environment. These packages can take time  

  • 01:03:25 to download and install. Wait for the successful  installation message and the return of the prompt.  

  • 01:03:31 The completed installation lists PyTorch  2.14 with a CUDA 13 build. Save the  

  • 01:03:37 companion package versions with it. This package  list will help you reproduce the environment or  

  • 01:03:43 compare a later update. The next command installs  ComfyUI's application requirements. This includes  

  • 01:03:49 Python packages used by the server, interface  distribution, templates, and other functions.  

  • 01:03:56 A source clone alone would leave this dependency  step incomplete. We then install the requirements  

  • 01:04:02 for the integrated Manager and enable it through  the documented startup flag. The recorded version  

  • 01:04:09 supports this route. Older tutorials may describe  placing a separate Manager repository in the  

  • 01:04:15 custom-node directory. Use the requirements files  supplied with the source snapshot you selected.  

  • 01:04:22 Install the application requirements first, then  the Manager requirements. Keep the installation  

  • 01:04:28 guide and companion commands alongside your  saved source identifier. Run pip check after  

  • 01:04:34 both requirements commands finish. Here it reports  no broken requirements. If it lists a missing or  

  • 01:04:40 incompatible package, resolve that message inside  this environment before starting the application  

  • 01:04:46 server. Save the installed package list to the  requirements lock file. Save the source commit in  

  • 01:04:52 the 2nd text file. Keep both in the application  folder so you can copy them into a backup before  

  • 01:04:59 updating. Activate the environment and run the  startup command. Enable Manager and select port  

  • 01:05:09 8189. The example also includes optional memory  settings, which we'll examine after completing the  

  • 01:05:16 1st image workflow. Watch the startup messages  until the server prints its local address.  

  • 01:05:23 The log also lists the selected graphics device  and memory mode. Keep this window open while you  

  • 01:05:29 use the application in your browser. Some optional  acceleration or integration messages can appear  

  • 01:05:35 during startup. A missing optional component is  not automatically a fatal installation error.  

  • 01:05:40 Follow the log through to the server-ready message  and the actual browser response before drawing  

  • 01:05:45 that conclusion. The address points to the same  computer through its loopback interface. A local  

  • 01:05:52 browser connection is different from publishing  a server to the network. This demonstration does  

  • 01:05:58 not require exposing the application to other  devices or the public internet. Keep the terminal  

  • 01:06:04 available because it contains the server process  and useful diagnostics. Closing that process can  

  • 01:06:10 stop the application even if the browser tab  remains visible. The application is installed,  

  • 01:06:16 but this workflow still needs model files. We will  follow the official documentation to download each  

  • 01:06:22 component, then use Explorer to place the  completed files into their matching folders  

  • 01:06:28 before generating an image. This workflow needs  3 separate files: the image generation model,  

  • 01:06:34 the text encoder, and the image decoder. Their  categories matter. Putting every file into 1  

  • 01:06:40 folder does not match the locations that this  workflow expects. Search for the official ComfyUI  

  • 01:06:46 Z-Image Turbo example and open the documentation  result. Check the domain in the address bar. Its  

  • 01:06:52 model download section connects each required file  to the folder where the application expects it.  

  • 01:06:58 Open the text encoder file page and use Download.  Leave the file downloading until it completes;  

  • 01:07:06 the partial file is not ready to place in the  model folder. Next, follow the diffusion model  

  • 01:07:12 link from the documentation and download the  selected weights. This is the largest of our  

  • 01:07:18 3 files. The documentation shows each filename  beside its destination folder. Open its download  

  • 01:07:25 link and confirm the repository and filename  on the model page. We use the browser Download  

  • 01:07:32 control and wait for the transfer to complete.  Choose Show in folder from the browser download  

  • 01:07:38 entry. Explorer reveals the downloaded file and  its location. Copy that file, navigate to the  

  • 01:07:45 matching model category inside ComfyUI, and paste  it into the destination. For the decoder, select  

  • 01:07:51 the completed file in Downloads and copy it. Open  ComfyUI, then models, then VAE, and paste. The  

  • 01:08:00 same filename now appears in that destination.  Find the completed text encoder in Downloads,  

  • 01:08:06 select the file, and copy it to the clipboard.  Inside the application folder, open models,  

  • 01:08:11 then text_encoders, and paste the file into that  destination. Once the diffusion download finishes,  

  • 01:08:18 copy it from Downloads into the diffusion_models  folder. Check the destination filename and size  

  • 01:08:24 after copying. Preserve the complete filenames  and extensions. After the files are in place,  

  • 01:08:31 reopen or refresh the application's model choices  before submitting the workflow. The browser  

  • 01:08:38 interface is the visible front end of the running  server. It presents workflows and results, while  

  • 01:08:44 the server performs the model operations. If a  page fails to connect, inspect the server address  

  • 01:08:51 and startup state first. We create a separate  workflow for this lecture so that existing work  

  • 01:08:58 remains available. The template library provides  prepared graphs for supported model families. A  

  • 01:09:04 template is a starting configuration, not a  substitute for installing its required files.  

  • 01:09:11 Search the template library for Z Image Turbo and  choose the text-to-image example. The selected  

  • 01:09:18 template separates the model into several  components. A text encoder turns the prompt  

  • 01:09:24 into conditioning information. The diffusion model  generates an image representation, and the decoder  

  • 01:09:31 turns that representation into pixels that can  be saved. The local installation now contains the  

  • 01:09:37 files downloaded from the workflow's documented  sources. Check the 3 model selections against  

  • 01:09:42 those actual filenames. The diffusion model  belongs in the diffusion_models folder, while the  

  • 01:09:49 text encoder belongs in text_encoders. Select the  matching files shown in the workflow. The decoder  

  • 01:09:55 belongs in the VAE folder and appears under its  documented filename. With all 3 components  

  • 01:10:02 selected, inspect the prompt and image settings.  Our prompt describes a creative workstation in a  

  • 01:10:08 university laboratory, with warm desk lighting and  a monitor displaying abstract shapes. It also asks  

  • 01:10:16 for no people and avoids intentionally requesting  readable text or a recognizable brand. The image  

  • 01:10:22 size is 1024 pixels square,  with a batch size of 1. The template uses 8  

  • 01:10:30 sampling steps and the selected Turbo model's  settings. More steps do not automatically improve  

  • 01:10:36 every distilled model. Use the recommendations for  the actual model and workflow rather than applying  

  • 01:10:43 1 sampler recipe everywhere. Keep the seed and  other generation settings in the saved workflow  

  • 01:10:49 and output metadata. A seed helps reproduce a  run under comparable conditions. Changing models,  

  • 01:10:57 libraries, or hardware can change the output  even with the same seed. Submit the workflow  

  • 01:11:02 and observe the progress. The 1st execution  may involve loading large weights before sampling  

  • 01:11:09 begins. The job history lists the submitted  settings and result. The image has appeared  

  • 01:11:15 in the output node. Keep the job history with the  device, model, and workflow settings. Performance  

  • 01:11:22 depends on loading, hardware, precision, and image  size. The image shows a desk, monitor, keyboard,  

  • 01:11:28 and speakers. Small interface-like markings and  a label remain on the monitor. Compare the image  

  • 01:11:35 with your prompt and inspect its visual quality.  After a run, this template displays a new seed  

  • 01:11:42 for the next image. Before saving, put back the  seed used for the image you want to reproduce.  

  • 01:11:48 Here we restore the original number shown on  screen. Then use File, Save As, and give the  

  • 01:11:55 workflow a descriptive name. We use the filename  shown here, ready to reopen with the same prompt,  

  • 01:12:03 models, dimensions, and seed. Close the graph and  reopen it from the workflow library. Inspect the  

  • 01:12:11 returned prompt, model selections, dimensions, and  seed. Reopening this saved graph brings back the  

  • 01:12:17 seed we restored before saving. We can now repeat  the run with those settings. If your sampler has  

  • 01:12:24 a control after generate option, choose fixed to  keep its seed unchanged. Open the application's  

  • 01:12:30 output folder to find the original PNG. ComfyUI  can store the workflow and generation settings  

  • 01:12:38 inside it. In ComfyUI, press Control O and  select that original image to reload its embedded  

  • 01:12:44 workflow. The prompt, models, dimensions, and seed  return. Keep the original file, because converted  

  • 01:12:52 or shared copies may lose that metadata. From  the application folder, open user, then default,  

  • 01:12:59 then workflows to find the saved graph. This  folder contains the application saves, while  

  • 01:13:05 browser downloads go to the download location  configured in your browser. Your installation  

  • 01:13:10 may use a different drive or application folder.  Start from the folder you chose, then follow the  

  • 01:13:17 same output and user directories. The visible  filenames identify the actual saved assets,  

  • 01:13:24 rather than relying on this computer’s drive  letter. This PNG contains workflow and request  

  • 01:13:30 metadata. Keep a separate workflow file because  other software can remove image metadata. Select  

  • 01:13:38 the saved workflow file and copy its path. In  ComfyUI, open the file picker, paste that path,  

  • 01:13:44 and load the graph. The model selections  and original seed return, giving us another  

  • 01:13:50 practical way to recover the configuration.  After restarting the tutorial server,  

  • 01:13:56 we load the saved graph again and submit it. The  model operation completes and saves another image.  

  • 01:14:04 This run checks that execution still works after  the server process has been restarted. These model  

  • 01:14:11 links are also available inside the workflow.  When the required file is already installed,  

  • 01:14:17 you do not need to download it again. This is  a useful troubleshooting pattern: compare the  

  • 01:14:23 requested name with the files the application can  actually see. A missing-model message can mean the  

  • 01:14:29 wrong folder, an unrefreshed list, or a different  filename rather than missing weights altogether.  

  • 01:14:36 Once the basic workflow works, you can share its  model files with another installation. Keep 1  

  • 01:14:42 model library outside the application folder, then  point each installation at that library using its  

  • 01:14:50 own configuration. Stop the server before moving  its model files. In Explorer, create the shared  

  • 01:14:56 model folder beside the application. Cut the  existing models folder, open the shared folder,  

  • 01:15:02 and paste it there with its category folders  intact. Return to the application folder and  

  • 01:15:15 copy the extra model paths example. Rename  the copy to extra_model_paths.yaml. Keep  

  • 01:15:21 the original example so you can consult  its other supported categories later.  

  • 01:15:37 Open the companion mapping template in your  text editor. Select and copy its contents,  

  • 01:15:44 then paste them into the new configuration file.  Replace the base folder with the actual location  

  • 01:15:50 of your shared library. The base path points to  our shared folder. Under it, the diffusion models,  

  • 01:16:00 text encoders, and decoder entries identify their  category directories. Keep the indentation and  

  • 01:16:07 forward slashes shown in the template. Save the  configuration, return to the application folder,  

  • 01:16:14 and start the server again. It reads the new  search paths during startup. When a model is  

  • 01:16:19 missing, check its category, filename, and actual  folder location. To find more launch options,  

  • 01:16:33 run the application's help command or open  its official Startup Flags page. The saved  

  • 01:16:39 help file lists the options supported by this  installation and explains what each one changes.  

  • 01:16:46 Read the low memory option carefully. In this  version, it moves text encoders to the processor  

  • 01:16:52 when dynamic memory management is inactive.  When dynamic memory management is enabled,  

  • 01:16:58 that option has no effect. Disable smart memory  makes ComfyUI move models into regular system  

  • 01:17:04 memory more aggressively. Use this when you  want that offloading behavior. Read the memory  

  • 01:17:10 options together before combining several flags  in 1 command. Disable Comfy compiler turns off  

  • 01:17:17 the application's model compiler, including its  CUDA graph feature. Add the flag to the startup  

  • 01:17:23 command when you need that behavior, then  restart the server to apply the change. An  

  • 01:17:28 update changes a working combination of source  code and dependencies. Before making it, save  

  • 01:17:34 the graph and configuration that just succeeded.  Keep the input and output assets as well, because  

  • 01:17:40 a software snapshot does not replace them. We stop  the lesson's server before changing its source and  

  • 01:17:46 packages. This avoids mixing a running process's  old code with files being updated underneath it.  

  • 01:17:53 In Explorer, create a dated backup folder beside  the application. Select the user folder in the  

  • 01:17:59 application directory, copy it, and open the dated  backup destination. Paste the folder there. Keep  

  • 01:18:05 the source and destination paths visible so you  can verify that they are different. Return to  

  • 01:18:11 the application folder and copy output into  the same backup destination. The backup now  

  • 01:18:17 contains separate user and output folders. These  preserve application saves and generated images  

  • 01:18:23 without duplicating the large model library.  Open the backup folder, then user, default,  

  • 01:18:28 and workflows. The saved graph files are visible  here. To rebuild packages, keep the interpreter  

  • 01:18:35 version, wheel sources, platform requirements,  and installation instructions with the package  

  • 01:18:41 list. Model weights can be much larger than  the application. Record their download sources,  

  • 01:18:47 local paths, and hashes alongside the workflow. If  you choose a shared library, preserve that mapping  

  • 01:18:54 too, including any custom weights. Add the saved  package list, source identifier, model mapping,  

  • 01:19:02 and startup options to the backup folder. Keep  them beside the saved workflows and outputs so  

  • 01:19:08 the recovery information stays together in  1 place. Select those files in Explorer  

  • 01:19:14 and copy them. Open the dated backup folder  and paste the copies there. Keep the original  

  • 01:19:19 files in the application folder so the upcoming  update can write separate after-update records.  

  • 01:19:28 Open Command Prompt from the application folder  and activate its environment. To leave the course  

  • 01:19:35 snapshot and follow updates, switch to the tracked  master branch. Then run the pull command shown in  

  • 01:19:43 the companion sheet. The pull uses fast forward  only. Here the selected branch is already up to  

  • 01:19:50 date. If Git reports conflicting local changes or  diverging history, stop and resolve that message  

  • 01:19:57 before refreshing the application packages.  Refresh the application requirements and  

  • 01:20:02 then the Manager requirements inside the same  environment. Let each command finish before  

  • 01:20:07 continuing. Run pip check again and address any  missing or incompatible package it reports. Save  

  • 01:20:13 a new package list and source identifier after  the update. Keep the earlier files unchanged.  

  • 01:20:19 Here the source identifier changed after switching  branches, while the before-and-after package lists  

  • 01:20:25 contain the same versions. Return to Explorer and  select the 2 after-update records. Copy them  

  • 01:20:39 into the dated backup folder beside the earlier  files. You can now compare the installation  

  • 01:20:45 before and after maintenance without overwriting  either record. For a real source update, perform  

  • 01:20:54 a small application test afterward and reopen a  known working graph. Inspect its model references  

  • 01:21:01 and result. Desktop and portable distributions  have their own maintenance procedures. Use their  

  • 01:21:07 documented updater for the installed product.  Do not automatically combine a portable update  

  • 01:21:14 script with manual environment commands copied  from an unrelated installation tutorial. Use a  

  • 01:21:20 Manager snapshot alongside backups of your  environment, weights, and media. Check what  

  • 01:21:26 the snapshot contains. Avoid major maintenance  immediately before a deadline unless the change is  

  • 01:21:33 necessary. A separate test installation can reveal  incompatibilities while the accepted project  

  • 01:21:40 remains usable. When an error appears, record its  exact text, the command or action that triggered  

  • 01:21:47 it, and the relevant environment versions. Include  the earliest useful failure in a build log,  

  • 01:21:53 because later messages may only summarize that  the operation failed. Start with the smallest  

  • 01:21:59 relevant check. For an import failure, verify  the interpreter and package environment. For a  

  • 01:22:06 compiler failure, verify the developer tools. For  a missing model, inspect its category, filename,  

  • 01:22:13 and actual search location. A model-header error  can indicate an incomplete file or another format  

  • 01:22:20 problem. Check the expected source, file size,  hash, and available disk space. Do not repeatedly  

  • 01:22:27 load a file whose download was interrupted and  assume the model itself is defective. Compilation  

  • 01:22:33 caches can require rebuilding after some changes,  but a cache is not the cause of every compiler  

  • 01:22:41 error. Confirm the application's cache location  and the actual symptom. Preserve useful logs  

  • 01:22:48 before applying a targeted, documented recovery  step. Do not delete unrelated caches as a reflex  

  • 01:22:55 or disable protection because an installation  is slow. Measure the failing stage and inspect  

  • 01:23:01 its output. A reproducible small test helps  distinguish an actual dependency problem from  

  • 01:23:08 an unrelated system change. If a server starts but  the browser cannot connect, compare the address,  

  • 01:23:14 port, and process state. A browser connection  problem does not necessarily mean the Python  

  • 01:23:20 environment failed. Keep those layers separate  when choosing the next diagnostic action. If  

  • 01:23:25 a workflow produces an unexpected image, first  distinguish a technical failure from a creative  

  • 01:23:33 limitation. Missing models and execution errors  need environment troubleshooting. Composition,  

  • 01:23:40 text rendering, and prompt interpretation can  require a different model or workflow decision.  

  • 01:23:46 This overview is dated September 2026.  The 1st organizing question is modality:  

  • 01:23:52 what goes into the system and what comes out? Text  can produce an image, an image can guide a video,  

  • 01:23:59 and audio can drive a speaking character or  another time-based result. Image generation  

  • 01:24:05 and image editing increasingly appear within  the same model family. The FLUX 2 repository  

  • 01:24:10 illustrates that combination. Its model table  distinguishes variants that support text prompts,  

  • 01:24:16 single reference images, and multiple references  for editing workflows. The same table also shows  

  • 01:24:22 why the model variant matters for licensing.  Some smaller variants use a permissive license,  

  • 01:24:27 while other weights use different restrictions. A  repository's code license does not automatically  

  • 01:24:33 describe every model file it links to.  For video, the Wan 2.2 family  

  • 01:24:39 provides several generation routes and model  sizes. Video requirements depend on the chosen  

  • 01:24:45 variant and settings. A small model's published  example should not be applied to a much larger  

  • 01:24:52 model without checking. Resolution, frame count,  precision, and offloading all affect the practical  

  • 01:24:59 workload. Audio-driven video and jointly  generated audio-video are different tasks.  

  • 01:25:04 One can take an existing voice recording  and animate a subject around it. Another  

  • 01:25:09 can generate visual motion and synchronized sound  together from the requested scene. The LTX family  

  • 01:25:16 illustrates the joint audio-video route in its  official repository. Its current instructions also  

  • 01:25:22 separate model components and performance modes.  Speech models turn text into spoken audio with  

  • 01:25:29 controls that can affect identity and delivery,  depending on the model. Check the model's official  

  • 01:25:35 list of supported languages. Music generation is  another category, represented by projects such  

  • 01:25:41 as ACE Step. Its purpose differs from ordinary  speech synthesis. Musical structure, lyrics,  

  • 01:25:49 instrumentation, and the resulting audio need  their own evaluation methods. 3 dimensional  

  • 01:25:55 generation introduces another output type. The  TRELLIS 2 repository illustrates image-to-object  

  • 01:26:00 generation. A plausible rendered object is only  1 part of a useful 3 dimensional asset,  

  • 01:26:07 which may also need suitable geometry and  materials. Segmentation, depth estimation,  

  • 01:26:12 upscaling, and frame interpolation often support  a larger media pipeline rather than producing its  

  • 01:26:20 final creative asset alone. Thinking in connected  operations helps explain why a graph interface can  

  • 01:26:27 be useful across these different tasks. The 2nd  organizing question is access to the model. Open  

  • 01:26:34 weights can be downloaded and run under their  applicable terms. A hosted API provides access  

  • 01:26:41 through a service, whose model versions and usage  conditions may change over time. Open weights do  

  • 01:26:49 not necessarily mean unrestricted use, and a  downloadable model is not automatically open  

  • 01:26:55 source in every sense. Read the actual license  and model card. Preserve the specific version  

  • 01:27:01 and terms relevant to your intended project.  The 3rd question is execution location.  

  • 01:27:08 Local software uses resources you maintain.  A cloud GPU provides another machine with a  

  • 01:27:14 defined capacity. A hosted creative service can  manage more of the environment while limiting  

  • 01:27:21 or simplifying some configuration choices.  Check memory, storage, region, queue behavior,  

  • 01:27:29 and job limits, then compare the cost with  the workload you actually plan to execute.  

  • 01:27:35 The recorded Runpod page separates its cloud  modes and billing units. We used the selected  

  • 01:27:41 hourly mode for our examples. The listed graphics  memory and system memory remain separate columns,  

  • 01:27:48 just as they are on a local workstation. Comfy  Cloud illustrates a different model: monthly  

  • 01:27:54 plans with credits used by active workflows and  supported service operations. Its public plan page  

  • 01:28:03 also distinguishes runtime limits and model-import  features. Those details can matter more than  

  • 01:28:11 a headline monthly price. The page's estimated  number of example videos uses a specified template  

  • 01:28:18 and settings. Read the assumptions behind a  pricing example before using it in your own  

  • 01:28:26 budget. The 4th question is interface. A simple  web form can be convenient, while a node graph  

  • 01:28:35 exposes more of the pipeline. Command-line tools  offer another route. The appropriate interface  

  • 01:28:41 depends on the control and reproducibility your  task requires. A custom node adds executable code  

  • 01:28:49 and dependencies to the application, so its source  deserves inspection before installation. Preserve  

  • 01:28:56 a working environment and review the project  provenance. The weight format matters because  

  • 01:29:02 some formats can load executable objects, while  safer tensor formats avoid that mechanism. This  

  • 01:29:10 does not make surrounding code harmless; the  source and loading application still deserve  

  • 01:29:16 inspection. Gated model repositories can require  accepting specific terms before download. Account  

  • 01:29:22 access and license permission are separate  questions. For your project, document the  

  • 01:29:27 terms and source rather than assuming successful  downloading grants every possible usage right.  

  • 01:29:33 You now have a working local image-generation  setup and a saved workflow you can run again.

Clone this wiki locally