Do you keep a tally of who finds the most bug aka your favourite users? I’m so loving them (the tools not the bugs 
I think you are leading with @tutschku on your trail! Maybe one day when there is no industrial action or pandemics we can sit down and sort out this ampslice business
1 Like
ampslice has had a serious rewrite so don’t lose time on the version you have…
Roger that - I’m working on making some of the ‘experimental’ scripts work now anyway
you can pop in the office this week if you want a preview
1 Like
Will do! Pandemic pending 
1 Like
update 1.3
Hi everyone,
I skipped two minor versions because I screwed up my git tagging, but there is a new release with some subtle but powerful features.
Any processes that produce new items (layers/objects in FluCoMa lang) work on reversed and stretched items. Very soon they will also inherit any take FX and envelopes from their parent.
There is also some ‘experimental’ scripts which people may be interested in. They’re super untested and always changing but perhaps interesting to talk about at this stage and experiment with given some digital supervision. You can check these out in the ‘experimental’ folder on the experimental branch.
3 Likes
Hello everyone. I have a update for anyone using ReaCoMa. The scripts are now at version 1.4 with lots of significant upgrades.
https://github.com/jamesb93/ReaCoMa/releases/tag/1.4.1a
Changelog
- Added the two new slicers
ampgate~andampslice~ - Fixed a sneaky mistake where the first slice was being ignored
- slicers produce time aligned slices on both backwards and forwards items (disclaimer: this works by editing the output rather than input)
- slicers produce time aligned slices on time stretched items (disclaimer: this works by editing the output rather than input)
- Linux is fully supported and tested (Thank you @francesco.cameli)
- Added new scripts under “Tagging” that assign notes to items based on descriptors. These will be useful for some scripts in the future
- All the calls don’t populate the global lua namespace anymore so they will be completely isolated from any scripts or extensions that you run yourself.
- Scripts have been submitted to ReaPack pending approval if you want to update that way.
I put together a short video of the changes with some demonstrations on how some new functionality works (for example ampgate~. This is a kind of preparation for myself as I will be putting together a series of tutorial videos that cover installation, setup and usage of the ReaCoMa scripts in conjunction with REAPER.
The video can be found here:
Thanks!
2 Likes
I remember that the user parameters where kept between calculations in an earlier version. This does not seem to be the case with onsetslice anymore. Every time I’m calling the function, I’m getting back to some ‘default’ settings.
No sure if this is me not doing the right steps.
I cannot reproduce either.
Only thing I can suggest is to update to the latest version if you arent already.
1 Like
My bad @tutschku I was on a branch where I fixed this inadvertedly. I’ll post a fix soon and point you toward a copy that fixes this.
1 Like
Try this one @tutschku. You can also be my guinea pig for the version checking functionality
ReaCoMa.zip (38.4 KB)
Beautiful. Working!!!
3 Likes
Excellent! Bug squashed.
I always seem to have issues with versions and everything, even though I’m not really changing things.
Can reacoma just come bundled with the CLI so that no configuration is required from the user and that whatever version you have would be guaranteed to work (with whatever version of the CLI it came with).
I guess this would leave people who do “normal” CLI with two copies of it on their computers, but it would certainly make the reacoma experience more seamless, as I presently have tiny windows where “everything works”.
This is possible and legal under the license which is used but there has been a discussion around the pros and cons of this idea with other people and most importantly official FluCoMites. The major downside with packaging a dist of the tools is that it makes ReaCoMa a separate entity from the community, the tools and general open practice which I think is being developed here. There is additional responsibility managing the command-line executables which can be annoying but most of the time any errors related to versions come from either 1. me breaking something and sending a specific copy of the code to someone over this forum. 2. The person not updating their tools regularly enough. I’d say the balance is 9/1 in those two errors and once ReaCoMa goes ‘public’ I won’t really make any changes on the master branch or in the version 2.0 release. In that scenario will very much be a ‘here is the version of the tools it works with and these are the features you get’ at that release and anyone who wants to tinker with or get the latest stuff will have to accept the responsibility of faff, downloading versions, git what have you. I also don’t want ReaCoMa to turn into a kind of consumed/installed REAPER extension like SWS but more so the original hacky and investigative tool that it began us (hopefully with no bugs or popups ;)).
Right now, I’m a one man team with other balls to juggle so there are periods where things are less stable and almost every week im finding new corners and edge cases I haven’t accounted for. Most of the time this means things break for other people while im happy working on my own machines against several different branches and moving parts.
I would love to just send the tools out to people and say thats the stuff take it or leave it. There would be less breakage but also less development and feature experimentation. I also love this community and the transfer of skills and knowledge that has come from my own participation in it and in these kinds of discussiosn and to diminish that kind of ‘call home’ instigated by the tools would be a negative in my view. Anything to make the tools for more embedded in FluCoMa, rather than an additional appendage is the way I’d like to take it. That said, in the last week alone I have made some pretty significant efforts to smooth over any of these issues (which I think you even helped me debug 
).
-
ReaCoMa has a version checker now to ensure compatibility with one’s tools. It will even take you to the download page of the right version if its wrong.
-
I implemented my own error system which hooks into the global lua metatable. This means very detailed errors, instead of ‘shit broke’ meaning a better dialogue between myself and users with issues as well as giving geeks something to poke at if they wanna fix it themselves.
Don’t take this the wrong way, I hear you and these are the reasons I have done things the way they are done.
2 Likes
Muting the off segment with ampgate:
@jamesbradbury, I just tried the implementation of the mute flag and it produced this result:
actually the segments I’m interested in are muted. There is certainly a command to invert the mute state of selected items.
But by observing the result, a different idea popped up: what if you also had an “ignore gate-closure till next gate-opening” parameter
- this would still take advantage of the look-back to a better starting point
- and it would create just one segment from the light beige and the green and then the next from the yellow and the blue (not dividing the resonance)
Looks like the logic messes up for this scenario. Would you be able to send me the exact segment so I can test on it? For now, what you can do is select all the segments and hit Opt + M to invert the muting.
This is actually quite simple to implement - perhaps not in spirit of the slicer but definitely in the spirit of hacking at and extending the functionality. Basically, it would only respect the onsets in this scenario.
1 Like
This is now implemented but only on my development branch. Next time I put something out there it will be official.
Feel free to test from here though: