I’ll be adding more as I go to this repo and this repo
copy_change_dur.py has now been translated and requires no installation except downloading the script 
1 Like
I take it the latest update has broken all of these?
Looks as if @jamesbradbury has already updated the executable names in the repo – you may need to re-pull though.
1 Like
Hello all,
The scripts work with Beta02 and upwards. There is no need for anything else other than the CLI tools as released by the team and these scripts.
https://github.com/jamesb93/ReaCoMa Please download the repo from the master branch and see how you go.
Any bugs let me know here or on the github issues page.
P.S
There are some experimental scripts in the /experimental folder. You can try to use these with the disclaimer that I might break them or leave them in a dysfunctional state.
3 Likes
This is incredible. Getting a visual for some of this stuff is worth every penny they are paying you James. Thanks for this!
3 Likes
In all seriousness, I’m really glad you have found it useful. For me it opened up the tools in a way that I didn’t think I would respond all that well to. Any bugs or suggestions let me know so I can include it.
1 Like
@jamesbradbury is providing this community with these amazing ports for free. He only gets paid in kind: special on-demand access to @weefuzzy and myself. Now, one might think it is not much pay… but he keeps on asking
(all banter apart, thanks again James for this fantastic porting)
1 Like
For anyone using these scripts I have found a limitation that is impossible to get around.
If you pitch shift or change the speed of a media item any FluCoMa processing will not respect the changes to that audio unless the audio is bounced/rendered first.
EDIT:
This applies to ANY processing
Also, if you execute a tool with insane parameters (like blocksize 1000 instead of 100) REAPER will hang, you will have to kill it but the process will run on forever in the background unless killed by user. Can’t fix that one unfortunately
are you certain? I sent you links to timing-out computations and advance threading in reascript… check the command reaper.ExecProcess( cmdline, timeoutmsec ) ReaScript API — Documentation
I was aware of the threading but not this call that can be made. I am currently going through LUA and around the API itself once the script is called. This means I can easily implement a timeout across all the scripts :), perhaps something which is configured with a sane default in the situation you want to do a chunky nmf or transient separation process. Given that I can do the command line execution within the API I can probbaly thread it too. Making the command line execute via os.execute is all well and good, but reaper cant see it or thread it very easily into the background.
maybe you could add a variable in the UI with a healthy default, and then if people get timed out, they get the message and can add more time 
Do you want some more time to run:
fluid-nmf @source file @components 1000 @fftsettings 32767 64 32767
1 Like
Not without @iterations 999999999999999 though…
1 Like
Do you mean num_iterations?
1 Like
Oh, I wasn’t kidding at all. I was working on some segmenting in SC, but then checked out this thread. I downloaded the Reaper tools, could see that the values I was giving the segmenter were giving me crap results, spent about 5 minutes tweaking the parameters (which just wouldn’t have happened in SC), then had a great segmentation that worked perfectly. But I just wouldn’t have had the correct arguments to get it right just working in SC because I couldn’t see the results. For that alone, it is amazing. Plus it can do all the stuff as well in my favorite DAW. Incredible.
1 Like
As an aside, this speaks to how useful/awesome it will be if/when @weefuzzy remakes @leafcutterjohn’s slicer visualizer thingy. (and same goes for other types of things (e.g. fluid.ampslice~ envelope visualizers))
On a more topical answer. This is indeed super awesome in Reaper. I still haven’t done anything major in Reaper, mainly relying on Logic (and Audacity(!)) for vanilla “tape recording” as needed.
1 Like
I am privy to some code which is in the works by @jacob.hart I think he should release it to the forum at some point because its clear that slicing parameters (and finding the right ones) is a pain point.
2 Likes
I know you weren’t. And I know visual feedback was very important when I did my learning in Python on most of the prototypes. That is why Reaper integration was on my todo since the first months of the project (hence my reaper scripts endeavours then), so when @jamesbradbury offered to jump in, I was too happy to support
Another good news: @jacob.hart has some visualiser indeed, but very soon there is a whole new lot of KE material with visual examples coming from @weefuzzy…
1 Like
@jacob.hart has very kindly shared his code with me, and I’m going to try and make it a bit faster; with his agreement, we’ll probably include it in the main distro. However, this is Max: I still need to harness enough SC gui-fu to assemble something that would be useful to @spluta.
@rodrigo.constanzo is quite right that being able to see the feature curves themselves would help massively with this, partly because thresholds and curve shapes are so different for various metrics. In my mind, there’s a sort of two-phase idea. The long term idea is a breaking change, where we separate the business of cutting curves from the business of generating them (more flexibility, but also more objects to learn). In the nearer-term, it would probably be possible to simply equip the slicers with new, secondary outputs, without breaking too much of everyone’s stuff.
1 Like