Technical problems

Hi. this is Vojtech from MeldaProduction. Recently I discovered a few minor problems with Reaper so: 1) Reaper seems to let the plugin store the state very often, basically after any change. I guess for some Undo thingy. Unfortunately this is hardly acceptable, because our plugins must use the global lock to protect some more advanced data such as envelopes. which results in sometimes a few seconds long lag (usually in GUI). It cannot be done a different way, because another editing thread may be just changing it, so the storing could crash. How can this be disabled? At least I need something to tell users. 2) I have 2 reports of a case, when somebody updated our plugins and the GUI disappeared. The only solution was to reinstall them or RUN ANOTHER HOST :). In fact Reaper is the only host doing this. So my question is, does Reaper do some kind of caching or something like that, which could cause it and how to prevent it? Unfortunately I was unable to simulate it yet, so our choices are rather limited.

Hope, a dev will come along here soon to answer your questions. In the meantime an idea to check for 1) would be if Preferences->Plugins->VST: "Avoid restoring VST state on undo/redo if possible" brings some quick relief.

I suppose you contact Cockos support via e-mail.

Hello, Maybe similar problem affects also "shortcircuit v1.1.2", where (in SC1 settings YES to "Store all samples in project directory" option) "shortcircuitdata" subfolder is created (that's OK), but samples aren't copied to that folder only when SAVE project is performed in Reaper, but they are copied immediately when adding samples to keyzones in SC1 and touching any editing parameter, which is BAD, since that way ALL samples that you only try to add to multi setup are copied to destination folder even if you remove them from keyzone right after adding. It has to do with new v3 UNDO functionality somehow. 1) This phenomenon DOESN'T occur in v2.206, v2.53, v2.58 when UNDO is enabled 2) This phenomenon DOESN'T occur in v2.206, v2.53, v2.58 when UNDO is disabled (=UNDO memory set to 0MB) 3) This phenomenon DOES occur in v3.x (v3.13, v3.68) when UNDO is enabled 4) This phenomenon DOESN'T occur in v3.x (v3.13, v3.68) when UNDO is disabled (=UNDO memory set to 0MB) Common settings for all tests, accross all tested versions: Maximum undo memory use = 30 megabytes Create undo points for item/track selection = YES Create undo points for time selection = YES -and- Save full VST plug-in state if supported (recommended) = YES Save as bank (larger config data, required by some plug-ins) = YES Avoid restoring VST state on undo/redo if possible = NO (not checked) Additional setting (Save full VST ..., Save as bank ..., Avoid restoring VST state ..., Create undo points for item/track/time selection) don't affect the problem in any way. Would be fine if it gets fixed. akademie Note: Due to known bug in SC1, to test properly, you must first save project (even empty) then close project/reload project to internaly set actual path for storing samples (SC1 doesn't check for project path on save, but only on project load :-( (= keeps previous project path if project was loaded from folder A and then resaved to new folder B path (similarly if new project hasn't defined path ...)

Sorry for the delay in responding, we've been discussing possible ways to handle this on our side. On the state saving issue: Of course the best solution would be for the plugin to support reporting its state without needing to lock up the GUI. There are a few strategies that could be used to accomplish this, such as caching the last reported state and only recalculating it if a parameter has changed, or only recalculating costly data if the relevant parameters have changed. There are many plugins that have massive state, but do not need to lock up the GUI in order to report that state. We may be able to add a per-plugin flag to disable undo, but there are potential side effects we need to think about. On the GUI issue: Is this an x64 specific problem? I recall reports of some other plugin GUI vanishing when the plugin is instantiated on x64 when more than 2GB of RAM is already in use. This could be a simple matter of the plugin using something like SetWindowLong instead of SetWindowLongPtr.

Great, thanks! Please drop us a line at support at cockos if you would like an NFR license of REAPER, and of course please let us know if you come across anything that you think REAPER is doing wrong.

OK, well the generic way to improve this in your plug-in is to reduce your locking granularity. For example, you could have a shared/exclusive lock for "envelope data" or whatnot, and have this locked exclusively during writes, and shared during reads -- and only exclusively locked for the duration of the writes. This way, you could read very quickly, except when writing, but when writing that would only be locked for a short time (and if writing is rare, then it's even less of an issue). I know this takes work on your end, but presumably it could have other payoffs...

Well, I know that of course, it's not that simple though. Well, we'll see how much of a problem it is (actually I posted this, because I notified, no customer or something, and it was in debug mode :), but still... ).