I now can’t delete version 0.01 (since it’s no longer “my file” I guess), could a mod do that for me?
Just had a crash with your latest update:
"Script ‘C:\Users\plugexpert\AppData\Roaming\Renoise\V2.6.0\Scripts\Tools\de.johann-lau.VocalOps.xrnx\main.lua’ failed in one of its notifiers:
std::logic_error: ‘invalid frame_index index ‘0’. valid values are [1-54533].’
stack traceback:
[C]: in function ‘sample_data’
.\vocal_ops.lua:94: in function ‘process_smooth’
.\vocal_ops.lua:184: in function <.\vocal_ops.lua:183>"
Processed a sample just after I installed the script and overwritten the older version. I processed the default Renoise installed amen break with a window size of 8 and 3 passes.
Okay thanks I will look into that 
-- write access to samples in a sample data buffer. new samples values
-- must be within [-1, 1] but will be clipped automatically
renoise.song().instruments[].samples[].sample_buffer.set_sample_data(
channel_index, frame_index, sample_value)
-- to be called once after the sample data was manipulated via 'set_sample_data'
-- this will create undo/redo data if necessary, and also update the sample view
-- caches for the sample. this is not invoked automatically to avoid performance
-- overhead when changing the sample data sample by sample, so don't forget to
-- call this after any data changes, or your changes may not be visible in the
-- GUI and can not be un/redone!
renoise.song().instruments[].samples[].sample_buffer.finalize_sample_data_changes()
ahah fixed! well I think, even though I couldn’t reproduce it myself I’m 99% sure I found and removed the cause, leftovers from experimentation actually ^^
file has been updated, thanks again!
but I’m actually calling that? after all the loops (number of passes, number of channels, and of course iterating through the sample itself) that gets called:
for i = 1, int_passes do
for int_chan = 1, buffer.number_of_channels do
for int_frame = buffer.selection_start, buffer.selection_end do
buffer:set_sample_data(int_chan,int_frame, new_buffer[int_frame] )
end
end
end
end
buffer:finalize_sample_data_changes()
(nevermind that this utterly kills stereo samples, that’s for 0.03 ahem)
While we are at this. Don’t use lua table to store temporary sample data. This is slow like hell and wastes memory like hell.
Create a new sample in Renoise instead, which you then use a drop bin. Then delete it afterwards.
We should maybe make this easier by allowing to create free sample_buffers. sample buffers which are not part of a sample in Renoise…
You already told me that, and I acknowledged it. I also asked what is the best way to do that, but I guess I can just look at how the Custom Wave Generator does it…
It’s in the todo list, and I mentioned it as a thing that keeps me from submitting this. But it works for now and I’ve got enough other stuff to figure out, and just because it’s slow or wastes memory (I have an i7 and 4GB, but even I notice how horrible it is haha…), it should still undo, unless I missed something else, right?
- ten billion!
well I either can’t figure it out or that’s not what it does…
local instrument = renoise.song().selected_instrument
local temp_sample = instrument:insert_sample_at(#instrument.samples + 1)
local temp_buffer = temp_sample.sample_buffer
-- or whatever else you need here
local new_rate = 96000
local new_bit_depth = 24
local new_num_channels = 2
local new_num_frames = new_rate / 2
if( not temp_buffer:create_sample_data(
new_rate, new_bit_depth, new_num_channels, new_num_frames)) then
renoise.app():show_error("Couldn't create sample!")
return
end
-- make use of temp_buffer
-- delete the temp buffer when done
instrument:delete_sample_at(#instrument.samples)
thanks!! I actually started to piece it together from CWG and API myself but this is much better.
okay, did that (attachment updated), although instead of
local temp_sample = instrument:insert_sample_at(#instrument.samples + 1)
instrument:delete_sample_at(#instrument.samples)
I’m using
local temp_sample = instrument:insert_sample_at(renoise.song().selected_sample_index + 1)
instrument:delete_sample_at(renoise.song().selected_sample_index + 1
it’s still terribly slow, so that seems to be a property of scripting and my code.
undo is still weird: when I load a song and do my smoothing, I can undo one action, “insert sample”, but that doesn’t change the sample back, it just recreates the temporary sample. which means, I can’t undo the smoothing.
if I load a song, do something else first (e.g. normalize), then smoothing, and press undo once, nothing (visible) happens. pressing undo again gives me the sample before normalization. if I then press redo, I get the normalized sample, and using redo again gives me then the smoothed sample.
in other words: I can’t reach this undo step when going backwards in undo history, then it just gets skipped/ignored, but going forwards works as expected?!
even using finalize_sample_data on the temp_buffer didn’t change anything, I’m kind of at a loss. it’s no biggie, since if it’s the first action you do after loading a song, you can’t undo but you can reload the song, but still, I’d really like to fix this…
Finalize after each action perhaps? Might slow down the routine even more, but gives you an idea when undo stuff is written away.
Or perhaps add a little timer between actions to allow Renoise to save the undo data before continuing the next action.
I would do that, but wouldn’t this fill the undo buffer with unneccessary steps? I just want it to behave like a normal, one-step action, and if it created a billion undo steps that would flush the undo buffer and be even worse in a way. I’ll play around with sticking more finalizes in there this evening though, can’t hurt.
However, Renoise does have the undo data, as is shown when pressing undo twice, then redo. It just ignores it when going backwards in undo history, it behaves as expected when going forward.
hi johann
now it also works on my system,thanks alot this is a nice tool,some interesting results can be made
cheers
yeah, while I think the more extreme settings (I’ll allow higher values, but give a warning/estimate if the process will take very long) are not really useful for the original purpose (I’ll just use it on high frequency artifacts in low-frequency syllables)… if you resample stuff afterwards, or pitch it up, who knows what can happen ^^
Updated again, but when the undo issue is solved I’ll split this into two separate tools. That makes much more sense and you can after all just keep both windows opened.