search

rock-hopper / shuriken

Shuriken Beat Slicer
GNU General Public License v2.0
107 stars 6 forks source link

Crash to desktop when changing BPM #2

Closed ghost closed 8 years ago

ghost commented 9 years ago

Hello,

Shuriken crashes to desktop if I manually enter a new BPM and the following conditions are met:

I can provide you the project file if needed.

rock-hopper commented 9 years ago

I see what's going on. The Return key is a keyboard shortcut for the slice button. If you manually enter a BPM and hit Return when there's no slice points then Shuriken crashes. Thanks for flagging this up.

ghost commented 9 years ago

Unfortunately, this happens as soon as I press the 1 of 156. The return key isn't involved.

rock-hopper commented 9 years ago

I couldn't reproduce the bug here, but I've made some changes which may have resolved the issue. Previously, when the audio back-end was set to ALSA, the number of outputs defaulted to 32. The Rubber Band library would then try to stretch all 32 channels simultaneously in real-time. Perhaps that was too much for your processor and Shuriken crashed. I've now set the default number of outputs to 2. Please let me know if this fix resolves the issue.

ghost commented 9 years ago

I'm using Jack. The problem is still there with the new build. I don't think I'm short in terms of processing power with an I5 2500k and 8Go RAM. ^_^' My guess is that as soon as something is entered in the bpm box, the stretching + pitch correction is processed. It's working most of the time but for a bpm of 1, something is wrong and crash the app. So if my original bpm is 137.82 and I want to enter a bpm of 156, I have to be careful and either:

If needed, you'll find the (only) project I'm working on and in which I encounter this bug here: http://www.mediafire.com/download/yov5n7pfy0d8nza/AB_project.shuriken

PS: and easy "fix" would be to have and "apply" button like in offline processing. This would also make the global timestretch panel UI more consistent :p

rock-hopper commented 9 years ago

Haven't forgotten about this, just need some more free time!

rock-hopper commented 9 years ago

Hi Barbouze, can you upload that project again? The link is dead. I did manage to reproduce this bug once but am having trouble reproducing it a second time as I didn't take a note of the settings!

ghost commented 9 years ago

Hi!

Well, sorry for deleting the file. The good news is that before uploading it again, I tried to reproduce the bug in the latest version and no crash happened. I then remembered that I changed the sampled beat from stereo to mono. It happens only when working with stereo files and a short window. You'll find another project to demonstrate this here: https://www.mediafire.com/?va18g8l51xaaqb5 but it has happened with every stereo file I tried so far. Mono ones were fine with changing BPM on the fly.

rock-hopper commented 8 years ago

OK, this is actually a known bug in the Rubber Band library https://bitbucket.org/breakfastquay/rubberband/issues/4/sigfpe-zero-division-with-high-time-ratios

I've got around the problem by restricting BPM values to between 10 BPM and 300 BPM. Hopefully that's still enough stretch to play with! If you enter a value less than 10 it just gets ignored until you enter a second digit.

ghost commented 8 years ago

Good to know! :)