Server Connection Lost - will more Memory help?

I’m getting a number of “Connection to the server has been interrupted” error messages.

The obvious thing to say is that I am running quite a big OSC file with a custom module updating quite a lot of variables of the widgets etc. It also has a few images in it. It ran ok on a previous machine but have just moved it to a smaller less powerful PC. Therefore it clearly points at a performance issue somewhere.

My question is about where to start targeting efficiency improvements.

Should I be looking at the custom module?
Or the images - Are they too big - do they sit in the RAM or are they called on demand?
Have I reached a threshold on the number of widgets?
Is the processor struggling - is OSC processor hungry?

Or I have a spare RAM slot in the PC that is running the server - if I put extra memory in the PC will this help?

I know that this is probably not an easy question to answer - but I’ve spent a lot of time building the OSC interface and it worked on the previous (way more powerful) PC so am hoping that an injection of memory will solve things??!

Would you mind uploading your session file ? How powerful is that computer ?

Yes, OSC is a bit heavy on the processor, well the client part mostly; are you using the same computer to access the client app or a mobile device ?

Make sure to disable the server’s debug option when it’s not necessary, printing a lot debug messages can be cpu intensive too.

Or I have a spare RAM slot in the PC that is running the server - if I put extra memory in the PC will this help?

Is most of the RAM used when running the app ? if not then it probably won’t help.

I will the upload the session file and associated custom module. It may not function fully without the cubase template sending it midi messages though, to hide and show the buttons/labels etc. (And it’s only a work in progress - please don’t judge!)

Computer is a small micro - 1.4Ghz AMD, with 4Gb DDR.

I’m running the client server and interface on the microPC - this fires midi to my main PC via rtpMidi connection.

Is it possible to run the “backend” server on my main PC (6 core i7 @ 3.4Ghz with 96Gb RAM) and then just the “front-end” on the micro with the touch screen? Would the big PC then do the leg work?

Tried that - makes very little difference in this case.

Anything up to 80% RAM with CPU running at 75%

Thanks for any advice!

The session file is too big - 6.8MB so to allowed to upload…

Absolutely, definitely worth a try.

6.8mb is a very big session indeed, I didn’t manage to increase the limit, can you upload it elsewhere ?

I’d need to work out how to do this…

We may therefore be establishing the issue…!

I’ve put a folder here with all the required files - hopefully you can see it:

One Drive Folder

I’d need to work out how to do this…

Launch the server on the main computer and make sure both computers are on the same network. On startup you’ll see a message like this:

(INFO) Server started, app available at 
    http://127.0.0.1:8080
    http://192.168.1.10:8080

It’s the app’s address on the network (127.0.0.1 only works on the same computer), but the other one(s) should should from other computers on the network. Simply open this url in Chrome on the small computer.

One of the benefits of doing that is that you won’t need to route OSC/MIDI messages though the network since they are emitted by the server :slight_smile:

Lol, now have that working easily enough (should have read the manual earlier
!!) - now I probably need to revert all my midi sends to pre-migration to the small PC!

It’s still very slow though…

Even if the server runs on a separate system, this session will probably not run smoothly, it’s just so big ! I see 2 things that can be improved:

  1. css code takes about 1/3rd of the file because of duplications that can be avoided using a theme and custom classes
  2. there are more than 2000 widgets (excluding containers) in your session, more than 50% of them are in the “modal_CCPanels” modal. A lot of them seem to be duplicates, and I guess they are not supposed to be displayed at the same time but rather depending on the DAW’s state. I think you could dramatically reduce the number of widgets here and keep a small number of generic wdgets, and use the custom module to change what these do depending on the DAW’s state. That’d require doing some hard work in the custom module.

Agreed - it’s on the to-do list - the session has just grown overtime copying widgets when I needed them, so the css in the widget has grown too I guess.

Yes - I suspected this was the issue - the idea was that each frame in the “modal_CCPanels” has a different layout and depending on which track is selected - and the panel hides or shows - then when you open the modal, only the correct frame is there. Each of the widgets and associated label also changes dynamically to which cc to send to depending on what is visible. I can hard code all of these cc values and labels but not sure that would make a difference - it must be just the number of widgets! Now that I write this down I am realising that I am really probably pushing the limits a bit!

Back to the drawing board I guess with the custom module.

Thanks for all the support on this one - now trying to think of another way!

Do you think it’s the number of widgets or the number of duplicate widgets being updated?

I think it’s the number of widgets, the interface is slow even without updating the widgets.

Also I suspect laying that of them directly in the same container container might hurt performances, maybe try separating them in more different panels ? Edit: I’m not so sure about that actually…

I think that I’m just trying to be too clever/over complicated!

It works a bit better if I have a single container with fader widgets that show and hide - it’s when I then duplicate them up multiple times with the image frames to mimic the VSTi looks that I start to run into real performance issues.