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:
- 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.
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
-- strip filename and overwrite dir with new path
dir = path:match("(.*[/\\])")
-- do something with file
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)
storing folder position is an easy update on the param menu, will get that in
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.
no. not sure why i said that. maybe i was actually thinking of the TAPE feature.
to be honest i’ve had little time to actually implement things on norns for the past 1.5 years, because of things happening.
if someone wanted to take that over, they could:
- make another instance of the Tape module, basically.
- (or in fact, this feature could just temporarily take over TAPE, in which case it is already done)
- spawn a new process playing to JACK system sinks
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.
Nah, sorry you’re right, I’m reacting to the OP. (And to a not-uncommon dynamic in these interactions.)
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