Woooooo it works - you need to save the project first though, but I just got a-ma-zing-ly fast novelty segmentation, undo-able, on MFCCs, in Reaper.
I’m soooooooo happy!
coming fix now by using a temporary folder among some other QoL changes so i can expand this to the other algos
Okay made some pushes.
-
The scripts can now all be placed into a folder inside your scripts location. They work regardless of where they are as long as they are ALL IN THE SAME FOLDER.
-
The first time you try to run anything the scripts will ask you to set your path to the flucoma executables. Once this is set, it remains persistent across reaper sessions. If you do need to change it because you made a mistake or want to move the CLI stuff somewhere else, you will need to run FluidEditPath.lua script.
-
Everything uses OS standard temporary locations, so no funky errors because you are working in an unsaved project.
-
You don’t have to have the media in a project, it can exist somewhere on the disk that is not a reaper project. Woo!
Things to add/fix:
If you are segment a media item, then try to segment one of the segments it will return an error. Not really sure why right now, but I’ll figure that out later.
1 Like
Not entirely the case. You can put the scripts anywhere as long as you can find them again when you call the “Run Script” action in Reaper. You could put them in documents, or in your root directory, or on a thumb drive. There is a standard location, but its in Application Support and I find it gross to go and find all the time.
Yep, again as long as you know where it is thats fine. The first time you run any of the scripts it will ask you to set the path to this place. I would recommend not touching /usr/bin and use /usr/local/bin/. I just use dev folder in ~/ for local stuff that isnt synced to the cloud and goes up to github via git.
Yes, multiple items works as does undo. The only thing I can’t find how to work is if you segment something, you cannot segment the segment yet. Although I think the solution is trivial and a matter of configuring offsets.
I see why in your code: you assume that one wants to process the whole file, as I mention above.
You should take an item’s D_STARTOFFS (the offset in the file) and D_LENGTH(how long) and convert them to samples and throw them in the CLI call as -startframe and -numframes.
This is already soooooo coooool!
if you want to go crazy: in Reaper, an Item can be a subset of channels too. You could get those 
You’ll have to explain that one to me. I am still a massive reaper noob
you are talking about the subchannel idea? I can show you in 5 seconds if you’re in tomorrow morning. You know where to find me
I will be after my vegetables arrive…
2 Likes
I agree. This totally feels tutorial/KE-worthy as an addition, particularly since doing it in this way removes the need for having to deal with all the buffer~ creation and management in Max-land.
As I don’t know complex the Reaper scripting can be, but is it possible (technically speaking, not in terms of ease of implementation) to do things like NMF/HPSS/etc… splitting in Reaper where it automatically places the generated clips on new tracks that are time-aligned?
This oddly makes sense here…
I planned to compose more this week, but totally rabit holed with this and have totally given over to it. So once I figure out this horrible recursion ive created in the user interface, I want to make exactly what you said for NMF/HPSS etc. It’ll be fairly easy to port to every algo once I get one perfect.
1 Like
With one caveat: some algo want to create and keep new audio files, but that is trivial for a code-rocking star like you 
thanks so much for doing this!
p
Easy enough to follow the convention of reaper. Store takes next to the source with incremented names :^)
1 Like
Sorry to spam this thread:
I couldn’t fix the bug where you cannot segment a segment so I moved on to make the script work on multiple selected files. In doing so, I was reminded that LUA uses immutable strings and to work on many files I would have to store every set of parameters in a table prior to executing the slicing. Now everything works!
What would be the ideal mechanic for NMF? Right now I have something which creates the NMF and adds it as a new take to the source item. You can then explode take to new items, then explode multichannel items to new tracks but I don’t want to assume thats what anyone else would want. I somewhat think going straight to new tracks is a bit heavy but I think that another option is a child track containing the multichannel audio.
the behaviour to new take is the best one for the reasons you mention. people can make a script of a chain of script if they want to explode it to tracks automagically.
thanks
I would personally want it to go to a bunch of tracks, since I don’t think I’d ever want to NMF, and then not have each component isolated.
Perhaps a chain of scripts then so it’s more flexible?
I’d vote for takes by default too. It’s a very convenient interface for A-B-ing, and it’s easy to explode.
1 Like
Okay, seems the consensus seems to be takes. It is very easy to use default actions after that to get the desired configuration. Sorry for not tagging you @weefuzzy! I forgot you were lurking in here
There is a working NMF tool now. Due to its long processing times the whole of REAPER locks out while it processes. I’ll see if there is a way to make it defer the GUI or something so you can keep going because its all being done in the shell anyway…
1 Like