I've just seen this review which highlights some things I have noticed with the latest version plus some things I was not aware of that are problems too.
http://www.vjcentral.com/?mod=softwares ... &id=modul8
yves@garagecube wrote:- Yes Modul8 uses more memory than other VJ applications. The true is that Modul8 tries to use all your memory to speed up movie play back. As it is explained in the documentation, it tries when possible to store short loops entirely uncompressed in memory and when they are too big, compressed in memory. So yes, Modul8 uses more memory than the applications which simply stream movies from disk. But it is for good reasons. Now it is always difficult to do the right decision when your ram is full and to anticipate swapping situations. We are still working on improving memory management, but we still think that it is a good idea to work as much as possible with pre-loaded movies instead of letting 50% of your memory not used.
Now be sure to check that you did not put wrong numbers in the media preferences if you have the feeling that Modul8 uses too much memory. Most of the memory problems are coming from writing huge numbers in the first field which causes Modul8 to load very big loops uncompressed in memory.
yves@garagecube wrote:- Modul8 always respects the original size of your media. You are responsible of scaling down your movies if you have performance problem while some other applications automatically (or manually) resize your media. So it is important to keep in mind that it is up to the user to resize the media when performances are not good enough.
yves@garagecube wrote:- Modul8 user-interface does not use 20% of CPU time. This is completely wrong. Most of the people open the "Activity Monitor" and made bad interpretations of the percentage displayed here. Modul8 is a highly multi-threaded application and have several high speed threads which have been designed to react very fast to user actions, scripts, etc. Modul8 has been designed to use as much as possible your CPU without taking care of parallel processes. These threads change their CPU usage depending of many internal parameters. The only thing it means is that Modul8 never completely sleeps - I won't go into detail here, but there are several limitations in OS X API regarding multi-threading which forced us to do it this way. Now it won't steal 20% of your CPU power simply for user-interface or for not good purpose.
yves@garagecube wrote:- Modul8 today uses CoreVideo for media decoding which is exactly the same decoder used by QuartComposer for example. So media decoding won't be slower than any other CoreVideo based applications.
yves@garagecube wrote:- The main problem of Modul8 V2.5 is how to optimize an highly multi-threaded engine for architectures as different as a G4 machine or a dual-core Intel. We decided to go for multi-threading in the past which was a good decision considering that all the industry is moving to multi-core processors these days. Now we are at a middle of a transition where Mac OS X runs on incredibly different architectures (going from single core G4 with a very slow bus to four core Intel machine with wide buses). It means, that we have to develop many different paths for each of these cases. On the other hand, Modul8 is one of the rare real-time application which is able to use fully two cores or four cores machines right now. It's true that we focused a lot on multi-core system during V2.5 development and we know that there are speed issues on some mono-processors machines - we are working on it.
Conclusion: It is nice to write a review and we are very open to critics. Nevertheless technical critics have to be more consistent and not based on pure feelings (unless it is clearly written from the beginning that we are talking about personal feelings). Saying that there are memory bugs in Modul8 which cause it to use too much memory without explaining in what context was used the application and what were the settings is not very helpful. Also by saying that the media decoder is much slower than QuartzComposer while it uses exactly the same one or that 20% of CPU usage is used for user-interface without knowing how works Modul8 internally, is jumping a bit quickly to conclusions that cannot be really technically justified.
3Din2D wrote:With the review in mind I have run some tests and found out that modul8 is loading uncompressed media with a wide margin despite the memory setting. Why is this so?
3Din2D wrote:I have to say I agree with the reviewer in being able to force a target resolution - that would be very handy.
3Din2D wrote:I ran Activity Monitor and saw (on my G5) a 20% load - 20% is 20% to the system regardless - and that would mean less threading resources available elsewhere, no? I did a test and ran an app that took 100% cpu and indeed it ran at 80% speed.
3Din2D wrote:Some of the review is personal opinion (that's what makes reviews interesting!) but it could only serve to improve the application.
yves@garagecube wrote:So you mean that before the review, everything was working okay ?
yves@garagecube wrote:Seriously, please elaborate a bit. How did you compute this margin ? We don't fill the memory with empty zeroes just for fun. I need to have a concrete example to see if something is wrong here and to fix it.
Something like what was the size of the loop and how did you arrive to the conclusion that this loop uses more memory than it should.
For instance, I just did a test with a movie :
Size -> 512x384
Duration -> 4 secs
Rate -> 25 fps
From the Media tab: 76 MB uncompressed
Do you mean that it should take less than 76 MB ?
Here is how to compute it:
memoryKBytes = (width*height*pixelsize*rate*duration) /1024
76800KB = (512x384x4x25x4) / 1024
This is correct.
Now I open the memory monitor and before loading the loop I have:
VMemory: 427.43
After loading the loop:
VMemory: 503.77
503-427 = 76
which is also correct. Modul8 did not use more memory than it should.
yves@garagecube wrote:Well it could be useful but it solves only half of the problem. Of course it takes less time to apply effects on a low-res frame but the application still have to read and decompress the frames as they were saved. So it makes a lot more sense to resize your movies before you use them if you really want to improve the performances.
yves@garagecube wrote:If by "elsewhere" you mean other applications. Yes. If you mean to Modul8 itself. No.
Your assumption is that 20% CPU usage will be subtracted to future Modul8 CPU requirement. Which is not true because this 20% includes already several things that have to be done when a movie is running. The "no movie" situation is a special case that we are not interested in. Now if you prefer I can put all the threads at sleep as long as no movie is displayed, then you will open the monitor and arrive to the conclusion that Modul8 has no CPU overhead which is as wrong as your first assumption.
yves@garagecube wrote:I agree. We take a lot of time reading the bug reports and the propositions of our users. And we always try to find solution to the problems as fast as we can.
Now when somebody writes in a review things like Modul8 has a slower media decoder than other applications, he better proves it with some clear benchmarks, like:
- Machine description
- Number of layers
- Effects applied
- Media used
- FPS
- etc.
I'm not saying that Modul8 does not have problems or that it is the best application in the world. However problems need to be clearly defined and bad performances have to be properly demonstrated. Writing that Modul8 uses more memory than it should, or decoding media is slower than other application and trying to demonstrate that by opening the activity monitor does not make any sense. If tomorrow I claim that my Spectrum machine is faster than your Amiga, I better find a good demonstration.
There are many reviews of Modul8 and usually I don't give my personal opinion about them. Everybody can write what he wants. I decided to reply in this specific case because it was posted to the support forum with a comment saying that it resumes the current problems of the application. I'm here to fix the potential problems/bugs in the application, and with all the respect, this review was full of wrong technical explanations that not only did not help me to fix bugs but gives wrong information to our users.
Now I'm waiting for a clear bug report regarding memory usage so I can see if there is a problem that needs to be fixed here. On the performance side, we are doing tests these days on G4 machines to see what's going on here. If you have some projects (as I wrote in another thread) that demonstrates performance problems be sure to send us an email. That would help. Thank you.
Yves.
3Din2D wrote:... but as far as the review goes I have to empathise with the reviewer ...
boris wrote:3Din2D wrote:... but as far as the review goes I have to empathise with the reviewer ...
Of course,
the reviewer and you are the same person.
Maybe is time to take off your mask !
Users browsing this forum: No registered users and 26 guests
Copyright 2017 © garageCube. All Rights Reserved. Powered by phpBB® Forum Software © phpBB Limited.