Home Forums General Panels, Components, Macros Panels look changes while converted in VST

This topic contains 7 replies, has 4 voices, and was last updated by  human fly 11 months, 3 weeks ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #70842



    I’m currently trying to work out a midi setup with several panels opened as VSTs in a vst host called Chainer, under winXP.
    The last versions of CTRLR won’t open in winxp (a kernel32.dll error, that has already been discuted in this forum), so after trying different versions, I ended up using v.5.3.201.

    It’s working, except some of the panels looks and graphics are not there/corrupted, and i have to use the internal host’s potentiometers for vst parameter’s controls. It’s a bit weird, because these panels look good while opened in the CTRLR’s VST. But when i’m exporting them as an instance (restricted), and then open it, they look giberrishy.

    What i’m really missing, beside the beauty of the panels, is the visual representation of the patches i’m working on.

    I’m currently having this problem with the ESQ1 and tx81z panels (last versions), and not with the Mks50 panel, which looks much more “basic”. So i guess it’s a graphic-related issue… Even though as i said the panels look good in the ctrlr’s vst, as well as in the ctrlr stand alone version.

    Sooo: if there’s no fix (might be because i’m using an older version of CTRLR), can you think of a simple way to modify the existing panels, maybe with more primitive graphics, to make them work for me? Is it even possible?

    I didn’t dwelved into panel programming yet, but if it’s just a matter of drag-dropping a couple of sliders in place of the present ones, i should be able to get it. Could it be that simple?

    Thank you!

    • This topic was modified 1 year, 1 month ago by  thatsok.

    Maybe I misunderstand – why do you make instances when the panels are working as Ctrlr plugin? You can open as much Ctrlr plugins as you want, right?



    hi Possemo, well i thought it was the right way to go… 🙂

    I remember having difficulties making the vst work until i read somewhere here i had to export an instance to make the panel controls work (it was in ableton at the time)… So that’s my setup routine now: charging the ctrlr vst in the host, opening the panel in the vst, adjust settings, exporting instance, and voilà, the panel vst is supposed to work on the host. Am i doing something wrong?

    Anyway, thanks for the answer, i’m going to try using ctrlr vst directly.


    To my experience exporting instances can cause problems. I’ve never seen that exporting instances is fixing bugs, but maybe this is just true for the panels I am using. In general I think exporting restricted instances only makes sense if you don’t want other people looking into your Lua-code. Btw: Ctrlr is using free Juce libraries, Ctrlr itself is open source. Why would you want to make some lousy Lua code closed source? Leave alone charging money (for the Juce libraries, Ctrlr, AND a lumpy panel)…



    In general I think exporting restricted instances only makes sense if you don’t want other people looking into your Lua-code.

    This could be a reason. But I’ll give a honest reason to make exported instances:

    Give the user a plugin that behaves as any other plugin and avoid to mess with Ctrlr, many people have a hard work setting this up: Having to use Ctrlr to load a panel, deal with Ctrlr versions (a panel performs fine with a Ctrlr rev. and not with others), configure the panel.overrides file to access each parameter for automation….
    All of the above, plus some issues when a panel is used on different platforms, has created on some people a wrong image with Ctrlr and the panels, that could have been avoided using exported instances, imho.

    Of course, you can also upload the .panel version if you want, but the exported version is a better and easiest option for final users, but a bit of extra work for developers.



    Ok, thanks for enlightments 🙂

    So, i tried to use panels from within ctrlr vst, it didn’t work but it’s probably just a setting problem. Will try again later..

    dasfaker, if i get you right, i should be trying to export instances with different ctrlr rev until i got one right… Isn’t there a library of all ctrlr vsts, where i can download the .dll immediately? Or maybe i should just google them one by one, hoping they’re hosted somewhere..

    Anyway, i think i’m going to let ctrlr rest for a while… Maybe i’ll use it sometime to program my own panels, but for now it’s too hard to configure and figure out. Particularly since i have to use an older versions (under winxp)..

    Thanks for the help!



    Each panel could have been developed with a different Ctrlr revision, as there are a lot of them. A change in a new Ctrlr revision can make a panel unworkable with this revision, so it could be that only one works perfect, it all depends on the edits made on the panel over time. Each panel has (or had) a property to know the Ctrlr revision used (enter Edit mode and look for property “Ctrlr revision that this panel was saved with”

    Here there are all Ctrlr revisions published: http://ctrlr.org/nightly/?C=M;O=D


    human fly

    i agree with dasfaker: having an exported VST dll is better
    for the end user, who will not have to deal with the editing
    features of Ctrlr. i personally found this offputting the
    first time i tried to open a panel as VST. i opened a panel
    that was not locked, clicked on a modulator that wasn’t
    locked, and it ‘jumped’ to another position… i wasn’t very
    impressed with that, and stayed away from Ctrlr for at least
    a year 🙂

    in fact, i would say it would be better if the site featured
    a section for exported VST plugins(or download links/links to
    a webpage) as users do not necessarily want to draft their own

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.

Comments are closed.