I'll test it when I'm back from work.PepeLopez wrote:64bit beta version of Reaper an Win8 is a very critical combinationpaterpeter wrote:My system: Windows 8 x64, Reaper x64 4.33pre4, Studio One Professional 2.5, i7 2600k, 16GB RAM, Native Instruments Traktor Audio 2)
Reaper crashes frequently when I edit the step sequencers. In Studio One, the notes are played very unevenly, ie. timing is off. I'll see what I can do about this, because Kirnu has the same issues. Maybe it's a S1 thing.
Is it different when using latest stable version of Reaper?
There are two typical reasons why you'd need to run the DAW as admin to make a plugin work:As workaround:
Please try to install Cream in admin mode and afterwards run (64bit) daw in admin mode. Some users reported that it works then. For some not. It's difficult to figure out why it behaves differently on similar setups :/
1. Access rights. For example, the plugin wants to read from or write to places on the harddisk where a normal user doesn't have the required rights. Typical example: presets or settings are stored inside the plugin folder and the user keeps the plugins inside c:\Program Files (for Windows users).
2. User specific resources. Some plugins write important data to locations that are only accessible by the user account (usually an admin) that's installing the plugin. On Windows, typical examples are %APPDATA% or the HKCU (HKEY_CURRENT_USER) registry hive. When you try to run the plugin as a different user than the one who installed it, the plugin can't find essential resources and crashed/behaves strange/etc. Two examples: Melda Production stores essential shared resources and factory presets in %APPDATA%. IK Multimedia stores essential shared information in HKCU and factory presets in user specific folders.
To be honest, I find it strange that so many developers still don't get this right. All current operating systems are multi-user environments that clearly differentiate between normal users and elevated users. It's actually easy to make software work for all users in those environments. Still many developers don't do it right.
Cream suffers from the first issue. It stores (by default) its presets and settings in subfolders (data and presets) inside the folder where the plugin is installed. This is a bad idea and should be changed ASAP.
For example, many Windows users install their plugins under c:\Program Files. There are better places in the file system to store presets and settings. Ideally, those locations are freely configurable by the user. By default, the settings and license file should probably go to AppData\Roaming.
For the presets, a configurable directory is always the best choice IMO. If that's not possible, at least the user presets should NOT be stored inside the plugin folder (an therefore, potentially inside c:\Program Files). Better places for user presets are the user's Documents or AppData\Roaming folders (depends on how you see it). The factory presets might stay inside the current location, as long as only read access is required. As far as I can see, there's currently no dedicated program folder for Cream, but factory presets and the manual could go there. Other manufacturers store presets in c:\ProgramData (Cakewalk) or in c:\Program Files\Common Files (Native Instruments), but some users don't like it when files are scattered all over the harddisk.
Personally, I like the u-he approach: add a shortcut inside the plugin folder that points to a data folder containing all required program data and presets (factory and user presets) and make the data folder location configurable during setup.
I've become quite good at "fixing" the carelessness of those developers who don't know where to store plugin data properly. It's time consuming and annoying, but at least so far I can run any plugin without admin rights in a restricted account which is different from my admin account.
I found that Cream stores the installation path in HKLM, but I haven't tried to fiddle with that. For now, I've simply granted the user write access to the folder where Cream is installed.
Sure, I'll see what I can do.If you have the possibility to show a bug in a video, please do so. Sometimes screenshots are working too. The faster a problem is reproducable, the fast it'll be fixed for sure!
Arto takes care about every bug!