Polybuffer~ issue : files can't be found (@embed 1)

is there anything in the name of the folders that breaks the path ?
You can test that first simply using dropfile,
drop the folder and look at the output.
If that is working as expected, then I would rather remove
embeding and store path to folders in a text file
which anyway makes more sense if patch gets used on other machines
having different paths etc

Hi,
Thanks a lot. Your answer was helpful. But this is still a mystery to me.
The "readfolder + path" message works if I apply your method (using the path from the dropfile object). BUT, I get the following error message when I JUST replace the name of the folder by another name in the path, by typing the name. If I use dropfile again to copy paste the file path, then, Oh, miracle, it works (and I don't think "toto" is a very complex folder name. No typo involved).
Previously, I either got "couldn't find file" reopening the patch with a [polybuffer~] and an "@embed 1" attribute, or "toto" is not a folder using the "readfolder" message and an absolute path (the folder I tested that option was named "toto".
My file names were written with the following syntax: 01_A_FileName_0.wav 01_1_FileName_1.wav etc.
In one case, they were properly reloaded, in another they were not. The folders were named BLABLA1, BLABLA2...
Out of 4 folders, I had no issue reloading 2 folders, and issues with 2 others. All names were formatted exactly the same.
I had used dropfile before, and the folders were loaded properly. So there doesn't seem to be any issue with the folder or file names.
I have used [dropfile] to find the absolute path, copy paste it. I have removed all _s but I haven't removed spaces. My files have been correctly loaded and they could be loaded automatically at start up.

So, although I have no clue about why it didn't work, now it seems too. I now need to find the correct relative path. If ever you have an idea about that, that would help. Although I am used to patching quite a lot, there still are things like file paths that are alien to me. Don't know why.

Thanks!

Relative path to what ?
The patch, or Max app or Standalone ?
There are several ways to get the path of all of that.
here few examples

and yes somethings one can't explain why things don't work even that by all logic
they should.
May also be a bug of some kind in polybuffer

Well, for the moment, a relative path to the patch, and eventually, to a standalone. I'll look into it. I definitely think there is a bug implied.
I have deleted all _ and spaces from the file names, and it seems to work with the embed method. Only, I need to test it from someone else's computer, and then from the standalone.

To work on other computers ...
I would really advice in using absolute path to the patch
or standalone, and combine root path with folder names
to load samples using readfolder message.
That is a safe way which never failed for me.
What one can't have under control is if users make folders
that have slash or colon in the folder name.
Once I had a customer that prepended a space in front of HD name
on Mac.
Max was not able to cope with that, space was removed from max path creation,
resulting in nothing found.

Hi,
Thanks for the patcher. I am a little confused with the different options that are displayed. I have trouble understanding the difference between the app and the standalone. I'm sorry to ask you to be more specific about it, but my issue is that I am working on a Mac, and my customers use PCs, and need a standalone. I cannot compile a standalone for PC, therefore I am not able to test the PC standalone option. Would you have the kindness to give me more precisions about your patch?
Thank you so much.

Coralie

i'll be glad to help you about that.
How do you plan to deliver software to PC users ?
In fact one could put together windows strandalone on mac ,
it just needs some tools and a bit of knowledge.
---
In the patch I there are different ways of getting path to itself,
while programming in Max it is folder where patch is, in case
of standalone, it is folder where standalone resides.

On windows there are not that many restrictions as on mac,
so one has more freedom where to read or write files.
Do you want the samples to be in the same folder as Application ?
On windows no problem at all.
Windows standalone usually gets compiled into a folder named same as
executable - like Samp-Player, and in that folder
Samp-Player.exe, Samp-Player.mxf file and resources folder is included.
One could use that root folder to load samples.
------

Hi Coralie, while not a standalone, I recently did a windows release from my mac for an external, and I highly recommend setting up a windows virtual environment. You can do this with a free copy of windows now, there are various windows images meant specifically for testing software on windows, or you can use a full windows install and not activate, which Microsoft tolerates for testing. I did not hit any issues doing that. I used Parallels, which is a paid product and is apparently the best working host on Mac, with very easy sharing between the windows and mac operating systems, but you can also use free hosts such as VMWare. hope that helps.

iain

Hi Source Audio,
The standalone will be integrated in a simulation environment for medical use. The data will come from a server using nodes.js. Responding to this data, the standalone will do its job (play sound files, interact with the user with a sound synthesis engine.
So we have a global program which is quite powerful, into which the standalone is integrated. No direct interaction will occur with it. Everything goes through the simulation program.

I will have 4 sound files folders embedded in the main folder from which the standalone will be compiled.
If I deliver the root folder and the patch that includes the module that will generate the path to load the sound files, they can compile the standalone.
I guess I need to know how to name the folders correctly.

I Iain,
Thanks for your advice. I am pressed with time, so right now I cannot set this solution, but it will certainly be useful to me later.