32Bit/64Bit/2.7.2 Comparisons


  1. first load 2.7.2
  2. load a bunch of plugs
  3. they load quick
  4. keyjazz is still possible
  5. then quit 2.7.2
  6. load 2.8b3 64bit
  7. try to load in plugins
  8. they load real sluggish
  9. keyjazz is lost (as per the bridge being in full effect)
  10. quit 2.8b3 64bit
  11. repeat the same with 32bit 2.8b3, and notice that one plugin actually gets a buggy gui what with other plugins stealing it’s header.

either way, all versions of 2.8 Beta have acted like total tar compared to 2.7.2, which is truly unfortunate.

I don’t understand what you are trying to say.

Bridged plugins are slower? Bridged plugin will grab the keyboard focus? This is known.

Are there any significant differences between 2.7 and 2.8 32Bit? I didn’t see any in your video.

there’s some allright. loading older songs while a song is playing in 2.8b3 32bit will actually result in 3-4 minutes of unresponsiveness in the “releasing old song” portion, and i have actually had renoise completely crash my machine with it (i.e., you get that gray sign saying “you need to close your machine now”. It makes me wonder what’s next.

yes, loss of keyboard is a known issue - i could’ve let that go without a mention, but it really shouldn’t be forgotten about – especially if there is any kind of a possible solution of retaining keyboard input direct to tracker. buying a midikeyboard isn’t a solution ;)

Still, I don’t understand what issue you want addressed.

  1. In the video, it’s not clear how you opened the plugins.

  2. If there’s an arrow in the header, then the plugin is bridged. In your video, when you opened 2.8 32bit, then the plugins, all your plugins have the little arrow. So whatever you are doing, it’s not opening correctly. I repeat, if there’s a little arrow, then that means bridged.

If you want speed, get rid of those arrows?

With keyboard shortcuts which start a script which loads a VST/AU effect. I literally pressed
FTOEWASZC (fusionfield,toraverb,ohmboyz,transientshaper,W1,syntorus,multibandsend,Pro-Q,ValhallaDSP Room)

what the heck!? thanks for this one!!! i had “Run all plugins in sandboxes (->separate process)” toggled ON. Now that I*ve unticked that box, they all load real quick and i maintain keyboard control. that’s what i was hoping for. thanks.

i guess unticking that box will do it.

i’m not sure if it will solve my “releasing the song during playback” issue tho, and i cannot actually video it because if a song causes 2.8b3 32bit to crash my whole computer, i can’t come back with a video showing it, can i? ;)
well, this certainly helped a great deal.

Wow, I never saw that option.

Makes me wonder if a bunch of other power users turned this on and that’s where a lot of perceived slowness is coming from. Geez, why is that option even there?!

I deleted all my 32bit plugins. I don’t have any, anymore. It’s liberating.

I think I toggled that option on cos I thought it would increase / improve behaviour. It didn’t. This should really be talked of in at least cat-size letters, and told to people. I’m sure I’m not the only village idiot ticking that box. Or, if I am the only one, the rest of you can consider yourselves fortunate!

I have no idea how to get 64bit plugins of all the plugins I use, since some are fairly old. I’d love to move to 64bit, as long as that “releasing song…” doesn’t result in crashing.
but one thing… is it true that 64bit, in non-sandboxed mode, has that same “loss of keyboard”? so in essence, I should probably keep to my non-sandboxes 32bit?
, yep, go back to your 32bit, esa

Wow, I just quitrenoise64bit and it took it approx ~35-45 seconds to release an empty document (no playback was going on). the “releasing song” also shuts up OSX for that portion of time (you can’t move your mouse, the whole OS is unresponsive…) interestingly, i had a 32bit version running and playing a song at the same time, and the playback was flawless.

This does not happen to me.

Shutting down Renoise takes just a few seconds.

I’m on OSX 10.6.8 and am exclusively using the 64bit version.

Anything strange in the logs?

Well, I did find this in the logs:

[details=“Click to view contents”] ```
GUI: Creating the Document GUI…

CrashLog: 0 libSystem.B.dylib 0x9a30405b _sigtramp + 43
CrashLog: 1 ??? 0xffffffff 0x0 + 4294967295
CrashLog: 2 Renoise 0x00ba0317 0x0 + 12190487
CrashLog: 3 Renoise 0x00aa684e 0x0 + 11167822
CrashLog: 4 Renoise 0x00aa685f 0x0 + 11167839
CrashLog: 5 Renoise 0x00aa685f 0x0 + 11167839
CrashLog: 6 Renoise 0x00aa7d54 0x0 + 11173204
CrashLog: 7 Renoise 0x00ab3cfc 0x0 + 11222268
CrashLog: 8 Renoise 0x00b65dab 0x0 + 11951531
CrashLog: 9 Renoise 0x00189976 0x0 + 1612150
CrashLog: 10 Renoise 0x0004b283 0x0 + 307843
CrashLog: 11 Renoise 0x00b3120e 0x0 + 11735566
CrashLog: 12 Renoise 0x00b377bb 0x0 + 11761595
CrashLog: 13 Renoise 0x00b383b3 0x0 + 11764659
CrashLog: 14 Renoise 0x00b38806 0x0 + 11765766
CrashLog: 15 Renoise 0x0004c1a8 0x0 + 311720
CrashLog: 16 Renoise 0x00560684 0x0 + 5637764
CrashLog: 17 Renoise 0x0004f726 0x0 + 325414
CrashLog: 18 Renoise 0x00569042 0x0 + 5673026
CrashLog: 19 Renoise 0x0004debf 0x0 + 319167
CrashLog: 20 Renoise 0x0048d7f0 0x0 + 4773872
CrashLog: 21 Renoise 0x00018a02 0x0 + 100866
CrashLog: 22 Renoise 0x00018929 0x0 + 100649

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

Error Message: A fatal error or crash occurred (unhandled exception in thread: GUI).
Error Message: This either happened because of a bug in Renoise, or because of a bug in one of its loaded components (plugins). Please contact and report this problem, so that it can be fixed.

Error Message: Note: It’s very important that we know exactly what has happened (what you were doing before this message popped up), or the problem cannot be replicated/analyzed. Please include a description of what you were doing and which components were being used…

Application: Terminating…

CoreAudio: Stopping Device ‘Apple Inc.: Built-in Output’…

CoreAudio: Stopping Input Device ‘Apple Inc.: Built-in Microphone’…

CoreAudio: Releasing Device ‘Apple Inc.: Built-in Output’…

CoreAudio: Releasing Input Device ‘Apple Inc.: Built-in Microphone’…

CoreAudio: Device is down

MIDI: Shut down: Closing all acquired MIDI devices…


but this seems related to another bug, having to do with trying to script-wise add multiple tracks to one group - which causes serious crashes, saves crashbackup .xrns's, which when reloaded (and thus the file is lost from the drive when re-loaded) - cause immediate gui crashes. I didn't expect that my incomprehension of how groups + tracks operate and how to move multiple tracks (all named "H") to a group would cause these kinds of issues.

allright, i loaded a big-ish track and quit it. renoise2.8b3 64bit gave 18 seconds of non-responsive mousetime. here's the log.well, no, no log - since there's nothing especially interesting displaying in it (there's no errors etc. it just looks like a clean quit. but somehow releasing VSTfx takes so much longer with 64bit 2.8b3)


I originally posted this in 2.8 beta bugs. it was moved to 2.8 beta ideas suggestions&help.
in light of this post being in the 2.8 beta forums, i do not understand the “the place should be the beta-forum in my honoust opinion”-part of your sentence.

That option is there because it “should” prevent Renoise from crashing if any plugin crashes including the native bit versions (It supposed to be some sort of safe-button and prevent you from loosing work), however, this is currently not the case unfortunately so hopefully during this Beta all these crashes get figured out so that this button does offer this safe option.