i think it was mentioned somewhere in the forums that renoise (the disk browser) can hang a few seconds when there are a lot of files to display
currently i’m organizing my files not so “flat” that it would hang too long, but i personally would like it a lot to see the responsiveness known from windows explorer
on my machine: a few thousand files => 3 seconds hang on each activation of the renoise window etc
speaking of windows explorer: it lets you control (scroll etc) the file view even with ten thousands of files, traverses files and renders the file view nonblocking (just btw: it does this better than popular linux desktops)
i also have very long waitingperiods when switching from song to instrument or samples. I have 104217 samples in my samples-folder, in subfolders, etc, and it’s always been a drag to use the diskbrowser since it takes so freakin long to do anythin.
i’ve taken to sorting stuff more so there’s less folders but with more samples, hoping that this would help with 2.8b3. i’m not sure if it will, but i hope it will help.
the next step would be to start destructively reducing the files to .xrni’s, and hope that there’s some way of extracting the wavs out at-will when-required for non-renoise software. or somethin.
it would work if the case is: “the disk browser does one very lengthy operation to update it’s internal state (that is needed to access the folders and files), and saving/loading this state actually takes much less time”
in short: caching (to say caching FindNextFile on win32, if that’s the bottle neck)
if that’s really the case, why not this feature: “freeze directory”
you’d toggle on the freeze button (setting per directory) when viewing d:\thousands_of_samples and then live with the fact that renoise won’t update it’s internal state (internal list of files, whatever) for just this directory
fluctuaction of files is very low in these folders
so it would be practical, if you’ve added another 500 samples to the folder, to toggle the freeze off, then renoise should not only update it’s list again but also bring a progress window for this operation, and you’d have to watch and wait for the state to be updated
of course, in frozen folders, it would be possible that renoise trys to access non-existing files, or that it’s not being informed of new files, giving error messages (then prefereably in the status line)
but i think this feature would just reflect the fact that OS file traversal simply takes very long
it would be pretty much the same like freezing tracks, a user-controlled caching
Caching is better. It is quite simple to create a cache file containing specific details of each file found and analysed in a file folder.
The only thing scanned for changes afterwards are file modification dates. If any file has been modified, the cache is updated for those files only.
It is the old Impulse Tracker method actually.
Include a small (row resolution) waveform image in the cache file and with a big more code people could scrub the preview stream along a waveform display.
if that’s possible, i’d find a transparent mechanism better too, nothing with user interaction
my impression over the time was just, that renoise might already do a quite fast method (like, it would caches already information about the files themselves) and it would simply not be possible to avoid the little hang for a folder with 10.000 files and more
to be more specific, i thought, that with the plain FindFirstFile functions it wouldn’t be possible at all to look within milliseconds if there’s a new file in a folder with 100.000 files, even windows itself needs a few seconds when you try it (with a dir command)
i’ve just checked it again, with a folder having 766 xrni files + 766 sf2 files it doesn’t hang at all, but with a folder with 40.854 wav files it was about 12 seconds hang
Yep, but we don’t have that here.
Yes, it would be the best possible method. But to be honest, I’ve completely given up on taktik ever acknowledging prior art (ImpulseTracker)
I’d really love this method, it worked so goddamn well with ST3/ImpulseTracker/SchismTracker.
you know what else it enabled? a descript.ion -based (or similar-to) method of renaming samples on the fly (without renaming the wavefile itself)
i’ve measured it with 30.000 valid (the .xyz have garbage inside) files in each 4 directories
i clicked on the folder icons in the disk browser to test
using athlon x2, 500 gb disk (hd502hj) on sata 2 port, windows 7, ntfs
in other words: give the user the ability to control the gui at first and at all time, start giving them the file names concurrently, when done start giving them less important
meta data (thumbs etc), etc
imho explorer even uses a certain order with every loop (start to middle then end to middle) to assure the most visited places (top and bottom) are ready at first
@ IT2: it did update the wave previews concurrently too, didn’t it? with an own context switching between gui and file functions probably
and, as vV mentioned, it cached it in files, but i think this alone without concurrency would not be a fully non-blocking solution
