garageCube

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

First of all thanks for the link and thanks for the review.

Now there is a couple of things in this review which needs some clarifications :

- 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 take 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.

- 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.

- 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.

- 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.

- If you have operational bugs, send us a bug report. We can only fix problem that we know about.

- 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.

the described heavy CPU base load for an empty program does not appear on my macbook pro 2.33.

here i have a base load of only 4-9% of the CPU. even when running large PAL DV movs it hardly rises beyond 25%. this was measured with istat 2.0. i can easily run several layers with multi filters before the framerate drops.

on my desktop G5 single 1.8 PPC under 10.4 i have the described 20% baseload...

but as yves has explained, this is a very unprofessional testing, maybe it does not mean a lot at all... great software anyway!

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.

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?

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.

I have to say I agree with the reviewer in being able to force a target resolution - that would be very handy.

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.

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.

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.

Agreed - I think the reviewer had the above in mind when he mentioned that.

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.

I have to say that running test according to the review I can only agree with the reviewer, since I am seeing the same effects. For example, I didn't even notice the frame glitching he mentioned until I compared it with Quicktime.
Some of the review is personal opinion (that's what makes reviews interesting!) but it could only serve to improve the application.
As for the technical side, from this single-G5-user, I am seeing exactly the same effects the reviewer mentioned.

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?

So you mean that before the review, everything was working okay ?

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.

3Din2D wrote:I have to say I agree with the reviewer in being able to force a target resolution - that would be very handy.

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.

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.

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.

3Din2D wrote:Some of the review is personal opinion (that's what makes reviews interesting!) but it could only serve to improve the application.

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.

yves@garagecube wrote:So you mean that before the review, everything was working okay ?

Hehe - sometimes though, reviewers point out some things that aren't noticed, a bit like someone showing that a door wasn't locked.

For example, the media 'glitching' I didn't notice until I saw the review - 25FPS video (any format) will not play smooth on a PAL 768x576 output - but if I run the same media through Quicktime or many other apps, they *do* play it smoothly. Modul8 doesn't seem to be able to update to the media's actual FPS.
You can test this with a scrolling grid, for example, preferably a computer generated one. I was shocked to see it not being able to honour the 25 fps smoothly, with the CPU/GPU barely taxed.

This alone brought me to think the reviewer has a keen eye for detail and so on for the rest.

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.

I redid the tests under various conditions - in some cases (with the same clips) my memory goes up to 900MB used and in other cases 580! Wether this is a modul8 or OS issue I don't know. What I did find was that with some medias, even if I set maximum memory size to 80Mb and the 'info' tab in modul8 says their uncompressed size is 75MB, it won't preload that media uncompressed (bug?).
(P.S. It would be nice to force modul8 to NOT load medias uncompressed - perhaps a checkbox in the file dialog?)

I made a staggering discovery today - these memory issues *do not* affect 2.0.2 with the same preferences...

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.

It would be useful because it would be very useful Not only would effects run faster (if needed) but also (especially with the networking aspect) be very good in case visiting VJ's 'drop in' media to someone's machine which is slower than theirs. Say a user is VJing and (as happens a lot) another joins in and says 'hey, here's some clips' - which are inevitably DV PAL or NTSC, would max that machine's CPU and come out horrible. And it would take too long to re-encode. I've seen it many times. Call it a 'feature request'

Also, having a fixed resolution also precludes the use of a large amount of capture devices - people can't bring their HD camera, for example, because the amount of CPU/GPU power for HD effects is enormous. If they could run effects on the HD captures at 640x480, they would be able to benefit from the quality of the camera while being able to perform realtime.

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.

I have to say I disagree with you here - 20% is a LOT of overhead - to the point that while playing a movie, that's 20% + movie decoding overhead, which is far more than any other VJ application I have encountered. If it can't be optimised, fine, I'm just saying it's a lot compared to the others. I know there's a lot going on but even other gui-intensive realtime apps take less CPU.
I am curious about one thing - is every module 'run' per GUI tick? Even if it's not being clicked on?

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.

I agree in some ways too - but as far as the review goes I have to empathise with the reviewer - I have met a lot of VJ's that have seen me run modul8 and asked 'you're running 2.5, right?' When I answer yes, they inevitably say they're still running 2.0.x because of some of the issues the reviewer pointed out. Wether some are OS-specific or due to modul8 is, of course, under investigation.

Don't get me wrong, I love modul8 and it's the best VJ application I have used by far. It does suffer from some problems though and despite some people not noticing some of the reviewer's issues, the information is there nonetheless to investigate. After all, the reviewer must have taken his time with that article, which means he (or she) cares, rather than be influenced by the status quo.

I see modul8 equivalent to a Mac. Mac users are now blessed with some fantastic machines - but they didn't design themselves. Apple have heard and worked on all the complaints and comments that the users who care about what they use have issues with, like reliability, noise, performance and so on. Some of it is painful, but at the end of the day you end up with something of beauty*.
If you can sort the issues out, modul8 will be unstoppable

*Except firewire audio, which is crap on OSX

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 !

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 !

No mask here dude - I checked his profile on vjcentral, the reviewer is using an email from a collective I belong to, rofl! I asked the guys and it turns out it's someone I know; you can contact him at the main email address and the guy who runs it will forward you if you have any questions.

Whatever... I think that we can resume the point of view of the reviewer (and yourself ) as :

- Modul8 2.5 uses more memory than it should
- Modul8 2.5 is slower than it should (especially comparing to the V2.0).

To finish with this thread:

- We know that there are some speed issues with some mono-processors machines (1.67 G4, mono G5) and we are working on it.
- There is always room for optimizations and I'm working on several speed improvement that will be included in the next minor release V2.5.3.
- Of course the V2.5 is not the V2.0. In some area the V2.0 is faster, whilst in some different context the V2.5 is faster.

All in all, I think that we understood your view and hopefully, you will be happy with the future improvements of Modul8.