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??!
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.
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
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
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:
css code takes about 1/3rd of the file because of duplications that can be avoided using a theme and custom classes
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.
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.