New Tool (3.1): Auto Grow Sequence

Renoise Tools
21

I could see if it’s possible to circumvent by wrapping the removal of sequences inside an idle_observable notifier. Is it really a practical problem, though? If the bug only occur during deliberate provocation, I’d prefer to leave it the way it is.

I’m sorry to tell you this…I have been doing tests with another own tool that also adds patterns automatically. By doing various tests, I have noticed that there is also a problem with the native Undo (CTRL + Z). If I hold down (CTRL + Z) and many times Renoise returns an error and closes (A fatal error or chrash occurred …), the same error…

So, I went back to your tool, and the same thing happens. I would not recommend the use of this tool because Renoise does not seem stable. Apparently, Renoise misses out by deleting a pattern at a certain time. I suppose that, when a pattern is added, an index or something is recorded and something is wrong, because when it comes to erase, there comes a moment when something goes wrong, as if it wanted to erase something that does not exist, or it does it too fast or too slow. I don’t know!

That to force with the wheel of the mouse then Renoise crash is already something to take into account. But that Undo width CTRL + Z does it is a very serious matter. This should be thoroughly reviewed by the Renoise Team.

I have done another test. I have put 5ms in the USB keyboard repeat settings, and I press the down key to add patterns automatically with your tool. Here it seems to work correctly!

Everything seems to indicate that using the mouse wheel in the sequence is conflicting, and does not depend on the tool at all (the code), it is something internal to Renoise. Maybe we should report this as a serious BUG. Imagine this issue in a RAS type tool. The truth is that these errors annoy a lot!!!

As I understand it, no tool should be able to hang Renoise. That is the objective!But unfortunately it is not!We do not have the control to avoid these errors and it is frustrating, because there is no support for many months!

Have you tried to make a tool type RAS, without this error is present?This kind of errors make developing a tool an absurdity. You can think and write the code well and then Renoise hangs anyway.

Edit :In case it helps:I think the problem is when the patterns are added, that the index register is not correctly established (I suppose). The problem is not in the process undo CTRL + Z or in the act of deleting, but in that which must be deleted (which has been registered for a long time before).

22

Indeed, but it probably has to do with the deletion rather than creation. Maybe some problem with object destruction internally. Or malfunctioning pointers. Or something related to gc/finalize metatables of the lua objects.

The bug doesn’t have to do with the scroll wheel. It also happens when using the gui scrollbar.

Maybe it will get fixed faster if I upload it to the tools page :wink:

23

Indeed, but it probably has to do with the deletion rather than creation. Maybe some problem with object destruction internally. Or malfunctioning pointers. Or something related to gc/finalize metatables of the lua objects.

The bug doesn’t have to do with the scroll wheel. It also happens when using the gui scrollbar.

Maybe it will get fixed faster if I upload it to the tools page :wink:

^_^Maybe…

I believe that if you replace the notifier in charge of detecting the sequence change by a timer (add_timer ()), the way to register the Undo-Redo queue changes. This will avoid the error.

I have done some tests running away from the notifier (selected_sequence_index_observable: add_notifier ()) and using my own timer (5-10ms) and the tool looks like another. Actually, the delay in milliseconds does not matter. If you use a higher value, 15 or 20ms, it will be easier for you not to register the sequence change, but there will be no error in the tail of Undo-Redo. However, I have noticed that the way to save the Undo-Redo tail is different. Pressing CTRL + Z behaves differently.

To my knowledge, a notifier has a delay of about 10 milliseconds. I usually set the timer (add_timer (func, time)) in 5ms. This does not guarantee 100% reliability, but it is what we have.

The conclusion of all this are 2 things:

  1. If the notifier (renoise.song().selected_sequence_index_observable: add_notifier ())is used, it is very likely that he keeps in the tail of Undo-Redo with inaccuracy, generating serious errors (for handling and saving the Undo-Redo queue).
  2. If the timer ( add_timer(func, time) ) is used,how to save the undo-redo tail changes,even being able to detect that there are no more steps of Undo, when they do exist. But at least, it prevents Renoise from crashing. As far as I know.

Even so, neither of the two things work as I would like. If the timer saved the Undo-Redo queue as the notifier, it would be much better.

I recommend that you experiment with a timer, and you compare what happens with the saved tail of Undo-Redo.If you want to maintain identical behavior, use a 10ms timer.

24

The error doesn’t happen under undo only.

I suggest we leave it at this. OK I’ll try an idle_notifier. Shouldn’t make a difference, but you never know.

Have a try with this one. It seems to work OK here (when undoing, it will temporarily break until changing sequence. I probably won’t fix that due to the required complexity of circumventing this edge case)

8169 joule.no0b.AutoGrowSequence.xrnx

25

Thanks for this awesome tool!

I discovered that it’s indespensable when rewiring Renoise to Studio One (or other hosts?). You won’t have to care about adding lots of patterns in Renoise. Whenever you press play in the master, Renoise will auto-update the sequence list with empty patterns if needed. Pretty much as if Renoise has an infinite timeline, when needed.

I was a bit surprised that the rewire transport and API notifiers catches this flawlessly.

26

Oops?

1 Like