enzienaudio
how to track down "connects to out-of-range let" upload error
I'm getting the following error message when trying to upload to the website:
"Connection [__inlet {index:1 type:--> name:}:0] --> [__graph.ZKfwN(_main.hv.json/Affirmations):1] connects to out-of-range let."
Does this give me any information on how to track down the connection to the "out of range let"?
Patch attached.
Hi @atellio, the short answer to your question is that the error was caused by the fact that we did not support (until about 5 minutes ago) the right inlet to the tabread4~ object. The error that you received generally indicates that an invalid (control, i.e. -->) connection is being made. I have pushed the fix to our dev channel, which you can access using our uploader script with the --release dev flag. Please note however that we don't (yet?) support the offset parameter via the right inlet. But at least your patch won't break anymore.
The longer answer for tracking down Connection ... connects to out-of-range let. errors is:
- You can figured out from the error message which connection is invalid. Admittedly this task can be... hazy... without a lot of a priori knowledge.
- Cutting out various parts of the patch until you can isolate the error. Admittedly this task can be tedious.
Awesome, thanks @mhroth. Re: the offset parameter - do you mean the offset parameters via the right inlet specifically with tabread4~ ? I was under the impression this worked with Heavy in other contexts.
In my case, could I get around this by having messages going to the left inlet of a tabread4~ with the "set" command, followed by the name of whichever table I wanted played?
Also is there a document of unsupported functions somewhere?
Have attempted a little patch testing the above but am getting the error that I'm using unsupported objects. That doesn't seem to be the case, though? Any ideas?
@atellio The short answer to your issue is that our [tabread4~] requires a table to be defined at compile-time. So for instance if you say [tabread4~ A3-0] then it will be fine.
That said, [tabread4~] also has a currently known issue that it doesn't handle the [set< message correctly. This and other issues are listed here, though we are in the process of updating the official documentation.
@mhroth ahh right, I see. All good, I think I should still be able to make the patch work, will just mean 20 or so custom subpatches instead of the one abstract patch with variable. Thanks for the info :-)
@mhroth so I've given [tabread4~] defined tables and am not using the right inlet at all but am still getting the "Verify that you are only using supported objects" error. Any ideas? :-(
Test2.zip
@atellio how are you uploading the patch? I did this with the uploader. Also, I did notice that uploading the patch/zip through the web interface results in an error. But that's because the zip is too large! We support a maximum size of 1MB. Yours is 1.3MB.
I've made a note to improve the error message.
@mhroth was using the web interface and that was it - the file size! will try with the main patch now. Thanks again for your help :-)
success with the main patch! yes!
So in recap for anyone who comes across this:
[tabread4~]needs to have tables set at runtime, doesn't support the [set< message in the left inlet and doesn't support offset parameters- Keep file sizes smaller than 1meg
@atellio that's all correct at this time. It's probably worth mentioning as well that file sizes typically become that large when you are embeddeding audio data into the patch. Depending on your application, it might be easiest to simply read that audio data into the patch at runtime from some framework-defined samplebank (e.g. if you were using Unity or Wwise or something like that).
@mhroth yeah that's totally what was going on - I'm loading audio data into PD from Unity. Mistakenly bundled the audio files with the PD patch. Thanks again for the help :-)
@atellio This project that yuli made may also give you some guidance for reading samples into heavy tables from Unity.
@atellio FYI the "set" message to e.g. tabread4~ is now supported in the dev channel.