OSX: GUI slows down on renoise.app():show_status() calls

Help, Support & Bugs
1

Please read last post. Status bar causes slow down on OS X.~~Hi

I added a Presonus Faderport, and thanks to Airmann’s Renoise driver, it works out of the box.

Only the values / sliders are updated very slowly while moving the slider of the faderport, in the mixer and in the effect bar. The status bar is updated with 60Hz, the sliders only two times a second… That’s a bit disgusting.

Can you fix it, or is there an option to increase update time?

BTW. also the pattern scrolling starts to stutter, immediately if I move a slider on the Faderport. Is this a LUA issue? Mabe it needs its own thread or something?

BTW2. I lately seen this stuttering also while inter-device modulations like signal follower -> meta mixer -> fx.

The same extreme slow down of the renoise gui appears, if I move any control in some vst GUI pop ups.

EDIT: [s]maybe this is related with this new “GUI update feature” introduced in Mavericks osx 10.9 by apple? 10.9 drastically slows down GUI updates of hidden areas, maybe it thinks that renoise GUI is hidden? I think it’s called “app nap”.~~ I disabled app nap in the app properties - no change.

Taktik should have a look on it…

EDIT:

If I activate write or touch mode (e.g. while writing pre-fader volume automation), the stuttering completely disappears.

2

See also here:https://forum.renoise.com/t/new-tool-2-7-8-presonus-faderport-implementation/29542

3

Could be an “OSX”-related gfx problem (?). I never experienced that under Windows. I’m pretty sure that it is no FaderPort driver problem, since the faders are completely updated by Renoise. The driver just sets new values for track volume/pan or devices.

4

@ Jurek, what are your settings at, edit/preferences/gui ?

I bet changing stuff here fixes your problem.

5

Hi, already checked that, frame rate etc. no change.

Ah btw I have the same effect, if I move any slider in a some VST gui pop ups. Immediately if I move a knob there, the renoise gui behind it will slow down extremely, too.

6

Hi

I added a Presonus Faderport, and thanks to Airmann’s Renoise driver, it works out of the box.

Only the values / sliders are updated very slowly while moving the slider of the faderport, in the mixer and in the effect bar. The status bar is updated with 60Hz, the sliders only two times a second… That’s a bit disgusting.

Can you fix it, or is there an option to increase update time?

BTW. also the pattern scrolling starts to stutter, immediately if I move a slider on the Faderport. Is this a LUA issue? Mabe it needs its own thread or something?

BTW2. I lately seen this stuttering also while inter-device modulations like signal follower → meta mixer → fx.

The same extreme slow down of the renoise gui appears, if I move any control in some vst GUI pop ups.

EDIT: maybe this is related with this new “GUI update feature” introduced in Mavericks osx 10.9 by apple? 10.9 drastically slows down GUI updates of hidden areas, maybe it thinks that renoise GUI is hidden? I think it’s called “app nap”. I disabled app nap in the app properties - no change.

Taktik should have a look on it…

Its not only your issue related problem, i have the same issues. I have 2 korg nanokontrols acting as a mixer console alike, so when im moving lotsa faders and knobs at once the GUI lags dramatically in both x86 & x64 builds.

Im on osx 10.9.5, RNS 3.0.1, no crapware installed, the system is always pristine clean (btw my setup is dual-screen and i have some gui issues all the time with renoise, like loss of focus and rns window disappearing from time to time) .

7

I have 2 korg nanokontrols acting as a mixer console

Would that be the 1st or 2nd version of the NanoKONTROL? Second version has caused a lot of problems, it outputs an excessive amount of MIDI messages even when the value doesn’t change (usually, MIDI devices only output values when they actually change). High-resolution devices such as the Faderport often do this, but that’s due to the high resolution so it makes more sense…

Reg. nanoKONTROL - I did some investigation along with satobox, and he found that not only Renoise but a lot of other programs were suffering from this “MIDI-spam”. Interfacing the controller with Renoise tools can potentially makes things even worse, due to the overhead of lua processing. I learned this device the hard way, as the nanoKontrol is supported by Duplex, Ultimately, I implemented a midi-spam prevention which seems to make it somewhat usable.

But - I’m not sure if this is the same problem as with the FaderPort. What makes me think so is the difference between platforms. OK on Windows, not OK on OSX…

@Jurek: perhaps could test this thing in Windows too - that would give an indication of whether it’s the machine which is underpowered, or its a Renoise related issue?

8

Would that be the 1st or 2nd version of the NanoKONTROL? Second version has caused a lot of problems, it outputs an excessive amount of MIDI messages even when the value doesn’t change (usually, MIDI devices only output values when they actually change). High-resolution devices such as the Faderport often do this, but that’s due to the high resolution so it makes more sense…

Reg. nanoKONTROL - I did some investigation along with satobox, and he found that not only Renoise but a lot of other programs were suffering from this “MIDI-spam”. Interfacing the controller with Renoise tools can potentially makes things even worse, due to the overhead of lua processing. I learned this device the hard way, as the nanoKontrol is supported by Duplex, Ultimately, I implemented a midi-spam prevention which seems to make it somewhat usable.

But - I’m not sure if this is the same problem as with the FaderPort. What makes me think so is the difference between platforms. OK on Windows, not OK on OSX…

@Jurek: perhaps could test this thing in Windows too - that would give an indication of whether it’s the machine which is underpowered, or its a Renoise related issue?

2nd version.

and yeah, some other things arent all ok on osx, but thats another topic.

9

But - I’m not sure if this is the same problem as with the FaderPort. What makes me think so is the difference between platforms. OK on Windows, not OK on OSX…

@Jurek: perhaps could test this thing in Windows too - that would give an indication of whether it’s the machine which is underpowered, or its a Renoise related issue?

Hey, no my machine has lots of power, no gui problems anywhere, it’s a core i7 and good ati gfx. Never reaching any limit. The problem also appears with an empty song, I just have to move a slider of the faderport. It’s a problem in the Renoise gui.

And as Ransom says, I also experienced these kind of slow downs with other controllers, when there is lot of input. And with some vst guis, too, while knob moving.

10

And as Ransom says, I also experienced these kind of slow downs with other controllers, when there is lot of input. And with some vst guis, too, while knob moving.

Ah, OK. I missed out on that part.

11

Hm, maybe this has something to do with undo function/buffer in Renoise OSX?

The faderport driver kind of “floods” the undo history on change, not because of the driver but because of some limitation in the renoise lua api. This flooding is different to normal midi input (which works almost fine here). Is it possible that undo buffer adding kind of blocks the gui on OSX? Just a blind guess :slight_smile:

EDIT:

If I activate write or touch mode (e.g. while writing pre-fader volume automation), the stuttering completely disappears.

12

Could the devs post some statement regarding this problem? I can do some video of the problem if this helps.

Problem desc. in one sentence: If I move the faderport slider, the GUI of Renoise will extremely slow down, as long as Write or Touch mode is not activated.

I would like to know if I can fix this problem inside the faderport driver tool, or is this a Renoise OSX’s problem?

13

Hey Jurek,

since you mentioned midi flooding I can give you some hints.

  1. In order to find out what’s going on the midi side, you can enable midi dumping for FaderPort driver. Enable dump_midi in config.xml. Have a look at Debug.lua. There you can define regexp filters for tracing function calls. The function midi_callback() is also traceable, but you have to hold the FaderPort’s shift key while tracing it. Last but not least _AUTO_RELOAD_DEBUG = true in main.lua.

  2. Check if FaderPort is sending lots of values despite fader isn’t moved/touched. This is an effect that can occur if the motor is off. It can also pollute Renoise’s undo/redo queue. Make sure that the additional power supply is connected to FaderPort.

  3. Disable FaderPorts undo workaround. I don’t recommend to use it, since it’s not stable by design.

  4. Check if FaderPort itself is the problem: e.g. my FaderPort pan encoder tends to send lots (!) of midi events from time to time (like an explosion/burst). Especially when only turned a little bit. Therefore, I added the feature anti_suck_min_turns to config.xml. If the pan encoder is the problem try to increase the value from 3 to 5 or so. If the fader is the problem: mmh ;-). You could also try to update your FaderPort firmware (just to be sure)

  5. Have a look at your system wide midi configuration and routing. Maybe use another midi monitor to find out what’s going on system wide.

14

Thanks for the detailed infos. No, it’s not a system problem, I am sure about this (and I am not the only one). Other controllers/pure midi controllers doesn’t cause stutter. I just remember that I observed the same behavior when using lot of meta devices (it was something like 2 lfos->xy-pad->2 hydras->going to various fx and send channels)… It’s something fishy with lua on Renoise OSX I guess. Or some problem in the faderport, only for OSX, so again some Renoise lua problem. Maybe something update frequency related or something. Have to become a bit familiar with this lua stuff first. I will try to investigate what is the difference between write/touch and read mode, since it stutters only in read mode.

I have the firmware 1.3.8 installed on faderport.

15

UPDATE:

I think I isolated the problem in Renoise OSX lua api:

Therenoise.app():show_status() function seems to slow down the GUI in OSX a lot! If I out-comment the call “renoise.app():show_status(message)” in FaderPort.lua on line 1468 here in function “FaderPort:status_bar_display_fader_value()”, there will be no more slow down here! (post fader mode)

Devs, can you bugfix this problem? Lot(or even less) of messaging to statusbar via LUA seems to stutter the OSX GUI. Please fix! Thanks!

EDIT:

Added a testcase / test script for OSX users:

Attachment 5573 not found.

Usage: Install tool, then bind a keyboard shortcut to “Global->Application->OSX GUI Stuttermode”. Now hold down the shortcut. I will see an extreme slowdown of the Renoise GUI. Tested on two OSX systems, OSX 10.9.4, Core i7, ATI and OSX 10.6.8, Core i7, nVidia. It will print a random status message ten times a shortcut press.

16

I know this is quite impatient, but could you fix this problem soon, maybe with a hot Fix (renoise 3.01 + recent bug fixes)? Since it prevents me from using the fader port properly, editing is not possible with 1hz visual feedback.

Hihi, and cool would be, if the priority of a changing automation point was bigger than the already recorded automation, so in touch mode I could see the change I do in realtime at the sliders, instead the value of the recorded automation (since on next loop it will be the new value)…

Or a feedback would be cool, too. :slight_smile:

17

Will look into this. Thanks for the detailed reports. For now you can simply disable the renoise.app():show_status() call in “FaderPort.lua”. They are not mandatory, aren’t they?

Such messages are causing immediate gfx updates, so flooding the UI with them indeed could slow down things.
Only thing I can and will do is filtering them out to avoid this so there is no real “fix” I could apply here, but only a workaround.

18

Thanks for clarifying this and taking the time looking into it. No, its not mandatory, but of course helpful to see the actual value. maybe the update of gfx could be limited to the area where the change will happen or something? Or some little conceptional improvement of refreshes? btw. why is this difference between osx and windows? For status bar, would it be enough to refresh it with max 60 Hz and then showing only the very last message?

EDIT: Found a quick workaround: Disabling beam sync via Quartz Debug will stop the stutter… Not sure if it works 100%, but seems to be something with beam sync related. This is of course no real working workaround, but for now…

19

Hey, but if limiting the number of outputs, then working with some kind of “setTimeout ( print(), ms)” function to ensure that the recent value is displayed last?

Wanted to workaround this way in lua, but couldn’t find any settimeout function in lua. In Javascript I would write

var to = null;
cleartimeout(to);
to = setTimeout ( function() { 
   print_status(text)
}, 100 );

So on every new call, the last threaded timeout would be cleared. Is that possible in Renoise LUA?

EDIT:

Found temporary solution:

showstatus = function () 
    if (renoise.tool():has_timer(showstatus)) then
      renoise.tool():remove_timer(showstatus)
    end
    renoise.app():show_status(message)
  end
  renoise.tool():add_timer(showstatus, 30)
20

Hey taktik,

don’t know anything about building an own multi platform gui from ground up :slight_smile: (big respect to that), but thought about this: Wouldn’t it be much more logical and lots more resource-saving, if there was a gui thread that refreshes the gui at every sync tick (like 60Hz) and processes a refresh-queue (with sorting and/or removing doubles), if the gui becomes dirty, and even better, only areas that changed/became dirty? It doesn’t seem to make much sense of the gui refreshes with speeds over screen refresh rate, in the case/bug above maybe with something like 1 millions Hz or so…? Also it seems to be dependent if the quartz graphics waits for a sync or not. If not (a.k.a. disabling beam sync in quartz debug), it seems to be ok (but of course resource destructive) to even refresh with such high rates. Because of quartz, maybe the approach on OSX should be completely different to the approach on Windows?