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…
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?)
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.
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 themode “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 not found.
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 not found.
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…
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 reallywork on Sierra++ anymore.
Optimized that now.