search

RomanKubiak / ctrlr

Ctrlr
BSD 3-Clause "New" or "Revised" License
530 stars 62 forks source link

Random CPU Spikes while using Ctrlr based TR-8s Editor Controller #313

Open Alfonrock opened 3 years ago

Alfonrock commented 3 years ago

Hey Guys! I am experiencing random CPU spikes using the TR-8s Editor Controller by Momo. Im using Ableton 11 on a 2019 MacBook Pro running Catalina 10.15.7 The specs of Ctrlr are the following: Version = 5.3.122, Build date = Wed Jun 17 11:56:49 CEST 2015, Branch = Nightly, Juce = 3.1.1, libusb = 1.0.19,

As my live set is performance based, Its quite problematic to have these spikes as it causes short audio glitching. I can see the spikes coming from the TR-8s editor track CPU meter, they are of a random nature. The spikes continue even though the editor is turned of on some occasions.

I was hoping someone could point me out a possible fix for this, or if I can somehow install the latest version of Ctrlr and make this work without bugs. I really appreciate any input you may have.. Thank you!

dobo365 commented 3 years ago

When having problems with a panel you need to turn to the person who made the panel, especially when the panels are sold (it is the case if I'm not wrong). Aren't Momo panels sold as full exe or VST? In that case, you don't need to install Ctrlr as the panels are self working. And further more, if this is the case, then only Momo can bring corrections to his panels (we are back to the point above). So, unfortunately not so much help for you I'm afraid... You will get much more help if you start doing your own panels ;-)

tomlem commented 3 years ago

Hey Alfonrock

https://ctrlr.org/forums/topic/ctrlr-and-windows-10-2004/

Alfonrock commented 3 years ago

I would love to make my own panels but don't have the time/skills. I appreciate both of your responses!

keinstein commented 2 years ago

In short Ctrlr is not realtime ready and will never be.

Some technical remarks:

CPU spikes can occur in every memory allocation, which means that they can occur in nearly all activities of Ctrlr.

Lua has a garbage collector. It is typically run when the application is idle.

Looking up properties and objects is also expensive (see #157). Especially when the property or name is given as a string (e.g. from Lua code). Looking up names and converting identifier strings into an internal representation are both implemented using a naive algorithm. This takes a lot of time. Here, a hashtable based implementation could speed things up. Fixing this would mean to hack JUCE.

The Lua wrappers around the C++ objects mostly don't know virtual functions which means that inheritance cannot be used properly. So many unnecessary copies are created. Fixing this a huge effort and boring work.

VST does support controlling plugins via MIDI. Midi based software like Ctrlr must abuse the VST standard as Steinberg has no interest in fully supporting MIDI.