buffer @file dependencies don't seem to be picked up by export or in project view
So I'm currently struggling to get exporting of audio file dependencies to work with RNBO.
I have a main patch, with an rnbo~ abstraction that has multiple buffer~ objects inside, and it works as expected with either the audio files being in an external folder that's added to the search path, or if I manually add the files to the project.
If I export the rnbo abstraction though, then despite having the Copy Sample Dependencies checkbox set, I don't get anything in the media folder in the export, and the dependencies.json file is just an empty array.
I'm also not seeing the samples shown as dependencies of the main patch, which the docs about rnbo and max projects seem to imply I should be.
https://rnbo.cycling74.com/learn/max-projects-and-rnbo
I've tried various different itterations of all of this, with the rnbo patch being a separate abstraction, or just a subpatch, and with media files explicitly added, in separate folders in the search path, and with/without consolidation but nothing seems to work.
I know that I can work around this by setting dataBuffers from within the javascript, but I'd prefer to be able to use the built in dependency management stuff, so any help is appreciated.
Hey TASTE, this is a known bug that we have ticketed as #17700 to be fixed in the next RNBO release.
In the mean time, as a work around, you should be able to put whatever files you'd like in your media directory and then edit your dependencies.json file by hand (here is the format):
[
{
"id": "foo",
"file": "media/ion.wav"
},
{
"id": "bar",
"file": "media/vexovoid.wav"
}
]
If you look in your patch.export.json or your description.json (depending on your export) you will find a block like:
"externalDataRefs": [
{
"id": "foo",
"file": "ion.wav",
"type": "Float32Buffer"
},
...
that shows you the ids that you need to reference in the dependencies.json, though you also know them from the name of your [buffer] or [data] objects.
Unfortunately this won't work for plugin exports that are build on the cloud compiler, but I see you're working on the web so I think you're okay.
aaahh, right. thanks for explaining.
that workaround is fine for the time being, was just concerned there was something I was missing.
and yep, building everything locally so have full flexibility.
cheers very much
Has this been resolved yet? Still running into this bug in version 1.2.3
JSELODY,
Can you tell me the steps to reproduce your problem? What export are you using, are you using the cloud compiler, can you share a patch that illustrates the issue?
Alex,
I'm experiencing a similar issue with exporting a RNBO patch to the Raspberry Pi, which includes about 20 short WAV samples. Curiously, only a random subset of these samples seems to be exported. This issue persists even when I simplify the patch and reduce the number of samples in a smaller test case. Despite this, the full patch, albeit with a limited sample set, does function, although not as intended due to the missing samples.
I have ensured that Max and RNBO on the Pi are up to date, along with all operating system packages on the Pi. I plan to explore manually updating the dependency file as you suggested. However, it would be preferable to resolve this issue, as my project involves numerous iterations, and relying on the exporter's functionality would be much more efficient. Furthermore, the final version of my patch will contain significantly more than 20 short WAV samples, so manually updating the dependencies for each iteration would be quite cumbersome.
Thank you for your attention to this issue.
Best,
Luke
in my case - saving untitled.rnbopat in folder with dependencies helped
I’ve found that sometimes if I start an export of a large patch while max is still automatically building / compiling the patch, then dependencies.json in the export folder will be blank.
This was happening to me fairly regularly. I’ve now got into the habit of waiting for the automatic compilation to finish before exporting, or just switching off ‘auto-compile’ and it rarely happens to me now.
I’ve not properly looked into it to see how reproducible it is tbh, but it could be a bug.