Jump to content


Photo

Better draw automation in app-idle for performance reasons?


  • Please log in to reply
9 replies to this topic

#1 Guest_ffx_*

Guest_ffx_*

    Composes without Wires burns Directly from Brain to DVD that is already in Store Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3521 posts
  • Gender:Not Telling

Posted 31 January 2018 - 10:00

Hi taktik, danoise, joule,

I currently draw automation within the vst-parameter-changed-notifier. Do you think it would help regarding performance, if I would draw the automation later in app idle by executing a command queue?

Currently that automation script drastically slows down if there are more than 5 automated parameters at once on one device. Also here and there can be slowdowns.

App idle is not that fitting event in other environments, e.g. a browsers javascript, but then at least ensures the GUI is idling? The correct event would be "on-next-frame", right, but does not exists.

So would it improve performance? But then the user would see the drawing delayed, too, which would be a worse real-time interaction experience....

#2 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1863 posts
  • Gender:Not Telling

Posted 31 January 2018 - 10:31

Hey.. I'm a noob. I believe danoise can answer this best, as I haven't dealt much with automation. I don't know the exact requirements and which kind of buffering-prewrite technique that are required and would fit..

But my first thought would be to make a "stack" that writes the actual automation - a table with pending writes that is "chewed" thru on an app_idle premise. Oh, but then things are getting complicated - pinpointing the exact timecodes of what you want to write. Sounds practically "impossible".

 

(PS. My impression is that there might be some slight gain in using app_idle under busy circumstances - even if you need to perform the exact same task.)

 

(PS2. Looking at the code of ffx.tools.GUIAutomationRecorder V1.10 - it seems really inefficiently structured. The most heavy and frequently ran line would be the add_point_at line, right? In this "scope" I wouldn't want any unnecessary locals or if statements. You have an insanely large code block there.. Cannot be optimized by any means?)


Edited by joule, 31 January 2018 - 11:07.


#3 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7009 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 31 January 2018 - 12:27

Yep, took a quick look and would agree with joule that it the code most likely could be simplified quite a bit. 

 

First of all, you seem to be iterating through, and doing a lot of logic, for each of the attached parameters. 

But, you hardly need that, do you? I mean, the focus should be on dealing with when and if a parameter has changed? So I would try to make a restructuring with that in mind. 

 

Usually, the rule for optimization says "don't do it / do it later". But with this kind of real-time critical tool I would definitely try to make the core logic as focused as possible - because, automation recording doesn't suddenly bring 10.000 points to the table, you more-or-less have a steady stream of values that you need to deal with.

 

Trying to do things asap will also make it clear if the tool is actually able to perform it's job in realtime. The incoming "value-has-changed" notifications are fired in near-realtime, and it's important to respond to them if you want to determine the fractional time - so I wouldn't use any timers (idle or otherwise) at all. Only when and if the tool is not able to deal with the messages as they arrive should "delayed writing" be something to consider. 

PS: This is perhaps a slightly different subject, but while maintaining Duplex, I've found that some MIDI controllers fire many times more messages than others - including repeating the same message/value multiple times, due to a discrepancy between the resolution of the physical knobs and the values it was transmitting. I had to implement throttling to control the volume of incoming messages. 


Tracking with Stuff. API wishlist | Soundcloud


#4 Guest_ffx_*

Guest_ffx_*

    Composes without Wires burns Directly from Brain to DVD that is already in Store Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3521 posts
  • Gender:Not Telling

Posted 31 January 2018 - 12:53

I think you do not fully understand the logic yet:

 

- First all parameters have to watched. If the mode "theOnlyAndOnly" is NOT activated, all parameters still have to be watched, because in this mode, you can record any parameter at once.

 

- If the mode "theOnlyAndOnly" IS activated, after determination of the wanted parameter (moving > delta or no automation yet), all other notifiers will be exited, except for that one parameter. So in this mode, the effort is quite little (just like in v1.1).

 

 

But I agree, the calculations on the active-preset-data only need to be done once a parameter, not every round  for any parameter :) Optimized that now.

 

I now also moved some of the variables to outside, but I doubt that this would bring any noticeable difference.

 

Please see this version:

[attachment=7944:ffx.tools.GUIAutomationRecorder.xrnx]

 

Also now implemented a on-idle-queue. Obviously - like in the Faderport tool - drawing automation with low LPB 4 will lead into weird automation spikes. So I assume those spikes do not reflect the used values. I know that problem is less visible on a Windows machine. This problem really made me sell the Faderport:

 

[attachment=7945:Bildschirmfoto 2018-01-31 um 11.35.41.PNG]

 

You can test on-idle-queue drawing yourself. Then uncomment the lines 560, 561 and 595.  With direct drawing (not on idle), the result has no spikes. Also do not forget the disable automation_follow in song options first. Something fishy is going on with automation drawing in idle... 


Edited by ffx, 31 January 2018 - 12:56.


#5 Guest_ffx_*

Guest_ffx_*

    Composes without Wires burns Directly from Brain to DVD that is already in Store Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3521 posts
  • Gender:Not Telling

Posted 31 January 2018 - 13:11

Ok, it seems that this active-preset-data brute-forcing was the bottle neck. Seem to be able to automate 20 parameters without any performance drop.

 

Yet there still is this bug in undo/redo:

 

Original automation:

 [attachment=7946:Bildschirmfoto 2018-01-31 um 13.09.16.PNG]

 

One time undo:

[attachment=7947:Bildschirmfoto 2018-01-31 um 13.09.26.PNG]

 

One time redo:

[attachment=7946:Bildschirmfoto 2018-01-31 um 13.09.16.PNG]

 

Two times undo (on second undo, nothing changes):

[attachment=7947:Bildschirmfoto 2018-01-31 um 13.09.26.PNG]

 

One time redo -> crash.



#6 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7009 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 31 January 2018 - 13:21

Grabbed the tool in it's current crash-prone version. Thanks. 

 

Seem to be able to automate 20 parameters without any performance drop.

 

Cool. Now I wonder, how did you test that - with twenty hands?  :D


Tracking with Stuff. API wishlist | Soundcloud


#7 Guest_ffx_*

Guest_ffx_*

    Composes without Wires burns Directly from Brain to DVD that is already in Store Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3521 posts
  • Gender:Not Telling

Posted 31 January 2018 - 15:45

No, I mean per automation device, I setup one by one. Before the performance dropped heavily with 6+ automations. I now updated the tool on tool page.

 

Btw. a question regarding versions on the tool page:

 

Is V1.11 > V1.1 ?

 

Also the tool updater in Renoise seems to list again the same updates over and over, even after update.

 

 

EDIT:

 

I use a dynamical context menu adding for fx dsps. This seems to slowdown the GUI on macOS ( referring here:             #15             ). Sometimes I can see 1/4 second GUI freeze when I click a dsp... I don't see how I could optimize that part...

 

This trick             #27              also does not really work on Sierra++ anymore.


Edited by ffx, 31 January 2018 - 16:16.


#8 Guest_ffx_*

Guest_ffx_*

    Composes without Wires burns Directly from Brain to DVD that is already in Store Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3521 posts
  • Gender:Not Telling

Posted 31 January 2018 - 16:30

btw thanks for help @ danoise and joule



#9 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7009 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 31 January 2018 - 19:02

 the tool updater in Renoise seems to list again the same updates over and over, even after update.

 

The problem you're experiencing is caused by the tool being listed as "autoupgraded" in the manifest. 

Such tools are not considered "proper" releases by the update checker. 


  • Guest_ffx_* likes this

Tracking with Stuff. API wishlist | Soundcloud


#10 Guest_ffx_*

Guest_ffx_*

    Composes without Wires burns Directly from Brain to DVD that is already in Store Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3521 posts
  • Gender:Not Telling

Posted 01 February 2018 - 00:46

The problem you're experiencing is caused by the tool being listed as "autoupgraded" in the manifest. 

Such tools are not considered "proper" releases by the update checker. 

 

 

Ok, I changed that to false in all my "new" tools. So will it then auto update everywhere?