Agreed with a lot of other posters.  This forum has a nice, inviting, feel.   Change the back end to whatever software works best, but keep the feel.   And yes, the current search stinks so please choose one with a good search function.  For example, gearslutz's search function works great.
 
It would be nice to keep the names/accounts, if possible. 
 
urock

In this forum you can post a question and usually be confident about getting some good suggestions. This is certainly not the case in all forums elsewhere. It's frustrating when you have a specific question, you google it and find a forum where someone else has asked the exact same question, but scroll down to read the replies and find that nobody has responded. This almost never happens here with the Cakewalk forum.

Can we get like buttons in the new forum, still keep the helpful, but having a like counter would be good too

I wouldn't mind moving the forum as long as it is seamless to the members.  I would like to see users stats carry over to the new forum.  Total posts, when they joined, and anything else that makes sense to know who the veterans are.  Thanks for asking BandLab.

This is not only the best forum I also like the way it looks and everything about it. And I honestly dont know what exactly will a software change technically would do.

I am a part time web developer myself in real life, and I have dealt with many forum software in last 10 years. Comparing with other forum software, I think vBulletin will suite the best for Cakewalk forum. Just have a look at Gearslutz and homerecording.com for example.

James Argo
I am a part time web developer myself in real life, and I have dealt with many forum software in last 10 years. Comparing with other forum software, I think vBulletin will suite the best for Cakewalk forum. Just have a look at Gearslutz and homerecording.com for example.

And www.gainjunkies.com

Whatever changes might come in the appearance of any future forum, I hope the family friendly policy of not allowing swearing continues. I hate hearing foul language, let alone seeing it written infront of me. I choose to not associate with people who use vulgarities all the time, another reason I keep off most social media. That’s another thing I like about the Cakewalk forums.

mudgel
Whatever changes might come in the appearance of any future forum, I hope the family friendly policy of not allowing swearing continues. I hate hearing foul language, let alone seeing it written infront of me. I choose to not associate with people who use vulgarities all the time, another reason I keep off most social media. That’s another thing I like about the Cakewalk forums.

Have to agree with you there. 
 
I do like the Gearslutz forum software. Easy to navigate and easy to read on a mobile device.

For the roadmap - i'd suggest to slpit UI for multithreading first and fix all VST related bugs, i got 2 monitors and when console is opened in multidocking on second, then core1 gets overloaded and it produces sound errors.
VST bugs i've sent for a support, but if you'd like to change the forum, then maybe first thing you'd better change the online bugreport, so users could see similar bugs, test or prove it.
The arp fx bug is here in forum, that you can't add vst-arp as midi-fx, only mfx.
The other is about jbridge i guess, that it is reloading all patches sometimes when it should only change next and read only 1, instead it reloads all bank and then changes (occurs probably on auto-saving, can produce error).
And talking more about multithreading - is a thread control and balancing, usually each next vst loads first core, but if you move UI-thread to last core, then there will be more resources for vsts, since you can't change priorities of side-code. That's why i'd like to separate those for more threads, then if any threads goes into error it must not hang whole application, so if any vst hangs then for example a "reload vst" function can be called for any-not-responding or hand picked vst, just like we can stop and restart all sound on top. So this start/stop sound should be a separate thread and load/unload vst also as save/change-vst-state, because when playing live these functions can conflict (i think).
 
Really i'd suggest to use more videocard 3d-resources and GPU power for console (for example) and GUI in a whole, that will free up more CPU resources.
Sorry, maybe that's too much for suggestions and ideas... gl with that