Forum Replies Created
-
Posts
-
Pascalc, could you please make your copy of the source code available?
Due to Steinberg’s copyright claim about vst, the source code is removed from github.
Could you maybe upload somewhere and provide a link please?
Thnx.Maybe Intel processor backdoor fix has something to do with this?
https://appleinsider.com/articles/18/01/03/apple-has-already-partially-implemented-fix-in-macos-for-kpti-intel-cpu-security-flawThe article says apple partially addressed that issue on 10.13.2
I’ve done these tests on 10.12.6
Also, I’ve updated my laptop to 10.13.4 and the problem happens there too.
So I don’t think that could be the problem.
Ctrlr problems started with Sierra and High Sierra.I really wish atom would at least do a compatibility update for the Mac version of Ctrlr.
I really have no problems with Ctrlr v5.3.198 on mac. I think it’s incredibly good for a free software. You only have to add images with Ctrlr v5.3.163 other than that Ctrlr v5.3.198 is perfect, well was perfect until Sierra happened.You write about 32bit versions. I thought that the Ctrlr Mac build is 64bit? But then it wouldn’t be possible to run the plugin on a 32bit DAW. So the newest Ctrlr Mac build is in fact 32bit?
I have been wondering that for some time now too. The same Ctrlr plugin for both AU and VST, work in 32-bit and 64-bit environments. I really don’t know how that happens. But the good news is that when you make a restricted instance, it works in both 32bit and 64bit environments too 🙂
ok, I’ve checked Ctrlr on different DAWs. Here are the results:
macOS Sierra 10.12.6 on Mac Pro (Late 2013), 2.5 GHz 12-Core Intel Xeon E5, 64 GB 1866 MHz DDR3
Reaper v5.70/64: VSTi & AUi Ctrlr major performance problem.
Reaper v5.80/64: VSTi & AUi Ctrlr major performance problem.
Reaper v5.80/32: VSTi & AUi Ctrlr major performance problem.
Ableton Live v9.7.1 32bit: VST & AU Ctrlr major performance problem. (AU little better)
Ableton Live v9.7.1 64bit: Ctrlr-VST works better but not perfectly smooth. Ctrlr-AU is ~acceptable.
Ableton Live v10.0.1 64bit: Ctrlr-AU works perfectly smooth without any performance issue.
Ableton Live v10.0.1 64bit: Ctrlr-VST shows major performance problems.
Hosting AU v1.5.0 microDAW: Ctrlr-AU works perfectly smooth without any performance issue.
Logic Pro X 10.4.1: Ctrlr-AU works perfectly smooth without any performance issue.
Bitwig v2.2.2: Ctrlr-VST shows major performance problems.It seems that on Sierra Ctrlr has a major issue with its VST version.
AU version seems to be doing good on some DAWs.
None of these problems were present on OSX Yosemite 10.10.5So, Ctrlr is not working properly with Reaper and Bitwig on Sierra.
However, Logic and Ableton is ok for the time being with AU only.I’ve upgraded my MacBook Air to High Sierra and the performance problem is still there.
Maybe I should also try this on Logic.Also, I should mention that after upgrading to High Sierra, the general performance of my 2012 MacBook Air did not get worse, it actually got a small bit better than before.
Harddrive write and read speeds are almost same (writes a bit faster and reads a small bit slower) I mean read was 450MB/s now it’s 444MB/s. Also Write was 389MB/s now it’s 393MB/s. and geekbench shows High Sierra gives the best overall score compared to Yosemite and Sierra. So that’s that!wow that’s amazing.
I’ve just tried http://ju-x.com/ (Hosting AU – microDAW – Free!) as a plugin host.
It’s a 589 KB simple host and the Ctrlr plugin/panel worked incredibly smooth.
What I don’t understand is why is it slow on my older version of Live?
It used to be fast on it and the only thing different now is the OS.
Very confusing.
I will also try it on High Sierra when the installation completes on that laptop.It’s almost impossible to use your MKS-70 panel now :-(.
I’ll try another plugin host now. thanks for that idea 🙂here is a video showing the problem
below is the description from the video
The first part shows the performance problem when ctrlr is a plugin.
The second part shows proper performance of ctrlr in app format.
The same problem applies to panel in ctrlr as plugin or restricted vst/au in plugin host.
This problem occurs in Sierra. This problem is applicable to any panel.I’m sure this will make the problem very clear.
This happens to any panel so it’s a big deal.I’ve just checked on a clean installed Sierra on my MacBook Air and it has the same performance issue.
I will now upgrade this Mid-2012 13-inch MacBook Air to High Sierra and post here if it behaves any better.Hey Pal,
Nice to hear from you.
Thnx a lot for the information. I recently developed a decent amount of paranoia towards apple.
The problem is that there used to be a separate update for firmware/EFI (extensible firmware interface).
Apparently since 2015 silently the firmware update became part of the operating system upgrade.
I did not have issues with Sierra regarding performance but I tried High Sierra with one of my older mac minis. Upgrading the OS and thus upgrading the EFI/firmware made the mac mini very slow and even when I downgraded the OS to Sierra later, because there is no way to downgrade the firmware my mac mini stayed slow. 🙁I believe the firmware/EFI update/upgrade would present no effect on a Virtual Environment. Most probably it would silently fail in the background due to not finding a compatible hardware.
So I’m really nervous about upgrading the OS to High Sierra on my studio device which is a pimped up thrash bin model Mac Pro. Currently, it’s on Sierra. I know upgrading it to High Sierra will render some plugins and some software incompatible also. However, if Ctrlr is not working properly with Sierra but if it’s working ok on High Sierra, I wouldn’t mind the Hassle provided it will not slow my mac down.
I’m just afraid that the same performance issue will be present on High Sierra too.
So I’m just curious about the reason for this performance issue with Sierra.I will make a video of this issue and provide a link here to make it clear.
Hey Pal,
Nice to hear from you.
Thnx a lot for the information. I recently developed a decent amount of paranoia towards apple.
The problem is that there used to be a separate update for firmware/EFI (extensible firmware interface).
Apparently since 2015 silently the firmware update became part of the operating system upgrade.
I did not have issues with Sierra regarding performance but I tried High Sierra with one of my older mac minis. Upgrading the OS and thus upgrading the EFI/firmware made the mac mini very slow so even when I downgraded the OS to Sierra later, because there is no way to downgrade the firmware, my mac mini stayed slow. 🙁I believe the firmware/EFI update/upgrade would present no effect on a Virtual Environment. Most probably it would silently fail due to not finding a compatible hardware.
So I’m really scared of upgrading the OS to High Sierra on my studio device which is a pimped up thrash bin model Mac Pro. Currently, it’s on Sierra. I know upgrading it to High Sierra will render some plugins and some software incompatible also. However, if Ctrlr is not working properly with Sierra and if it’s working properly on High Sierra, I wouldn’t mind the Hassle provided it will not slow my mac down.
I’m just afraid that the same performance issue will be present.
I will make a video of this issue and provide a link here to make it clear.I started using Ableton Live 10 and since it doesn’t work on Yosemite, I had to upgrade to Sierra from Yosemite. Since I’ve tried High Sierra before on another mac and it had speed problems (it also does a firmware upgrade without telling you) I didn’t upgrade my trashcan model MacPro to High Sierra.
I have Live v9.7.1 as 32 bit and 64 bit also Live v10.0.1 (it is 64 bit only)
Since I’ve upgraded to Sierra, the panels are not working smoothly when they are a plugin.
When Ctrlr is either AU or VST, a restricted AU or VST, in any of the above-mentioned versions of Live, it does not work smoothly. Even the Ctrlr editor interface becomes sluggish without any panel loaded.
As a standalone restricted app or as a panel in the standalone ctrlr editor it works fine.
So the problem is with the plugin versions of the Ctrlr.I guess we need a Mac Update for the Ctrlr or a solution for this problem.
Is anybody else having this problem with Sierra?
Is anybody having any problems in High Sierra?
I wonder if it works ok as a plugin in High Sierra?Please help…
yes, you can use it just as a button of course but the question was how to launch it from Lua. You need Lua to assign it to a popup menu for instance. Otherwise, you can just use the button if it fits your need.
Hi infrasonic,
Add a button, name it ‘MidiSettings’
Set it’s ‘componentInternalFucntion’ property to ‘MIDI Device Selection’
Make it invisible or hide it in an unused layer etc.assign it’s component to a variable:
MidiSettings = panel:getModulatorByName(“MidiSettings”):getComponent()then on lua, maybe from a popup menu do
MidiSettings:click()enjoy 🙂
You can use the following.
.Net Naming Guidelinesok, I got restricted vst instance to work with zoom in correct host window size.
Currently, Ctrlr does not provide an interface to modify host window size in a restricted instance. This is very sad. I hope Atom would provide a method at some point. If you need to set host window size, you can only do this before exporting. After export, host window stays fixed to what was initially set.
Here is how it works with any zoom setting.Let’s consider you have a panel with a size of 1910 x 1330 and you want it to be at 0.7 zoom, which makes 1337 x 931, so set your “uiPanelCanvasRectangle” to “0 0 1337 931” by entering the values manually and insert the following line to your ‘onPanelLoad’ method.
panel:getCanvas():setSize(1910,1330) panel:getPanelEditor():setProperty("uiPanelZoom",0.7,true)This will make your panel programmatically cropped but have it viewed at the correct size. The issue here is that host window size is set by the panel:getCanvas():getWidth() and getHeight() parameters, which does not change with zoom. That’s why we’re using a cropped panel. However, panel:getCanvas():getParentWidth() and getParentHeight() gives a size dependent on the zoom setting, and host window size should use those, even when if you still don’t have the ability to change the host window size on runtime.
Also, Ctrlr v5.3.198 on Mac, crops the window with 24 pixels from the bottom when you export a restricted instance, so to compensate that, set your “uiPanelCanvasRectangle” to “0 0 1337 955” adding 24 pixels to height.
Finally, if you want the menu bar to be hidden add the following as well.
panel:getPanelEditor():setPropertyInt("uiPanelMenuBarVisible",0 )
Just don’t forget to implement a way to have the menu bar appear when you need it 🙂Hope this helps someone.
There are a lot of parameters that are not visible in the VST parameter automation list.
Is there any way to deal with this?
thanks
a.Hi alfonso,
If I understand correctly, you’re talking about modulators that become visible in your host so you can automate them in your host right?
First, the relevant modulators’ “modulatorVstExported” parameters should be set to enabled. I use Ableton, so click ‘Configure’ on Ableton host device and delete if you have stuff there, then move a modulator, it will be exposed on Ableton host device.
I hope this helps.
I hope you’re using a journalling filesystem on your Mac.
check my post
Lost 3 days work 🙁
good luck 🙂Currently, as far as I can tell this is a missing feature of Ctrlr when your end product is a restricted instance. If your end product is an instance or just panel etc, I would definitely recommend considering higher resolution screens.
try to imagine by considering this image how small your panel would look when you design it on your laptop and how someone with a 4k display would see it.
If you design your panel to be full screen on your laptop, it will look almost like 9 times smaller on a 4k display. Now imagine properly filling that 4k display with your awesome panel 🙂
That’s why you need a zoom feature 🙂
you design for 4k and use the zoom for your 1366×768.
