Using a TXT file with coll instead of embedding in patcher?
Hi,
I cant seem to get this to work. No matter where I put my text file (in the search path), coll will not find the txt file to load its data.
So I name my coll object [coll MyCollData.txt]
And then I add a file to my search path called "MyCollData.txt" in which I put the data to be used in coll.
However, coll will not load the txt file. There are no error messages or anything. I'm sure this used to work with older versions of max... when we used to have to add resources files to the "program files" folder on windows.
Does anyone know how the new "user" folders work for Max 7? /My Documents/Max 7/Packages , Library, etc - I've found them to work quite strangely/specifically, particularly for loading MXJ's etc - requiring a "java-classes" folder in a certain hierarchy...
that's not how you do it-- you need to send it a read message. the argument is not a file name, it is just a reference so other coll instances or a cellblock can reference the data once it's in memory. there is also a corresponding write message if you want to save the data if it has been changed
I disagree with @Floating. See the reference page for coll, explainling the arguments. It works fine for me in Max 7.1 on Mac OS 10.8.5.
Since I'm not on Windows, I can't rule out the possibility that it's a Max for Windows bug, but more likely Max is just not finding the file. I get no "file not found" error message if the file doesn't exist.
@Christopher yes you're correct-- my apology for the misinformation (I've never used it that way);
however if there is some undiagnosable problem you could try to explicitly send a read message (triggered with a loadbang) with file path and file name and see if that works
I recently had problems with coll not finding their argument file with standalones I built under OSX and Max7. I don't remember the details (I won't have access to the right computer and email exchange with c74 support before monday) but it was related to file extension. I think that coll could find its file into the standalone if the .txt extension was removed in the argument. I can check that on monday but in the meantime you should try to remove the extension.
Maybe you should also make sure you don't have more files with the same name (even with different extensions) in the search path.
p
Yes I confirm: if you want your coll's to read text files in a standalone , make all text files without any extensions. In my case (Windows 10, Max 7.3.4) , coll would not read the text file (in the standalone) if the text files had '.txt' (although this worked as expected in the Max patch).. Must be a bug in Max..
This is an old thread but I'll try my luck. I am having the same problem of a txt file not being found by Max. I have tried removing the .txt extension. I am using the Windows and have the txt file in the same directory as I have the patch.
Should it be somewhere else? I have not managed to work out where to where Max is looking for it.
files are found by residing inside the search path of the current max runtime.
for subpatchers it usually also works when it is beside the motherpatch, but i would not count on methods like this.
and dont forget to use unique names.
Thanks @Roman, apologies but could you express that differently? I don't understand 'current max runtime' - newbie here.
Thanks @Yaniki the coll came empty in your example. But I don't want to save the data in the patch, I want it as a separate txt file.
Hmmm... my example is not about saving the data to the coll. It should read data from file (afile.txt) when patch is loaded and put it to the coll.
Did you seen any error messages? The patch I sent you is extremely simple and should work on every platform and all Max 8.x versions.
i said "current" because if you for example use the patch in max4live later, or build a standalone, or share it with someone, that other max runtime might have a different search path set.
that is why it can be clever to put all files for project X in a folder called project X and put that into /patches or /packages
@Roman
Yep, agree with every single word (not to mention the whole structure and senses of the words you used) ;-).
@Yaniki, apologies for not reading the directory carefully enough. However, the text file is not being read by the coll, which is empty when I double click it. On my machine, your example has exactly the same problem as the patch I am working with. (I am working with Max 8.)
@Roman, thank you. I have it set up so that the patch is in the same directory as the text file - i.e. everything inside the the folder for project X. But it's not reading it.
Can you direct me to the place where I can check where Max is looking?
"Yep, agree with every single word"
but, if you allow, i will correct the typo in "max4life", because, while it might be a term with a fixed meaning for some of us, it is definitely not a max runtime.
side note: in max v4, when you name a coll and there is no file of that name, it will throw an error message in the console, and that even when it has content stored with the patch.
side note 2: in the rare cases where i use files, i call them by loadbang and i name them "*.coll". (maybe not the best idea if you are on windows? but until now it worked there, too.)
(maybe coll should have a binary file format option such as we have in detonate or jit.matrix.)
Hello Yaniki,
many thanks for the second example. The separate read message did the trick - I was able to navigate to the text file. On the max console, it prints what it should in your second example.
HOWEVER...
I have now looked again at your first example and realise the error was mine. I had not unzipped the directory, I think that's why it couldn't read it.
I didn't realise I needed to instruct coll to read - I have now added the loadbang + read in my patch and it works.
Thanks very much!
Oh, perfect! I am very glad that the cause of the problem was finally found!
For me, it was an interesting issue, because I use similar mechanisms very often in my patches, which then reach other people and I was worried that possible problems might arise.
Happy Halloween!