Adding complete folder system to device
Hi Guys,
Is it possible to add a complete folder system to your device?
I know, I can make a umenu system, where I can brows files, etc., but I'd like to add a complete library with a lot of files to the device.
Not sure if there's enough information here to know how to respond.. but you can use Node to access the filesystem and read/write with the 'fs' module..
I'm sorry Jay, I'll try to explain it.
I'd like to make a device, where I'll use a lot of files, I mean, thousands and I'd like to bundle these into the M4L device, just to make everything simple.
(Since this will be a commercial product, I'd like to avoid enduser confusion about where and what should they copy, etc...)
If I could just attach the complete directory system into the device and then load files from there, that would be amazing!
You could create an Ableton Live pack via the "Manage Files ..." dialogue in Live
Yeah, but, the device I'm working on should use these files only.
As I mentioned, I could load files, with a dynamic library handling system .... thing.
With umenus and suuch, but would be much easier to bundle everything inside the M4L device.
Did you have a look at polybuffer~ ?
You mean to load all the files into a large polybuffer and keep them there?
...interesting...
As far as I know you only can embed the file references in a polybuffer~.
So this would still require you to build a Live pack, but the user can't add his own files.
Ok, I'm trying to make the folder system, to read from disk.
I have a 3 level director :
DATA/Level 1 folder/Level 2 folder/ files
The problem with it, that no matter what I do, it doesn't save the umenu positions with the Live session...
I know, that it is a checkbox thing, because I've done this earlier, without problem.
This is what I came up with
That is amazing, thank you very much!
Is there any way, to fill the umenu with the filenames and load them into another buffer? I've tried, with colls, etc., but I always freeze out Max :S
I dont know about loading to another buffer but you can populate the menu with filenames using a "getshortnames" message.
Yapp, that is right, but, for some reason, if I use that, the menu populates it without file extension.
It is not an issue on Mac, but indeed it is on Windows.
Strange , I'm on Windows - the code posted above is working
I'll manage that...later.
My next problem, is that I load these files into 1 single buffer and then into a buffir...Now, if I load into the buffer, from the polybuffer, I have tons of files there, all the same single file...
Ok, tried something else, now it works...but, heheh, just my luck.
So, you have three levels, let's say, level 1, 2 and 3.
Now, if you select Level 1 and then Level 2, my umenu will be populated with the file names, fine.
But, since Level 2 is set to save the state with the Live session, every time I open a saved session it literally re-populate the umenu, so that state is not saved...ergh....
I've tried a lot of different things, I'll try to explain the goal, because I'm note sure I was clear enough, but that is clear, that it is beyond my actual state of Max skills :D
I'm trying to make this simple.
Reading the files from a polybuffer, or from the HDD is OK, I've tried both, the end result is the same.
My idead, is that I should use fill 2x5 umenus with the filenames and show / hide them dyanimcally...
But it would be a huge scripting work and I'm pretty sure that there is a more simply, more elegant, more efficient way, it is just beyond me :S
I assume you provide the samples with the device. So if you create a pack they should be in the same location and filepaths are relative to each other. Setting the individual path on load should work
For the different umenues: you could toggle the "hidden" attribute or put them in a bpatcher and switch them depending on your conditions
I store the item number of the selected sample in the umenu. Then bang it when the device is loaded.
Yeah, that'll work, the main sample library will be in the same folder as the device, so yes, that works, just as you've described.
However, the umenu thing is still bugs me. There'll be a lot of files, so have to use the umenu, you know, for future updates, it is much easier to just "re-build" the menu, instead of adding the new files manually to the live.menu.
I'm not sure I can understand the second patch...
Actually, with 2 Umenus, the storing works, do not know why, so if I omit the middle level, it is OK.
So, just a quick update.
I've managed to do something usable...at elast, this would a great starting point to improve.
I have now 2 live.menus, filled with the sub folder, these are fix, won't change.
And, for the 10 different sub-sub folders, I have literally 10 dynamically updated umenus, inside a bpatcher.
Actually, the two sub folder live.menus are controlling the offset of the bpatcher.
Not so clever, nor elegant, but, at least, it works and stable as hell :D