No, that’s definitely not a good idea. if you need a sample buffer, create one in Renoise by creating a tem sample/instrument, then throw it away afterwards. Using lua tables this way wastes a lot of memory, and will also be slow.
On a second thought: The script maybe simply takes ages to do its job? Its not crashing, but its simply “frozen” for a while?
Please carefully use the term “crash” to avoid sudden heart attacks on my side.
but it doesn’t do anything of the whacky stuff that can happen when you get sloppy with C and arrays/pointers, right?
what’s the best way to do that?
removes bright red disclaimer with caps
Of course. When I’ve done a mistake, then this can crash the C++ code that is running behind all this. But this is as usual my problem, and not yours. Feel better now?
I don’t know what you’re saying, but I like the sound of it…
yeah, that’s good to know. “just like PHP” 
I utterly love how LUA/Renoise immediately tells you where what went wrong, by the way, I just wish that could be more “syntax” highlighted: error message, file names and line numbers → maybe they could be bold?
Actually… I’m disappointed that I haven’t found a horrible bug in the scripting engine 
any ideas how to make it suck a bit less in regards to smooth transitions with the parts of the sample outside of the selection? it’s a bit wonky with big window sizes(check it out with the draw tool)… hmmm. oh well, it works best with small window size and multiple passes anyway, so maybe I’ll just leave that as is.
edit: I think I have fixed this in a way that is not perfect, but good enough, so cheers 
(Ab)Using the loop markers should be possible, though. At least I read in a thread about It-Alien’s Sampleslicer that he’s planning to use the loop markers to visualize the slices.
I agree that doing this fully automatically would be hard and prone to errors (and it would be no better than a gate) so giving the user the final word about where the silence should be inserted is the best solution, I think.
thanks, that’s a nice idea, but still… that would feel ugly 
and what about samples that have a loop already set?
selections are much easier to handle, I mean mouse wise… and this is what they’re for, so I’d rather hold out on that one.
actually, I think manually selecting the parts I wanna mute might even be faster than tweaking the variables until they are somewhat reliably detected, and then still having to tweak them indidivudally…?
by the way, my personal “trick” for this is to vertically zoom in a lot, until only the breathing noises aren’t clipped - then they’re very easy to spot (for a human, not so sure about algorithms), sometimes I don’t even have to listen to what I’m doing.
it’s mostly the (mute it, select the start, fade in, select the end, fade out) part I want to reduce to a single click…
but hey, it’s open source after all, so if there’s a real demand it will surely will creep its way in there somewhere 
You could save the old loop positions and restore on closing the dialog
I agree completely.
I agree again. Now that I think of it, my suggestion was not such a great idea after all 
Time will tell, time will tell.
well yes and no - if the API allows us to set the selection some day, I might toy around with this… but until then, I don’t desire it enough to make it work with loop markers 
maybe that could even be another tool, something that sets the selection… “next silent part”, “next peak”, “expand selection to zero crossings on both channels” etc. etc., more than I can think of right now, so that really should be it’s own floating window, so all other tools can enjoy it too
Done for the next Renoise update.
hooray! scriptable renoise is the best thing since sliced bread, and it’s kinda hard to fathom just exactly how much work went into this…
speaking of hard work, I updated Vocal Ops
realized it breaks undo! so use with care, and if anybody has a suggestion, I’d be grateful, because this and the wasted memory kinda are the only things that keep me from submitting it to tools.renoise.
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?
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.