Lua Slice Markers Bug

It seems that if you add a slice marker to the end of a long sample (can be done in renoise or API) then load a shorter sample over it via the API, you can no longer delete the slice marker as it goes out of range.

If you do the load the new sample in renoise, things seem to work ok.

I was trying to delete old markers. They were still present under the …sample[1]. slicer_markers table but an error is fired if the position is longer than the newly loaded sample:

Test Code:

  1. Load a long sample into renoise and add slice markers near the end

  2. Run code and you get a O.S. dialog to find your new shorter sample (preferably a lot shorter)

local song = renoise.song()
local inst= song.selected_instrument_index

local test_sample = song.instruments[inst].samples[1]
--get path from OS
local sample_path = renoise.app():prompt_for_filename_to_read({"*"}, "load")

--load sample
test_sample.sample_buffer:load_from(sample_path )

--reverse loop to delete all slice markers  
for i = #test_sample.slice_markers, 1,-1 do
  --print(test_sample.slice_markers[i])
  test_sample:delete_slice_marker(test_sample.slice_markers[i])
end

--ERROR when old sample has markers beyond the length of the new one

As a side effect you can get some mangled ghost data in the sampler in the slices for the old long sample:

I’ve also noticed a few crashes of renoise when developing and using the latest version of my Toggle Reference Track tool. I added a `Scrub Slider` that uses slice markers to change the start position of sample play. I can’t recreate the conditions exactly, but thought I`d mention it here in case related to the slice markers:

Tool version 1.39 here:

https://forum.renoise.com/t/new-tool-toggle-reference-track/39281

Just to add maybe something Ledge, with your ‘Scrub Slider ™’ to move a slice marker… I thought this…

Load Renoise and then open up your toggle reference tool. Load a sample via your tool and go to the sample editor. You should see your loaded sample and your 1 created slice marker. Your ‘scrub slider ™’ moves the marker. All good. Now, create from the sample editor a second slice marker ahead of your first slice marker. Using your ‘scrub slider ™’ on your tool, move the first marker into that second slice marker. Kinda pushes the second slice marker forward (or looks that way.) Make sure you push the second slice marker forward (is important.) Finally, close your tool and close Renoise (answer no to unsaved changes.) Have a look at the Renoise log file, and see if there is a exception thrown near the end of the log file. On my machine there is, so I conclude you probably aren’t seeing things :slight_smile:

Secondly (this is just to try to clarify btw), from your initial post you posted a snippet of code. Now from that snippet (if I’m reading that code okay), you are loading in a new sample, then trying to delete any slice markers from the previous sample yes? Whereas in your tool you are deleting the slice markers, then loading in the new sample? So hence why your tool seems to be okay (and Renoise internally because it probably deletes the slices, then loads the new sample), but the above snippet fails. Deallocated the old sample buffer, reallocate a new sample buffer, but now trying to access slice markers (that are probably out of range) from the old sample.

Yes I accounted for the bug by deleting all the markers first in my tool. The reason I posted to the tool in this thread is due to a suspicion that there is something extra going wrong with the slice markers causing the some crashes here and there.

It seems you have definitely found something, so thanks for sharing the details. I`ll see if I can re-create and maybe the renoise team can take a look aswell.

Just to add maybe something Ledge, with your ‘Scrub Slider ™’ to move a slice marker… I thought this…

Load Renoise and then open up your toggle reference tool. Load a sample via your tool and go to the sample editor. You should see your loaded sample and your 1 created slice marker. Your ‘scrub slider ™’ moves the marker. All good. Now, create from the sample editor a second slice marker ahead of your first slice marker. Using your ‘scrub slider ™’ on your tool, move the first marker into that second slice marker. Kinda pushes the second slice marker forward (or looks that way.) Make sure you push the second slice marker forward (is important.) Finally, close your tool and close Renoise (answer no to unsaved changes.) Have a look at the Renoise log file, and see if there is a exception thrown near the end of the log file. On my machine there is, so I conclude you probably aren’t seeing things :slight_smile:

Secondly (this is just to try to clarify btw), from your initial post you posted a snippet of code. Now from that snippet (if I’m reading that code okay), you are loading in a new sample, then trying to delete any slice markers from the previous sample yes? Whereas in your tool you are deleting the slice markers, then loading in the new sample? So hence why your tool seems to be okay (and Renoise internally because it probably deletes the slices, then loads the new sample), but the above snippet fails. Deallocated the old sample buffer, reallocate a new sample buffer, but now trying to access slice markers (that are probably out of range) from the old sample.

Yes I accounted for the bug by deleting all the markers first in my tool. The reason I posted to the tool in this thread is due to a suspicion that there is something extra going wrong with the slice markers causing the some crashes here and there.

It seems you have definitely found something, so thanks for sharing the details. I`ll see if I can re-create and maybe the renoise team can take a look aswell.

Yep, You’re definitely onto something there 4Tey, the second slice marker didn`t like being pushed around! :

CrashLog: Handling Exception! Code : C0000005
CrashLog: 0000000140507E90: l9_ippsSin_64f_A50 +3297A0
CrashLog: 000000014045E4E5: l9_ippsSin_64f_A50 +27FDF5
CrashLog: 000000014045CC94: l9_ippsSin_64f_A50 +27E5A4
CrashLog: 0000000140973759: l9_ippsSin_64f_A50 +795069
CrashLog: 000000014050A2AF: l9_ippsSin_64f_A50 +32BBBF
CrashLog: 00000001404ECF7A: l9_ippsSin_64f_A50 +30E88A
CrashLog: 000000014056572F: l9_ippsSin_64f_A50 +38703F
CrashLog: 00000001405641B9: l9_ippsSin_64f_A50 +385AC9
CrashLog: 00000001405A0C18: l9_ippsSin_64f_A50 +3C2528
CrashLog: 000000014055EF06: l9_ippsSin_64f_A50 +380816
CrashLog: 0000000140563FD6: l9_ippsSin_64f_A50 +3858E6
CrashLog: 0000000140269253: l9_ippsSin_64f_A50 +8AB63
CrashLog: 0000000140268DDD: l9_ippsSin_64f_A50 +8A6ED
CrashLog: 00000001402692C6: l9_ippsSin_64f_A50 +8ABD6
CrashLog: 0000000140BB888F: l9_ippsSin_64f_A50 +9DA19F
CrashLog: 00000000779A59CD: BaseThreadInitThunk +0000D

Application: Caught an unhandled fatal exception (Thread: GUI)!
Application: Saving a backup...

I do not know if this will help or complicate the detection of the bug.I had a similar problem (bug) described here:

https://forum.renoise.com/t/bug-cloning-groups-and-collapse-expand-and-others/48254

Maybe the cause is not the same, but the error poster says the same thing: “A fatal error or crash occurred (unhandled exception in thread: GUI)”

BLA BLA BLA
...
...
Application: Caught an unhandled fatal exception (Thread: GUI)!
Application: Saving a backup...

Maybe they are related. The bug that I suffered, I have not been able to reproduce it again. It must be an extraordinary, strange case.This bug was related to the addition or deletion of clues through a tool. I understand that a tool should never close Renoise. If there is an error, an error window appears and closes the tool, not Renoise, unless the code is malicious, to fuck the CPU, and we just do the opposite.

I do not know if this will help or complicate the detection of the bug.I had a similar problem (bug) described here:

https://forum.renoise.com/t/bug-cloning-groups-and-collapse-expand-and-others/48254

Maybe the cause is not the same, but the error poster says the same thing: “A fatal error or crash occurred (unhandled exception in thread: GUI)”

BLA BLA BLA
...
...
Application: Caught an unhandled fatal exception (Thread: GUI)!
Application: Saving a backup...

Maybe they are related. The bug that I suffered, I have not been able to reproduce it again. It must be an extraordinary, strange case.This bug was related to the addition or deletion of clues through a tool. I understand that a tool should never close Renoise. If there is an error, an error window appears and closes the tool, not Renoise, unless the code is malicious, to fuck the CPU, and we just do the opposite.

It`s definitely worth noting. I think those errors are pretty standard when the GUI thread gets bungled somehow, and I have possibly had something similar with groups; though I tend to run a lot of VSTs so hard to tell sometimes what did what to what…

I may be doing a small script with the groups soon, so I`ll post up in that thread if I find anything.