Towards a useful file browser.

Leo Mayberry's icon

I'm still a little baffled as to the purpose of a specialized file browser that doesn't integrate into a patch. Drag and Drop is not an option, as window switching on a Windows system creates a freeze in Jitter. Drag and Drop is also a tedious and sloppy method of choosing content. Instead of being able to use the file browser by keyboard or other methods, one must mouse the selection over to a particular drop point. What piece of software only functions using drag and drop as an input method? This is certainly not a viable way of performing. There is no functional difference between the C74 file browser and just using a system file browser to do the same thing.
There are ways of creating your own file browser with menus, lcd, and other convoluted methods. All of these efforts to reinvent the wheel could be eliminated if the browser was able to be integrated into a patch.

Roman Thilenius's icon

i see the problem but also see no solution. if a filebrowser would be in any patcher window,
or in an external, it would still be a filebrowser with the same functionality.

so creating a custom filebrowser seems the way to go if you want to load AIFC type files
from all over your system into a certain buffer.

darag and drop .. i use it a lot .. for vst plug-ins, bpatchers, samples, even for script-creating
objects ... but i am not performing live, usually that is done even with DSP off.

-110

Leo Mayberry's icon

This was my initial reaction to the file browser, and I had completely ignored it, but the "Vizzie" example seems to present the file browser as the substitute for a module that would do the same thing. The problem is that it is filling a gap with a broken solution and considering it taken care of. What other piece of Max is not accessible from within a patch? Just seems odd.
My point about the keyboard/midi thing was that right now there is only one way to use the browser, whereas integration would allow other methods of controlling it. The most obvious example would be selecting a folder and then being able to step through the files in it sequentially. Yes, you can do this with menus... but show that mess to a normal human being instead of a Max user and they just think you're an idiot for not having a real file browser.

Roman Thilenius's icon

Yes, you can do this with menus... but show that mess to a normal
human being instead of a Max user and they just think you're an idiot
for not having a real file browser.

i absolutely agree, that is exactly the moment when my C and java friends
are laughing at me and my max.

we have opendialog, savedialog, and if we need more, we need to build it
from scratch.

(same with midi btw: we have [detonate], and when you compare its
possibilities with java, you wonder if max really is a midi program.^^)

but it seems we also agree that an external for easy access to easy file
browsers are not even half a solution for perfect access to files.

i have been using my (relatively complicated) custom abstraction
110.folderfiles and also sometimes the good old 242.axial, but even that is
somehow to much work for what you get in the end.

my solution for all this is that i accept that file browsing (as well as searching
for files) suck anyway during creative work, so i only use folders with known
names inside the maxmsp search path now.

in an optimal case, i would for example just automatically rename 1000
audio files or textfiles in order to be able to call them by name without any
requirement for paths and filetype bullshit.

-110