Do you mean
Do you mean
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.
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.
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.
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
@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.
Why breaking? Can’t it just be new devices along-side them or something? Or perhaps instantiation flags.
Either way, this would be super useful, and looking forward to seeing @jacob.hart’s code, as well as the new KE dump.
Could be that we’d be able to wrap things up so that an identical interface would be available.
But I’m not going to rule out actually breaking changes in future versions if we manage to hit upon a way of dealing with the various interface challenges that have arisen so far (incl. the managing number of parameters, and being able to discern their relative importance). Rest assured, such things are a way off and – by definition – v2.0.0+ kind of things. That’s one reason I have an interim mechanism in mind.
This sounds really cool to be honest. Yes, more code is scary and especially in Max makes patches less understandable as they suffer digital rot, but being able to access that data could be so fruitful. Exciting prospects!
I get that.
A v2.0+ breaking change is very Apple-esque. And obviously if it’s important and makes things better, I’m for it. But I have to imagine people would also be upset by this (if older patches no longer work and/or need updating). Or maybe a
@legacy flag or something, so people could keep existing patches without rebuilding stuff.
Hello! The afore-mentioned visulaiser. As said, Owen is optimizing it but if you want to give it a go as it currently exists! (btw cmd+click to add slice)
Seriously, I think that we all agree that backward compatilbity is important for a trusting relationship with an emerging community - don’t worry, the plan is not to change stuff that do not need changing, and as @weefuzzy said there are contingency plans. But at the same time, we cannot fix interface design grievances without changing them
For anyone using the new REAPER 6.0, scripts should still be working but if you run into a bug can you let me know here?
Unfortunately the prompts in the scripts didn’t adopt the new sexy interface
My version needs updating since I bought 4…7 years ago! These guys are incredible.
I finally bought bought it… been sitting on the demo of 5.9xxx for ages waiting for it to tock over before buying.
these scripts now work under Windows and Linux (untested) too.
The only caveat of windows is that you have to execute the scripts with the toggle for restricted permissions OFF. This toggle is put there so that you can block scripts from accessing anything outside of Reaper, but we need to call the command line from within the lua scripts. This is not dangerous in anyway as long as you trust the script writer
If you are using these scripts in Reaper, please update to the latest version of the master branch found here.
Parameters now remember what you used last and don’t return to the default arguments between repeated uses of the same process.
I was using
os which is a Lua standard library for executing on the command line but read in the reascript api that there is a function
reaper.ExecProcess() which can be used to do the same thing. In an effort to make things as reaper native as possible I converted all the scripts to use the reascript function rather than the lua specific one. What I did find out that is on Windows
reaper.ExecProcess() works without a hitch, while on MacOS or Linux the program won’t execute. The cherry on top is,
os.execute won’t work deterministically on Windows inside Reaper, so these two ways of calling the command line are mutually exclusive. To get the best of both worlds whenever you execute a ReaCoMa process Reaper will select which function to use based on your operating system.
I also removed a lot of cruft from the code and tentatively started implementing
ampslice~. I also overhauled the way parameters are known inside the scripts so its much easier for me to add the new objects coming with Toolbox 2. It should be a matter of minutes, rather than hours.
If you like to manage git and are pulling from the repo here is the link.
this. made. my. day.
@weefuzzy might find this very timely
I will have to pester him ^:)