Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Alfonrock opened this issue May 27, 2021 · 4 comments
Open

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

Alfonrock opened this issue May 27, 2021 · 4 comments

Comments

@Alfonrock
Copy link

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
Copy link

dobo365 commented May 27, 2021

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
Copy link

tomlem commented May 28, 2021

@Alfonrock
Copy link
Author

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

@keinstein
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants