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.
1 Like
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.
1 Like
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)
3 Likes
How rude! 
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 
1 Like
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.
1 Like
update
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 
>>> https://github.com/jamesb93/ReaCoMa/archive/master.zip
1 Like
major update
If you are using these scripts in Reaper, please update to the latest version of the master branch found here.
changes
-
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
oswhich is a Lua standard library for executing on the command line but read in the reascript api that there is a functionreaper.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 Windowsreaper.ExecProcess()works without a hitch, while on MacOS or Linux the program won’t execute. The cherry on top is,os.executewon’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.
2 Likes
this. made. my. day.
@weefuzzy might find this very timely
I will have to pester him ^:)
I’m trying the new script with Reaper 5.983. With novelty slice I’m getting this error.
while using the default values
Hi Hans,
That was an easy one. Can you try downloading again? The gist of the problem was that that line of code is trying to write some information to a table that is no longer necessary so it fails.
well, I restarted Reaper, even restarted the computer to make sure that I’m not having an older version in memory. Halas the error still pops up witch onset slice.
You have found another bug which has been made by myself after overzealously culling lines of code. I have tested all the scripts again and they work on my machine. Can you try downloading from the link again and testing for me? That would be great.
1 Like
Yes, onsetslice works with this update. Thanks a million.
Hans
No worries! Thanks for finding those bugs - it helps me too 
update
I now version the scripts so that there is always a tagged stable release (beta/alpha). Right now the scripts are considered 1.0, but alpha because I haven’t tested the corners enough to see what nasty bugs might be laying around and because ampslice~ is not implemented yet.
Anyway, in this latest update a pretty significant bug was fixed to do with the naming of files that come out of a fluid process. Outputs from NMF, Sines, HPSS etc all had unique identifiers made to make sure that there were no conflicts, however, there was a scenario in which having the same file name and take offset would produce the same same file meaning the most recently processed media item would overwrite any others. Now a universal unique identifer is made using system time so that there are never conflicts.
1 Like