Some issues I discovered when testing the Generative Nature patch from this thread.
- I open the
Generative Nature.vcv file in VCV Rack.
- The Basic Wav Player modules don’t have any samples loaded, as expected. But note that instead of displaying the
Load a Sample message, all six display the Error loading file message.
- I right-click on one of the Basic Wav Player modules and select
Load Sample …
- A macOS file picker dialog appears, as expected.
- I navigate to the samples, which I’ve moved to the VCV Rack user folder, and select one.
Expected outcome: The selected sample loads in the Basic Wav Player.
Actual outcome: No sample loads and the Error loading file message still displays.
When I test the Basic Wav Player with the same samples in a new patch, everything works as expected:
- I open a new patch file in VCV Rack.
- I add a Basic Wav Player, right-click, and select
Load Sample …
- A macOS file picker dialog appears.
- I navigate to the same set of samples and select one.
Outcome: The sample loads in the Basic Wav Player.
Some more testing:
- Open the
Generative Nature.vcv patch in VCV Rack.
- Try to load a sample manually on the first BWP.
The sample doesn’t appear to load and the Error loading file message appears, as described above.
- Delete the Audio device, or change the output setting from
No device to a device.
The first BWP waveform display changes to green, although the Error loading file message still displays.
- Click the Play button on the first BWP.
The sample that we tried to load in step two plays normally, and the name of the sample displays.
OK, that’s strange. It behaves differently on this patch vs. on a freshly-created patch (even if I simulate a missing file by moving the .wav files to a different folder). I’ll try to figure it out
The first BWP waveform display changes to green, although the Error loading file message still displays.
This part, at least, I understand: the BWAVP just doesn’t clear the error message.
1 Like
Yeah, it’s weird! I did decompress the .vcv file and discovered that the paths to samples are hardcoded — each BWP has a data parameter that contains a path to a file in Ross’s user folder, like /Users/ross/Desktop/blah/Sample.wav. So I wondered if that could be the issue. But I deleted those lines and re-compressed the file and the problem persisted, so I guess it is not?
So, digging into the Rack patch.json file, the only thing I found that makes it work or not work is changing the Audio module’s data field in the vcv patch.json file to be the actual device being used (e.g. the name of your audio device), or removing this line:
"masterModuleId": 2671016074292391
Removing that is the same as unchecking “Master audio module” in the Audio module’s right-click menu. Or better is to just select your device in the Audio module, as you found.
It seems that this is how Rack works – if the audio device is invalid but selected as the Master, then it won’t run the modules but runs the GUI only. I didn’t see bug reports of this on the Rack forum, so maybe there’s a good reason Rack works this way (or there’s some way to work around this to make patch files more share-able, that we haven’t discovered yet).
I think in the future when we share .vcv patch files, we can manually de-select the audio device, and then uncheck Master module. That should allow modules to run as soon as the patch is opened in VCV Rack (since Rack will fallback to running modules itself if Master mode is unchecked).
Also I can update the BWAVP so that it clears the error message once it has a valid sample file loaded (right now it waits until it starts playing)
1 Like
Interesting! Ok, glad we learned something.