Multiple File Attributes

#1

Is it possible to have multiple attributes of the 'file' type on the same object?

I'm making a file-loader object, and sometimes the type of files I want to load come in two parts, so I need an optional second file attribute.

I did try it just adding a second file attribute to the Factory 'alloc 16b scram load' object, with no actual loading code in the Init section of the object XML, but it seems to cause the Axoloti Core to disconnect with the following error, if the second file path field is left blank:

file cd2352.vsm matches timestamp and size, skip uploading
Generate code complete
Start creating directory on sdcard : /multifile-load-test
creating dir: /multifile-load-test
Done creating directory
Changing working directory on sdcard : /multifile-load-test
Change working directory: /multifile-load-test
Done changing working directory
Start uploading file to sdcard : /multifile-load-test/working
IOException,java.io.FileNotFoundException: /Volumes/NO NAME/talkie/working (Is a directory)
java.io.FileNotFoundException: /Volumes/NO NAME/talkie/working (Is a directory)
	at java.io.FileInputStream.open0(Native Method)
	at java.io.FileInputStream.open(FileInputStream.java:195)
	at java.io.FileInputStream.<init>(FileInputStream.java:138)
	at qcmds.QCmdUploadFile.Do(QCmdUploadFile.java:78)
	at axoloti.USBBulkConnection$Transmitter.run(USBBulkConnection.java:855)
	at java.lang.Thread.run(Thread.java:745)

Disconnect request
Done uploading file

I presume some behind-the-scenes filesystem checking is going on, and it's this that is failing, causing the disconnect.

If I put something (can be just a single character) into the second field, it uploads the first file without an error, and the Core isn't disconnected. I guess this is a bug, but hadn't been discovered before because nobody has attempted what I'm trying to do.

So, I guess my question is two-fold.

  1. Should it be possible to have multiple file uploads to SDRAM from a single object
  2. Is the above error a bug, and if so, can it be fixed such that the second file field can be left blank, without this causing the Axoloti hardware to disconnect?

I should probably file this as a bug-report, but I want to be sure I'm not doing something that is specifically unsupported/not supposed to be possible, before I go ahead with that.

Cheers,

a|x

#2

actually the multiple files is a 'red herring', it does it on single files too...

its an issue with blank file attributes, where the patch has been saved.
I suspect, whats happening is the patches directory is being added to the filename, and then the filename length is being checked to zero or not. (hence why unsaved patches work)

a quick check of the code, indicates this is likely, but I will need to check tomorrow in the debugger to be 100%, then I will fix for next release.

#3

Ah, sorry, I didn't test with just a single file attribute.

File that as a bug-report, then :slight_smile:

So it should be fine to have two of them. Good news.

a|x

#4

yeah, seem to work the multiple attributes from the quick test i did.

for the time being, you can probably work around, using a 'text' attribute, or a string input.
you wont get the file choosing or automatic uploading, but will let you continue, till a release is made.

#5

I'll probably just put a big warning in the module description, if I release it before the fix is rolled out. Afterall, it doesn't crash the patcher, and the workaround should just be to put something in both fields. My code will check if the second file exists, and only load it if it does.

a|x

#6

ok, Ive fixed this in dev, so empty filename is handled in same way regardless of patching being saved or not.
(might be mid term, we review this further, as per others posts on sample handling and resources)

#7

File-loading with optional second file now working (though the bug still exists, so you still have to put something in the second file field).

I've also implemented crc32 checksum generation, which I'm using to identify the files. It's massive overkill (I'm sure there are way easier ways to id them), but it's quite a cool thing to do, anyway.

a|x