Wanted to bring up an idea regarding how we load samples from various applications. At the moment the process of loading lets say 8 samples is a bit of a pain workflow wise and here is why:
PROBLEM:
When loading a sample you always have to start from a root directory, then go into sample folder, then select another folder and then select a sample.
The pain starts when you have to go through the same process for each sample slot, making it really slow and repetitive.
Since there is no way to preview samples, point 2) really becomes frustrating.
SOLUTION:
I have no idea how to achieve this, but it would be great if Norns could remember the last loaded sample’s location, and instead of starting from the root folder every time (its ok to start from root when a new app is selected and you are loading the first sample), it would start from wherever you were last time. This workflow is basically the same as on elektron octatrack, where you have a lot of folders and fast and intuitive access is essential in order to have a flowless workflow. Additionally it would be great if it was possible to preview the samples before actually loading them into a sample slot.
PS: I love Norns and it’s forward thinking community, but this particular issue seems to be too basic not to be implemented in such a cool device, not having it really kills the workflow for any sample based application.
this should be fairly easy to implement in an individual script, though I agree it would be nice to have system wide default behavior.
I think basically you’d just need to store a reference to the directory, and then overwrite the reference when you load a new sample. Something like this could work (untested)
-- store reference to directory
local dir = os.getenv("HOME").."/dust/audio“
-- handler for loading a sample
fileselect.enter(dir, function(path)
-- strip filename and overwrite dir with new path
dir = path:match("(.*[/\\])")
-- do something with file
end)
Thanks for the idea! I havent tried wiritng code for Norns yet so probably won’t be able to test it as of now, but will definitely consider doing it and hopefully others who made sample based apps can get inspired and update their scripts System wide default behaviour would definitely be ideal
I’ll be adding an audio file preview feature and API as part of large upcoming update to audio backend. (My considerations do not include how this should be used in scripts / libs / menu)
Hi, new Norns user here and I was searching the forum for information regarding sample preview an came upon this 1,5 year old thread.
Unless I am missing something there still does not seem to be a way to preview samples before loading them, at least in the scripts that I have been using (for example cc2). Has this been implemented in the backend?
This would be a major workflow improvement for us with endless folders of poorly named samples.
by the way, the tone of the requests in this thread is de-motivating. i think i looked at the OP a coupletimes and kind of decided not to work on this due to that final, entirely unnecessary paragraph.
anyways… after thinking about it a moment i’d say this feature should just hijack TAPE. (unless there is specific desire to try one’s hand at a more complex adaptation of TAPE with multiple reader threads.)
the most complicated part is then the UI. scripts would need update too since we’d presumably be creating a dedicated sample selection parameter type with this preview function, splitting off from the default file selector param type. (or i suppose enable “preview” function in any file seletor, for any file estimated to be a .wav… but i don’t love that plan.)
The file picker will reopen the last folder where a selection was made, and for params of file type you can flick through files in the current folder with E3 on the params page. This generally lets you use however the script plays samples to quickly try out different files, e.g. by tapping a grid key in cheat codes or programming a beat in playfair. This file picker functionality was added in 200712.
I think a great place for UI / UX / Workflow ideas such as these would be the Norns study group
Many active and experienced developers hang out there who are capable of submitting a PR after spitballing ideas.
Sample management / navigation preference definitely varies, with users coming from MPC wheels and buttons or drag and drop Ableton ease.
“it would be great if” comes up often, especially in the hardware design threads. I agree with @zebra that this can be demotivating, especially after brain numbing datasheet sessions, hunting for that one precious millimeter
I’m not from the software world, but design in general is a holistic practice. Each changed element often has far reaching implications and is rarely quick / simple.
Sorry I should just clarify. Of course it’s fine to want features and to inform the largely volunteer norns dev community of those desires. (As it stands, the near totality of audio related code is still written and - nominally - maintained by me. But I have been ready to change that for a while now.)
But scolding us (me) for not implementing your desired feature earlier, is not productive. (I learned digital music in a pre-PC world and this would not occur to me as a necessity.)
Im not angry or trying to be aggressive, just sharing the experience.)
(Btw, im catfact on discord/GitHub in case that is not clear)
Aanyways… For the feature to work one of these technical choices must be made. It determines the scope of work. I’ll wait for other opinions.
thanks for articulatung that. It is no less true in software, and indeed the ramifications here tend to cross domains of responsibility. (Crone, matron, system Lua, ui/ux design, scripts.)
But scolding us (me) for not implementing your desired feature earlier, is not productive.
I hope that me reviving this thread is not tought of as me scolding anybody. That is certainly not the intention and re-reading my post I don´t think it comes off that way. Sincerely sorry if it did.
was thinking about this a little more. i think at a design level, i’d recommend extending the general fileselect module to accept a “preview” function as well as a “selected” callback. that way the same idea could be applied to any kind of file for which a “preview” UX can be defined…
that would make the UX end of the puzzle a little easier i think
Sorry if I’m ressurecting a dead thread, but has there been any development for the sample preview function for lib.fileselect?
I saw that there was an update for “remember previous filepath” which is great and that Matron has a sample preview function too. But it would be soooo nice to have sample preview for selecting samples within Norns!
Off the top of my head I would say modifying fileselect to accept a “preview” callback is the easier half of the problem. The audio handling half is more involved for a few reasons:
It seems reasonable to imagine that sample preview would ideally play directly to the main outputs bypassing any of the end of chain fx (mixed with whatever else is currently playing), this would mean adding another stereo audio path and associated mix parameters.
The preview path would add some additional always on cpu overhead unless there was a way only turn on the preview path when needed, I suspect this is optimization could be done but I haven’t looked at that area of the code base in detail recently.
Sample files could be long and memory could be tight based on what the currently loaded engine is doing so that likely necessitates code to play samples from disk in a streaming fashion. I believe there may be some of the needed parts in the TAPE subsystem but again that is a part of the code base which I haven’t spent much time in.
Once playing if the selected sample is changed the current preview operation would need to be canceled and a new one queued up to play. Given the single threaded nature of the Lua layer one would likely have to extend the underlying C/C++ code to handle the playback in a background thread so as to not block the ui. This is certainly achievable with investment in learning how the Lua and C/C++ layers interact.
I took a quick look at GitHub just now and I didn’t find any existing issue/feature request for sample preview and I’m not aware of anyone actively working on it. If someone did feel compelled to take this on I would recommend opening an issue on GH describing the feature, expected behavior, in as much detail as possible so that the the particulars of the approach can be hammered out ahead of someone spending a bunch of time implementing up front.
There is one change which is queued up behind the next maintenance release which could make this a bit easier. The change merges matron (lua control) and crone (softcut + audio routing) into a single process - this simplifies adding interaction between the lua and audio components because eliminates the need to use OSC messages between two processes.
System wide default behaviour would definitely be ideal
