MuTools

muzycian · Post by **muzycian** » Mon Jun 11, 2007 11:23 am

DaveL60 wrote:SR-202 and DS-404 are single .DLLs, no other setup files involved. By re-arranged, I'm referring back to the original post: I decided to create a DRUMS folder under my PLUGINS folder and moved SR-202 and some others there. A simple re-scan after created some confusion, with duplication of the plugs that have moved, so I deleted all of LUNA's settings files and re-scanned and that seemed to go better, but the bottom line is that LUNA has been unstable ever since I moved plugin files around.

If you want to reset your plugin settings, ONLY delete the VstPlugins.xml file!

Cfr http://www.mutools.com/luna/docs/tt-qa.html

So reading this, i suggest you re-install LUNA.

That is: Unzip the original zip file to a new folder, and run LUNA

I'll happily post the technical details here the next time LUNA crashes. EDIT: I'd love to do that, but I can't copy/paste out of the window that reports it, and I never see the temporary file that Windows says will be sent to MS (which never happens either).

True

Sorry, didn't know it's that difficult/not possible to get the technical details to the developer without passing Big Brother.

Anyway, please first do the fresh install, and see how things go then.

muzycian · Post by **muzycian** » Mon Jun 11, 2007 2:45 pm

The next LUNA (not focussing the name now) will have an extra crash protection!

If luna or any plugin crashes, luna will, via a special exit routine, try to save the current session as "Crashed.MuSession" in the luna application folder. (edit: or maybe better: "SOS.MuSession")

By this, chance is high (not 100%, but definitely higher chance than now) that you can recover the session

pljones · Post by **pljones** » Mon Jun 11, 2007 5:58 pm

Stick this in a file called "whatever.reg", then run it (right-click, Merge):

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Auto"="1"
"Debugger"="drwtsn32 -p %ld -e %ld -g"
"UserDebuggerHotKey"=dword:00000000

It turns on "drwrsn32" for capturing application failures, which might help. Simply use regedit to delete the AeDebug key to revert to default behaviour.

DaveL60 · Post by **DaveL60** » Mon Jun 11, 2007 6:12 pm

@pl: Thanks, I'll add that in if I continue to have problems.

@Jo: I'd agree that a fresh install is the right course of action at this point. In the oh-BTW category: I've also seen one instance of the doubled tempo entry box that was mentioned in the new thread on project tempo / sample rate issues.

DaveL

pljones · Post by **pljones** » Mon Jun 11, 2007 8:55 pm

The tempo thing doesn't appear to be a bug. The first one is an updown control. You have to click that again to get a text entry box. By "not a bug", I mean it's working, not it's right...

muzycian · Post by **muzycian** » Mon Jun 11, 2007 10:17 pm

ok, please describe how it would be perfect.

pljones · Post by **pljones** » Tue Jun 12, 2007 8:07 am

Lose one stage: allow the updown control without clicking (i.e. "in place") and click to get the text entry box.

muzycian · Post by **muzycian** » Tue Jun 12, 2007 9:11 am

Yes, agreed.

I've done it like this (see next version) but thing is: whenever the tempo changes the composition is redrawn because the audio files graphics depend on the tempo.

So i only hope that when there are many audiofiles in the composition, and when the cpu weight is high, it's still "usable".

Anyway, the in-place tempo field is definitely more responsive = easier = more fun

So lets evaluate the its overall behaviour in group, when pr9 is out.

MuTools

KVR Audio

Re-arranging plug-ins (possible BR)