Resolume Forum

Hi there,

The title of this post is provocative, but its goal is not to spit on Resolume 3. The thing is just that I experienced too many issues with R3 last week so I had to eventually revert to R 2.4 for a gig last Saturday night.

I have been very disappointed by this, as I really wanted to use R3 for the first time for real. Before that I've been just playing with it and was impressed by new features and DXV, such that I decided to convert all my clips to DXV (this was really long!) and create new clips directly in DXV.

On this forum there are several post from people saying they used R3 all night long for party, and I really would like to learn from you how you set up things. I apologize in advance for this very long post, and thank you for reading it.

Here are the problems:
I wanted to be able to choose amongst around 600 clips, all DXV. So I created a new composition and arranged my clips by "subject" using Decks. I loaded no more than 30 clips per decks (3 layers 10 columns), and I ended up with 37 decks.

- First problem: when there are more than 10 decks, the 11th and above are not displayed as tab for obvious reason, but appear in a popup list on the right of the screen under a (+) menu.
Ok, but choosing one deck in this list just do nothing for me. There is probably a bug here... Thus, If I wanted to open one deck in this list I first had to close other ones, until the one I want becomes displayed in a regular tab.

- Second problem: each time I saved the composition (let say after creating 3 decks), the time to complete this operation was very long (2 minutes) and R3 was freezed. Ok, I was not playing live, I can handle this.

- Third problem: when I closed and re-open R3, the composition was loaded, but with only 2-3 randomly chosen decks, and 6-7 empty decks. Ok, then I could double-click on every deck entry in the "composition" tab, bottom right of the screen. Loading a deck this way is very long, freezes everything, and eventually I ended up with the popup list for all decks but the first 10 again, and I was thus unable to access their content...

- Fourth problem: Ok, then I decided to load only 10 important decks to start with, and maybe load other during the party, hopping the FPS freeze will not be noticed. Note that "load other" means: first close one deck to make room, and the load a new one in orer to avoid it being in the popup list.
But then, I experienced the well documented deck switching freeze: each time I click on a deck tab, it takes several seconds to display the thumbnails, and the FPS drops to a very low value.

So, I decided to stop using decks, and as recommend by someone on this forum, I put all my clips on a single deck: 4 layers, 150 columns: all 600 clips loaded (very impressive by the way). Saving this new composition was a bit long, but anyway...

- Fifth problem: I thus closed R3, and started it again (in order to check whether everything can be restored properly): R3 displayed a few elements of the GUI, and while looking freezed actually loaded my composition. After several minutes, the completed GUI was shown, and it took another few 10th odf seconds to display all clip thumbnails. Ok, this is is once per session, I can handle it, as long as I don't have to restart R3 while performing...

- Sixth and final problem: with my large deck, when changing the layer order, there is also drastic frame drops /freezes for a few seconds, perhaps because the whole thumbnail line is moved too... I understand this can be a feature, but I set the global clip assignment to be "active layer", so I don't see the point of moving all the thumbnail in this case. For me, changing the layer order is really a basic action I would like to be able to do as often as I want without any noticeable freeze. In R2.4 this is instantaneous.

I really tried, but eventually I decided that R3 was not usable for me in live and I reverted to R2.4: luckily all my DXV clips were playable in R2.4, but not as smoothly as M-JPEG: when using 2 or more DXV at the same time, I had frame drops (I can give a more detailed report on this).

I think I have a decent machine: WinXP SP3, Intel Core2 Duo, 4Gb Ram, a pretty fast hard drive carefully defragmented, Nvidia GTS 250 video card, and I usually find it to run smoothly (minimal set of services running, etc.), so I am really puzzled: how you guys around are doing? Are you using only a few clips? Are you drag'n'droping clips into a main deck, just when you need them, so avoiding having many thumbnail at the same time? Are you not changing layer order? Maybe you're not using DXV (maybe loading DXV thumbnail is slow)?

Any hints would be much much appreciated. I am very disappointed by this bad experience, and seriously think of sticking with R2.4 as long as all the issues above are not solved. I can not figure out why basic actions like changing layer order or switching decks can reduce FPS. This looks like a basic architecture problem, that does not match with the overall great quality of Resolume products.

Thanks in advance.

Wow, big explanation here. It looks like most of your issues are due to the clip loading & saving decks. Saving a deck for me does not take that long, but then again I don't have more then 30 clips in my deck. Both of those actions are hugely dependent on the speed of your HD.

R3 reads each video clip to make sure it is there in the right place instead of using a thumbnail placeholder like R2. I think it would great to disable this feature for live sets, its good to know if your clip is indeed loadable and in the right location before you click on the clip. Its a bummer in R2 to click on a clip just to find out the file is not in the same location anymore, but loading decks is a problem for most people using R3. My frame rate drops down to about 20fps on my MBP, but I'm only using a 7200 speed HD via firewire.

Although I think you would see a huge performance gain by adding an RAID 0 as your clip HD. then loading decks would not be as much of an issue.

As for changing layer order, I never do that. But if R3 reads all the clips again just because they move location in the deck...this is really a problem.

Personally I would like to see clips loaded into ram. Since most of us have several gigs of ram in our computers, loading clips from memory would be a huge performance booster when performing live, and reduce the need for faster HDs. load a clip once into ram after the first read, and then never look back.

600+ clips in one deck. Very impressive indeed. shows the power for R3. Well, your not the first to complain about deck loading. maybe there will be improvements in 3.0.2

can you send me a screen shot of how decks look like when you have more then 10 decks in one comp. I have never seen this pop up list.

-- Edit -- What are the specs on your HD (RPM, Internal, External?) .. are you using a laptop or desktop computer? ....

Thank you for your feedback! It's frustrating for us that we can not fix everything as quickly as we would like to but it is the only way to improve Resolume, we're making a LOT or progress. Your feedback is extremely important.

mandawah wrote: - First problem: when there are more than 10 decks, the 11th and above are not displayed as tab for obvious reason, but appear in a popup list on the right of the screen under a (+) menu.
Ok, but choosing one deck in this list just do nothing for me. There is probably a bug here.

Just tried it and it indeed does not work via the menu. We'll fix this.

I can not figure out why basic actions like changing layer order or switching decks can reduce FPS. This looks like a basic architecture problem

All problems you describe are related to indeed an architectural problem with the compositions and decks. They are stored as XML and when there are a lot of elements it get's slow. We have tried to solve this already but unfortunately there is no "quick fix" for this. We are going to solve this but it requires some big changes that are not safe nor easy to do. We will resume work on this after the upcomming free update which will be released "very soon".

Hi,

thanks a lot for your replies.

Gradek>

Well, indeed, with my 600 clips in one deck, it could be implemented like having "everything" in RAM (not every full clips, but at least thumbnails). If a clip is not there when the deck is first loaded, then indeed it's good to have a way to notice it asap, but in my opinion, it's very improbable that you will move clips around during a session.
And anyway, I am sure there is a way to program things such that the display thread has a sufficient priority not be disturbed by this basic IO management. Even the slowest disk access does not consume that many CPU cycles, and I guess not a lot of GPU cycle neither

But, are clips directly streamed from HD to video RAM/GPU? I can't believe it is so, so why would disk access slow done GPU processing?

Regarding changing layer order: I really wonder how you do, then... It's very funny to see that what I consider as a basic must have feature is not used at all by someone else!

I use it this way: let say I have a clip playing in top layer with full opacity. I load another clip in the layer just below, maybe setup some effects, change speed, whatever. Then, I set the blending mode to let say, Luma key, change opacity to 0%, change layer order such that this layer containing the new clip is now on top, then I gradually increase its opacity (up to 100% or not, depending what I want).
Is this a bad behavior? How would you manage to do something similar?

Regarding my config: it's a desktop computer. My HD is an internal Wester Digital RE4-GP. Tests I read show that it's a relatively fast disk. I measured something like 80MB/s on average. But again, with DMA and modern OS, disk access should not use CPU...

Regarding screenshot: I'll post it asap.

Bart>
I noticed indeed, that the composition file is something like 15MB. It's should take 1/4th or 1/6th seconds to load it into memory. Then ok, parsing all this XML can be CPU consuming, but isn't just a matter of thread priority?
I'll try to monitor my CPU while loading a composition or deck, because I am not sure I noticed 100% CPU usage, so this might be interlocking problem... I'll test and tell you.

Hi again Bart,

just to add that I know that fixing everything takes time, and that it could be frustrating to read post from people saying "this and this doesn't work" while you already fixed so many other things. My post tried to be constructive, maybe in a disappointed mood, but not filled with anger, I hope you saw it.

However, I have to say that it's hard to consider R3 as a final product when things like managing clip thumbnails, switching decks or swapping layers (all the basic behind the scene stuff you can expect from a VJ program) have such a big impact on the quality of the output, i.e. on what your public sees. So, in my opinion, these should be high priority items in your pipeline.

Well, it's just my opinion, but I hope you see my point.

Hi Mandawah

mandawah wrote:Hi,
I use it this way: let say I have a clip playing in top layer with full opacity. I load another clip in the layer just below, maybe setup some effects, change speed, whatever. Then, I set the blending mode to let say, Luma key, change opacity to 0%, change layer order such that this layer containing the new clip is now on top, then I gradually increase its opacity (up to 100% or not, depending what I want).
Is this a bad behavior? How would you manage to do something similar?

I don't understand why you don't prep the clip you want on top on a layer above your current clip that is playing. you can do everything you said, without chaining the layer order. then bring the clip from 0 to 100% opacity.

you can also preview any clip by click the tab below the video icon in the preview window. while in that mode you can add clip effects, change speed. audio volume, etc.... before you even add it to the layer. of course you can not preview layer FX in the clip preview window but, that's not such a big deal.

only reason I see the need to change the layer order is if you have clip A on top of clip clip B and for some reason, you need to change the layer order in order to achieve a different blend of B on top of A.

But if its just about prepping the next clip, no reason you can't do that on a layer on top.

But, are clips directly streamed from HD to video RAM/GPU? I can't believe it is so, so why would disk access slow done GPU processing?

No, clips are constantly being accessed by the HD while active in a layer. so if you got 3 clips running, then change decks, the HD will be accessing those three clips, in addition to reading for a quick moment all the new clip in the deck (even fast HD have a hard time keeping up with all that data). try changing decks while only one clip is active in one layer, I bet the slow down won't be as dramatic. The DVX codec just takes the burden of decoding from the CPU to the GPU. No Ram involved.

That is why I think loading clips into ram would be good, no need to access the HD while playing. Then if you switch decks the clips playing in an active layer are not effected by the HD accessing the new clips in the deck because they are being streamed from RAM. But resolume does not do so at the moment.

All problems you describe are related to indeed an architectural problem with the compositions and decks. They are stored as XML and when there are a lot of elements it get's slow. We have tried to solve this already but unfortunately there is no "quick fix" for this. We are going to solve this but it requires some big changes that are not safe nor easy to do. We will resume work on this after the upcomming free update which will be released "very soon".

Bart, do you think loading clips into ram would be a easier workaround for this issues? I don't know much about XML, but if playback of active clips are done from RAM then there would be no burden due to HD access while a new deck is loading. I know this would not be possible for long clips that are too big for RAM. But all those sub 200mb clips in my deck could be buffered into ram on first read.

First read could either be the opening of a new deck, or when the clip is previewed or made active in a layer.
Clips could stay stored in the ram until there is no more space, and a new clip takes it place. A simple check box in the clip property could determine if a clip would load into ram or be streamed from the HD.

Thanks Gradek,

Ooups: active clips in layer are real-time streamed from HD? Sounds like a bad idea indeed, especially if at the same time *all* clips have to be access to redraw the thumbnail... It's a HD nightmare, even if clip files are physically very close to each other and each in one fragment.

I supposed the idea here is to permit huge clips (that won't fit into physical RAM) to be played anyway, and to avoid latency before playing the first frame.

An audio program I use is programmed to always load audio clips into memory (up to a given size I suppose), amd there is a per-clip option to force HD streaming instead, useful for large clips, or to avoid a pause when loading the whole file.

Anyway the Resolume guys seemed to find a very good solution to this problem in R2.4, so it's perhaps possible to apply it to R3 as well.

Regarding "why changing layer order": Ok, let say the clip I prepared in my explanation is now in the top layer, and that I increased it's opacity from 0 to 100% with luma key, thus making it smoothly replace the previous top one. The old top one is now hidden in the layer just before the top one.
I then need to prepare the next one, and I want to blend it the same way. I can prepare it using the preview (very nice feature indeed), but I don't want it to just replace the top one, I again want it to smoothly replace the top one, by first moving it to top with 0% opacity and increasing opacity.

You see that my point is to repeatedly swap the "top" and the "just above top" layers: I put my new clip in "just above layer" set the opacity to 0%, move this layer to top, increase the opacity, and the do it again and again..

So, of course I can prepare the clip directly in the top layer, but this will obviously work only once... I got this (bad?) habit from using Resolume 2.4.

Ahhh, I see what your doing. I often go back and forth blending on and off, so I don't always need to replace the layer on top.

To do what you need, I would use the cross fader. Set the top layer to A and the Bottom layer to B both at 100% and then you can prep your clip below and just move the cross fader back and forth instead of bring up opacity.

you can even setup blending stacks to cross-fade, for example layer 1 and 2 set to A and layer 3 and 4 set to B.

Hi Gradek,

Thanks a lot for your advice: the crossfader may indeed replace layer swaps in this case, I did not think about it. I was looking for this kind of tips, so thanks a lot. I'll try and let you know if the behavior is as expected.

I know that R3 is claimed to be a different program than just a update of R2.4, so it's up to me to acquire no habits.
The move-up/move-down buttons are there in the layer anyway, so I am disappointed not being able to use these, and I would of course prefer that it's the machine that adapts to the man and not the other way round, but nothing is perfect...

Thanks again.

Edit: well, no, it won't work unfortunately: what I need is the "just above top" layer at 100% opacity and top layer at let say 50% opacity with luma key. Using the cross-fader will lead to having both layers at 50%, and the effect won't be the same at all...