I am trying to decide one or the other...
I'm on one of the most powerful iMac's in my department and it should run all software very smoothly even for a power user... but Muse drags so slowly I sit around watching the beach ball spin half the time.
Muse v.10 Build 948, CL 767416
AIR Runtime: 188.8.131.520
iMac 3.1 GHz Intel Core i5
8GB 1333 MHz DDR3
I only have 8GB of RAM in this machine so it's obvious a RAM upgrade would help anything - but I am unsatisfied that Muse won't work efficiently / fluidly out of the box.
Working on a Muse file with about 50 pages... any movement or opening of a page lags and shows the spinning beach ball for far too long. please advise?
I want to trust this software will have substantial updates to its resource usage.
I'm having the same issue, on PC. Any updates coming to fix this?
I'm haveing the same problem - incredibly slow - I have 16 gig of ram and 8 procs - I'm only using 8 pages.
If this doesn't get fixed this will be a useless program
Can you give me some more details like.
1. Do you have any other program running in the background ?
2. Do you face the issue with the all the sites that you make or only this one ?
3. What content are you using on this file ?
4. Is this the first time you are facing this issue ?
I have photoshop open as I am creating content for the site.
This is the only site I have tried in Muze.
The site is only 6 pages all built on the same master. There is a background image on th emaster page.
This is the first time I have tried Muze.
I get large pauses even when typing in content - I will be several words ahead of the display. There are times when the program will take 5-6 seconds to respond to a command
How long is the text frame you're typing in? (The current undo implementation for text will cause typing to be slow in text frames that contain a large amount of text.)
Roughly how many images are on each page?
Here is a shot of one of the pages with text and images:
hardly a huge amount of text. I run Premier and AE on the same machine and they are both quite nimble
I can only speak for my copy of Muse, but I'm having no similar type of issue. In fact I'm flabargasted by how much I can load onto a page. I have some pages with over 30 images piled one on top of another, none smaller than 300x250, as well as using several widgets per page, over 30 videos a page, and they all load pretty darned fast into a browser - faster than DW. My system is a modest 4 core, with 6G RAM, and I have Production Premium CS4 also on this machine, although I only use PS in conjungtion with Muse. My websites has very little text however.
James - lucky you, lol.
However I believe after much time has passed we've pinned it down to our network being the major issue. We've had to resort to pulling our Muse files onto our desktops to work from them otherwise it is literally not even worth it to try.
With that, Adobe could pay some attention to how a network hosted .muse file behaves and how it interacts with the network, since Muse will crash constantly when there are minor network hiccups (even when putting iMac to sleep mode, Muse will crash because it lost the network connection to the file).
EVEN with pulling the .muse file to desktop, there is small annoying glitches and pauses/delays that still blows my mind. This I point my finger at AIR, its just flakey as software.
You're right Seanmichaelboone.
I've just upgraded to the 2.0 and mama mia...crashes are quite often compared to the 0.X and 1.0 version of MUSE. And what a slowneeeeessss! that 2.0
Windows or Mac? What OS version?
When do the slow downs occur? Are you working directly on files stored on a server?
Please send the MuseLog.txt file from your Documents folder to us at firstname.lastname@example.org along with a link to this thread. Thanks.
Hello Zak, thanks so much for your answer.
i currently run muse 2.0 on a macpro 2x2.66 with 8Go ram. As I never uploaded my files on a server (because I'm still stuck with bugs) I don't have the MuseLog.txt. I gues that files you're asking is created on a server after UL the site right?
I had the same MacPro when I ran the v1.0 of muse and waoww!! it was pretty much faster than the latest release.
My OS is still the same when I used the 1.0 and now the 2.8 OSX 10.7.4
If I can help...let me know
Please take another look for the MuseLog.txt file. It should be in the Documents folder in your username folder on your Mac Pro. Anytime an error dialog comes up in Muse the error and some additional information is written to the MuseLog.txt.
What operations are slower in 2.0?
the MuseLog.txt was just sent to support email.
PS/ Muse 2.0 isn't incredibliy slow ALL the time. But it sometimes it looks like buffers are full.
For example few minutes gao I deceided to put a border frame of 1px on every sides of a rectangle. Once I clicked on the Upper setting of the stroke tu enter 1, muse never stop slowing jumping by itself all the number till 16px!!
Hmm... I haven't seen a message come through on the muse-support e-mail address. Could you send the MuseLog.txt again and just send it directly to me at email@example.com? Thanks.
How large is your .muse file? If you work with multiple different .muse files, are you seeing these slow downs with one particular .muse file or with any .muse file?
Now that I think of it, as I am working in Muse 2.0, you are right. Muse is a bit slow but not to the point where I can't work. I don't think it's your Ram as I have 12 gig.
morningcolours, that's for sending the MuseLog.txt again. It shows 6 errors/crashes yesterday. Four of the errors point strongly toward there being some sort of corruption in the file that was being worked on. Assuming you have one .muse file that you mostly work on, could you send it to me at the firstname.lastname@example.org address? If it's larger than 20Mb you can use a service like Adobe SendNow, SendThisFile, WeTransfer, etc. to send it. Please include a link to this thread with the e-mail so others on the muse-support e-mail list know the background. Thanks.
The other two crashes point to there being a bug in the on-object UI for one of the widgets. Do you recall what you were working with when the "Mismatched begin/endUserAction calls?" errors occurred? Thanks.
Zak the file is beeing transfert from dl.free.fr service. Let me know if it's ok.
For the last bug you're asking about, if it's the last one recorded in the .txt I might be when I just click with the T cursor in the "PREVIOUS" text area of my slideshow, I wanted to change the font size.
Hello I got the same problem here. Muse is very slow. And it even looks like it's slowing down my whole system though. I'm kinda new to using this program, but this is not very comfortable. Isthere a recent update expected for this issue, else i will make my website in an other program.
I don't think it's my system: Mac pro 8core, 5870 video, 16 gigs memory.
I've tried it without running any other progam.
The muse file in activity monitor is appr. 450 MB big, so that is not that big.
What actions in Muse are slow? Launching? Exporting? Publishing? Showing a certain palette?
Are you working with a particular .muse file?
Any additional information you could share would be helpful.
- whenever i try to resize fonts, or resizeing a window, just drawing a window
- switching between pages
- previewing the site
- it's just lagging a lot
Maybe it has something tot do with yhe pictures i imported?
the .muse file i'm working with is my own website.muse file.
How large is the .muse file? Where is it stored (boot drive, external drive, server, thumbdrive, etc.)?
The .muse file is 22 MB.
I changed the storage position from my server to my HD to see if that's making a difference, also i'm experimenting with the size of my pictures imported.
i'll keep you posted.
i put everything on my HD today instead of on my server and it seems the lagging is gone.
Also I made all the files smaller and more web-sized in Bridge, os i'm ok for now.
Muse reads objects into memory as they're used and currently does so (mostly) one object at a time. Since each file access is many many times slower when the .muse file is on a server versus your hard disk, I believe that explains the performance you were seeing.
We're working on revising how we load objects into memory to improve performance in general for a future Muse release. That change should make working directly from a server more viable, but working from a server will always be slower than working with the file stored on a local hard drive.
As for image size, you shouldn't need to reduce the files outside of Muse, though you certainly can. There's a relatively little known feature in Muse in the Assets panel called "Optimize asset size". If you right click on an image in the Assets panel this option will show up if Muse is currently storing more image data for that image than is necessary in the .muse file. Specifically, if the image is currently being used in your Muse layout at a smaller size than what was imported, then this option will be available. If you select this option, Muse will discard the excess image data. (It will store an image that's just the exact size that's being used.)
If you select the first item in the Assets panel and shift click to select the last (to select all), right click and choose the "Optimize asset size" option (which may take a while to run), then Save As to a new file (since Save As compacts file size and so the original file is available to compare to) you'll likely find the new file to be much smaller than the original.
The gotcha with the "Optimize asset size" option is once it's been done, all the images stored in the .muse file have been resized to their current size in your layout. If you then resize an image larger within Muse, it will become pixelated because it's now larger than the stored image. When this occurs Muse will warn of "upsampled" images and a little icon with a plus will appear next to any upsampled images in the Assets panel. If you right click on an image in the Assets panel that's upsampled the context menu will include an option to "Import larger size". Note that for this option to be enabled the asset has to both be upsampled and the link to the original file needs to be intact (so Muse can re-import the image data).