function sample()
local w=renoise.app().window
local t=renoise.song().transport
if w.sample_record_dialog_is_visible==false then
w.sample_record_dialog_is_visible=true
t:start_stop_sample_recording()
else
t:start_stop_sample_recording()
--renoise.app().window.sample_record_dialog_is_visible=false
end
end
renoise.tool():add_keybinding {
name = "Global:Impulse:Sample Now ON/OFF",
invoke = function() sample()
end
}
and ran into a problem. Okay, if the procedure is: 1) open sample recorder 2) start sampling 3) end sampling 4) close sample recorder – the result is that the closing of the sample recorder ditches the just-being-saved sample. If however I just leave the sample recorder window on, then it just works and keeps working, but I was hoping to do two versions, one for sampling and quitting, and one for sampling and continuing.
Is this something that can be done, a kind of a delay between “stop sampling” and “hide sample recorder dialog window”
So, according to searches, there’s a os.clock() . This continually changes. Can a “if” sentence be created which checks out if os_clock has increased by 3, before doing the functions specified in the if-sentence?
Hmm, I’m not really sure if i’m supposed to put that function inside another function… and I ttried delay(3) and invoke delay(3) etc and it just keeps asking me what delay is and what has it got to do with anything
Well, I got it to do something, just need to figure out how to incorporate it onto the “stop recording, delay, remove window from display” workflow.
Exactly that. a delay between ending sampling and closing the sample recorder.
function delay(seconds)
local init = os.time()
while init+seconds > os.time() do
-- nothing
end
end
function sample()
local w=renoise.app().window
local t=renoise.song().transport
-- local init = os.time()
-- os.clock()
if w.sample_record_dialog_is_visible==false then
w.sample_record_dialog_is_visible=true
t:start_stop_sample_recording()
else
delay(1)
t:start_stop_sample_recording()
delay(2)
w.sample_record_dialog_is_visible=false
end
end
It’s really weird. I’ll have to try and do some snooping around with status messages after the delay and leave the visible=false for later.
(edit)
Woah, it seems that the saving delay is completely dependent on how long the sample being saved is… If only there was a way to read sample_saving_progress and only do something after it’s at 100%
(edit)
Okay, if areally long sample is recorded, it is loaded with a long progressbar. Does that mean that the progress bar can be observed from somewhere, and something can be made only after the sample has been observed to load?
Did you try to put renoise.song().instruments[].samples[].sample_buffer.prepare_sample_data_changes() before the first start_stop and renoise.song().instruments[].samples[].sample_buffer.finalize_sample_data_changes() just after the last start_stop?
If that doesn’t do it it’s probably an issue that needs to be addressed by the staff…
The observable for the renoise.song().instruments.samples_observable:set_notifier(my_notifier_function) could perhaps offer some help here in observing the changes done to the sample.
I don’t have time to test this now, but you can set up an observable for the particular samplesslot your are loading a sample into and then apply a print message to see at which point your observable function is being called by the Lua engine. (only when a ahcnage to the sample is being made or also after a sample has been loaded?)
I think the limiting factor, or the real issue is this:
SampleRecordDialog’s Create a new instrument on each take… The sample_now will be toggled at any point in time, in any slot, and it’ll always create a new slot. So how to observe a start_stop_sample_recording() event so that upon stop - a % starts running, how to observe that and only do something at 100% (and preferably a half a second after)
You might perhaps need the renoise.song().instruments.samples..sample_buffer_observable:add_notifier(myfunc) instead.
If i were at home, would test this out which notifier works the best.
As soon as the notifier calls your routine, you could make it wait for xx seconds with the simple while… end loop until your variable you stuffed the first os.clock value in, differs 3 seconds from the current os.clock you are polling, but when the sample_buffer observer calls your routine, all processing might be done and you don’t need to delay anything in that case.
There is an answer somewhere, just can’t give you an insured one right now.
vV,
One problem might be when using “record to new instrument”. It doesn’t create a new instrument until the recording is done, which makes it difficult. Perhaps also add a notifier on number of instrument, if that is an observable.
There is an instrument observable where you can attach a notifier to that watches the instrument slots and fires your function if any activity is done on it (the same notifier also fires up if instruments get deleted and perhaps even moved).