Towards a useful file browser.

    Leo Mayberry
    Nov 20 2010 | 8:50 am
    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.
    • R∑N∑G∆D∑ R∆J∆
      Nov 20 2010 | 11:32 am
      on general improvement of integration, i agree(whenever i've used it, it's because i've forced myself to, not because it adds convenience; i need to be able to key/midi/osc through loading of multiple files in a folder/sequence some way, so setting up my own drag-drop-umenu with control elsewhere is just more convenient).
      but then maybe i'm trying to make it more than it is. it seems it's just a file 'browser', that's it. not a dedicated 'file loader' or 'file triggerer' nor even a 'file manager'. the drag and drop is just an added convenience to allow you to view the media you're browsing and find what you want(besides, i'm not sure what else besides mouse-interaction would be as easy: you can scroll viewing of files and folders up and down using arrow keys, but then how would you target a specific buffer~ object in your patch out of many to load a soundfile from the file browser all using keyboard shortcuts?)...
      but i guess that just means i'm a little baffled by it, too.
    • Roman Thilenius
      Nov 20 2010 | 5:16 pm
      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
      Nov 20 2010 | 8:28 pm
      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
      Nov 20 2010 | 9:24 pm
      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