Functionality that has been asked for quite a few times.
You can batch convert all stereo samples in one instrument to a new one. This includes the functionalities as available in the sample editor (Convert the left or right channel or mixdown both channels) except for the freq.rate and bitdepth!
I had it almost ready for quite a while and then suddenly i had to cope with keyzones to add to the copy options.
Still the instrument envelopes are not available in LUA so instead of waiiting for these to become available i simply abuse the instrument:copy routine and then convert the samples.
The copying of individual sample properties and note on and off layers are still in there and active for learning purposes.
Samples that are mono are skipped in the conversion process, if an instrument only contains mono samples, it won’t be processed at all.
As always, bug reports always welcome.
Also tips to make this routine work faster. I now had to compromise between processing and allow the GUI progress meter to update.
If this is about very large samples, i don’t have much of a choice.
V1.0 on the tools site:http://www.renoise.com/tools/batch-convert-stereo-to-mono
V0.7 also supports sliced instruments
v0.5:Primary testcase, worked for multizoned samples, but not for the slicer.
Draths, i forgot the sliced instruments.
i’m trying to think the best way out here. Meanwhile abuse the slices to instrument script before mono conversion.
Updated the 0.7 to process slices (first post updated).
The progress meter now has two functions, in case of sliced samples, it orientates on the amount of frames processed, in other cases it orientates on the amount of samples processed.
The final version will have a double session guard. (You can’t run two instances without one or the other causing errors)
Could someone do some analysis on the amplification levels of the target samples when doing R or L channel convert? I have the idea that the frames are boosted up while i’m not processing them double.
Something fishy here is going on here.
Hey vV, this tool seems to slow down scrolling through the instrument list on tracks with relatively many instruments.
I was experiencing noticeable slowdown and when disabling this tool everything run super smooth again, maybe something can be optimized, it can be a pretty handy tool, shame to have it disabled!
edit:
mmm, maybe something else is going on, it is sluggish again while the cpu in Renoise is around 2%!
Well, it might be the notifiers in Renoise who are being polled over and over again.
I’ve added removal of the notifiers to completely terminate the script, in the termination function, perhaps that is causing the lag (there were two observables that were not removed from the notifiers when aborting the conversion process). You should be able to download the update through the script updater.
There might perhaps also be a lot of other scripts that might not close down their notifiers when scripts are being terminated. The notifiers keep running but i think cannot be removed anylonger.
thanks for the update, not sure if it was your tool that was the culprit as I experienced slowdown after I had disabled your tool. Wish there was an easy way to determine which tool is responsible, am I right that it doesn’t necessarily have to be a tool working in or with the instrument list that can still affect scrolling the list?
The trick with observable notifiers is that each script can generate its own observables for several areas and whenever something changes in that area, Renoise notifies every script that has a notifier set for that area.
If you are running multiple scripts simultaneously that want to be notified about changes in for instance the instrument list, then Renoise fires up the respective routine that is configured to be started as soon as changes happen.
For the script-writer it is important to take care that the notifiers are being removed after the script has done its execution and these notifiers are no longer necessary.
If not then i suspect these notifiers remain up and won’t be removed. They have to remain up as some scripts are made to run in the background and constantly need monitoring on certain areas.
But in case it is not necessary, it only consumes CPU time, how much i don’t know, i think the amount of cpu congestion rising depends on the amount of changes that are applied on the specific monitored area within the same amount of time.
I’m not sure in my case it supposed to be so heavy, i just took out the one possibility on my side. I can’t judge for the rest.
while the cpu in Renoise is around 2%!