|
|
|
01-27-2021, 10:26 AM
|
#1
|
Human being with feelings
Join Date: Jun 2012
Location: Spain
Posts: 7,239
|
bug? reaper.GetTrackStateChunk() much slower if plugin is online
THE PROBLEM:
Getting the chunk in some tracks with certain plugins is very slow, If you set the plugin to offline then it works fast as expected.
I think the problem could be that REAPER asks the plugin to update the chunk or something before getting it. Because if the plugin is offline, it cannot ask it anything.
THE SOLUTION
Ideally it could be an additional parameter to the reaper.GetTrackStateChunk function to get the chunk as if the plugin was offline, without updating the chunk.
Another option is to have a function to get the chunk without the plugins encoded data part which is not needed.
You could think, then put the plugin offline, et the chunk , and then set it online again.. But that wouldn't work either as it takes the same amount of time to set the plugin offline too.
STEPS TO REPRODUCE:
Insert a Kontakt plugin with a big library loaded. Something that causes a big chunk of data in the RPP chunk of the track.
It can be other plugins too.. UVI, ENGINE...
Then duplicate the track and set the plugin to offline. The RPP chunk is the same data. but in the case of the online plugin it is much slower to get it.
Code:
local a = reaper.time_precise()
local ret, track_chunk = reaper.GetTrackStateChunk(reaper.GetSelectedTrack(0,0), "", false)
reaper.ShowConsoleMsg("got chunk in ".. reaper.time_precise() - a)
|
|
|
01-28-2021, 01:36 PM
|
#2
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
Thanks for digging deep here, HeDa. I have been confronted with the same issue.
However, I had no idea this is caused by GetTrackChunk.
Based on your findings I have done some tests and can confirm the behavior with different sample players, as shown below:
UVI Player:
online: 0.96 secs
offline: 0.0060 secs
Kontakt:
online: 0.63 secs
offline: 0.011 secs
Play:
online: 0.55 secs
offline: 0.0016 secs
Last edited by _Stevie_; 01-28-2021 at 02:01 PM.
|
|
|
02-02-2021, 02:16 PM
|
#3
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
This is an issue with the plug-ins themselves, their state-saving code is slow. I've seen different reasons for this, including:
- very large state that includes samples
- copy protection uses RSA encryption to encrypt the state
- complex internal state and no willingness by developer to optimize
Shrug?
|
|
|
02-02-2021, 02:42 PM
|
#4
|
Human being with feelings
Join Date: Apr 2014
Posts: 4,171
|
Quote:
Originally Posted by Justin
This is an issue with the plug-ins themselves, their state-saving code is slow. I've seen different reasons for this, including:
- very large state that includes samples
- copy protection uses RSA encryption to encrypt the state
- complex internal state and no willingness by developer to optimize
Shrug?
|
What about an option to supply the chunk without any of the plugin binary data? So we can get at the readable parameters, change them as/if required - and write back into the chunk without Reaper writing anything back to the actual plugin?
|
|
|
02-02-2021, 03:16 PM
|
#5
|
Human being with feelings
Join Date: Jun 2012
Location: Spain
Posts: 7,239
|
Quote:
Originally Posted by Justin
This is an issue with the plug-ins themselves, their state-saving code is slow. I've seen different reasons for this, including:
- very large state that includes samples
- copy protection uses RSA encryption to encrypt the state
- complex internal state and no willingness by developer to optimize
Shrug?
|
Thank you Justin
I was suspecting that because REAPER can read the entire chunk of data very fast if the plugin is offline.
Would it be possible to read it as an option as fast when it is online by not asking the plugin to update the data?
Many times in scripts we don't interact with the vst data chunk part, but we still need to get the track state.
I would love some solution to this because doing a script that needs to read many tracks states takes minutes to process and I don't need the vst data at all...
Quote:
Originally Posted by lb0
What about an option to supply the chunk without any of the plugin binary data? So we can get at the readable parameters, change them as/if required - and write back into the chunk without Reaper writing anything back to the actual plugin?
|
Thank you lb0!
Yes! that would be even better I think. To completely have the state without all the plugin data so we don't have to skip so many lines of encoded data that we don't need to touch. Then the setstate part would also have to ignore the plugin data too as you say. Otherwise it would delete the plugin I guess That would be awesome.. thanks!
Last edited by heda; 02-02-2021 at 03:32 PM.
|
|
|
02-03-2021, 04:45 PM
|
#6
|
Human being with feelings
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
|
Quote:
Originally Posted by heda
Thank you Justin
I was suspecting that because REAPER can read the entire chunk of data very fast if the plugin is offline.
Would it be possible to read it as an option as fast when it is online by not asking the plugin to update the data?
Many times in scripts we don't interact with the vst data chunk part, but we still need to get the track state.
I would love some solution to this because doing a script that needs to read many tracks states takes minutes to process and I don't need the vst data at all...
Thank you lb0!
Yes! that would be even better I think. To completely have the state without all the plugin data so we don't have to skip so many lines of encoded data that we don't need to touch. Then the setstate part would also have to ignore the plugin data too as you say. Otherwise it would delete the plugin I guess That would be awesome.. thanks!
|
As a scripter and someone who uses tons of instances of Kontakt, this feature request would be a HUGE deal. Save times could potentially be a small fraction of what they are now.
Big +1
Cheers,
Andrew K
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 • Catalina • Mac Mini 2020 6 core i7 • 64GB RAM • OS: Catalina • 4K monitor • RME RayDAT card with Sync Card and extended Light Pipe.
|
|
|
02-04-2021, 08:29 AM
|
#7
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
I totally agree with every that has been written.
@Justin, do you see any way to make this possible?
This would really be fantastic!
|
|
|
02-04-2021, 12:21 PM
|
#8
|
Human being with feelings
Join Date: May 2017
Location: Leipzig
Posts: 6,621
|
+1 for lb0's suggestion.
In most cases, the fx-data itself is useless to most of us, unless someone wants to reverse engineer stuff or save Statechunks as Templates.
|
|
|
02-05-2021, 08:10 AM
|
#9
|
Human being with feelings
Join Date: Jun 2012
Location: Spain
Posts: 7,239
|
thank you @_Stevie_ @Meo-Ada I owuldn't even try to reverse engineer it. .I just don't want to touch that data...
I want for example to look at the track state and search for "<FREEZE" and then the "<VST".. to find how many vsts are frozen in the track for example.
Another solution could be using a "offline cached" system for the vst data and let the cache regenerate/reencrypt etc when the user opens the plugin and changes some parameters or when API function sets some parameters. That would also help to improve project saving times.
maybe this thread now could be more a feature request than a bug... or maybe it can be a performance bug.
|
|
|
02-08-2021, 09:14 AM
|
#10
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
Hey Justin, what are your thoughts on these suggestions?
Could this be a cure for the shrugging?
|
|
|
02-19-2021, 09:18 AM
|
#11
|
Human being with feelings
Join Date: Mar 2007
Location: Germany
Posts: 1,539
|
I just ran into a related issue. I received a DrivenByMoss bug report this week that my extension would clear the Undo state of the Maschine plugin. I could track that down to calling GetTrackStateChunk, which I use to retrieve the lock state of the track.
I guess this is a side effect of what is described above (it doesn't matter if "isundoOptional" is set to false or true). So, I would also welcome such an option. Or even better if C_LOCK would also be available for the track and not only for the media item.
If someone knows a worksaround I would love to hear it, since I am currently stuck with this!
|
|
|
02-22-2021, 05:18 PM
|
#12
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
Sorry, not of any help. Still hope that the devs will take care of this in future devs builds.
|
|
|
04-10-2023, 02:24 PM
|
#13
|
Human being with feelings
Join Date: Dec 2012
Posts: 13,333
|
Did anything change regarding this issue?
|
|
|
04-12-2023, 02:26 PM
|
#14
|
Human being with feelings
Join Date: Jun 2012
Location: Spain
Posts: 7,239
|
Quote:
Originally Posted by vitalker
Did anything change regarding this issue?
|
Sadly, I'm not aware of it. It seems there was no interest to do something from REAPER's side, and it was declared a problem of the plugins writing too much data or taking to much time to encrypt the data before saving it. I still believe that caching/Flagging this data as needed to be regenerated, could be beneficial.
|
|
|
04-12-2023, 02:38 PM
|
#15
|
Human being with feelings
Join Date: Dec 2012
Posts: 13,333
|
Quote:
Originally Posted by heda
Sadly, I'm not aware of it. It seems there was no interest to do something from REAPER's side, and it was declared a problem of the plugins writing too much data or taking to much time to encrypt the data before saving it. I still believe that caching/Flagging this data as needed to be regenerated, could be beneficial.
|
Agreed. Not sure why Reaper needs to update FX states, it's not intuitive at all and probably slowing down whole function.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 12:32 PM.
|