Virus TI Midi Editor based on Ctrlr

Let's clarify some points:

Ctrlr can be used in several ways:
·As a standalone app, where you can load several panels inside a single Ctrlr instance. You have to open Ctrlr and then load any panel you want.
·A panel can be saved as a .exe (That is, a Ctrlr instance with only one panel loaded). This way you can create a .exe for each panel you want.
·As a Vst inside any Daw (same procedure as in the first case)
·A panel can be saved as a Vst (that is, a Ctrlr instance with only one panel loaded. Same procedure as in the second case).

For the two first alternatives, both Ctrlr and the panel work fine. The problem is that a panel will not work on every Ctrlr versions. The other two alternatives never worked fine with any Ctrlr revision, unfortunately.

With each new Ctrlr version there are some changes that make all panels incompatible with the previous revision, so if I fix the panel to work with a new Ctrlr version, the previous versions will fail. I've been updating the panel to be working with the newer revisions, with the hope that Ctrlr will be finished and polished soon. This has not been the case, so I decided not updating the panel to the last Ctrlr revisions any more.

So if anyone is interested in using this panel on one of the first two alternatives above, let me know. I'll check which Ctrlr revision is the best and test the panel to be sure it's working fine, and I can solve any problem or doubt you could have using it.

Disclaimer: I'm on Windows and I have a Snow. I never tested the panel with a non Snow Virus TI and on a Mac or Linux. If I remember correctly, the only difference between the Snow and non Snow Virus TI is the patch output. One user says this option is not working with his Virus, but we didn't found a solution. If someone else have the same problem, please let me know.

Zitat

Sorry, I wasn't implying any fault of yours in the panel… as a fellow
developer, i recognized the issue was Ctrlr's overnight build process.
this ridiculous model means as a panel developer are developing against a moving target (impossible!).

Ctrlr should follow a proper release model, and give panel developers a stable release to use.

No problem, I wasn't offended. Just wanted to clarify that, at least as a standalone application, it really works.

Your are absolutely right. Almost every panel is sooner or later abandoned by it's author due to what you say. I did panels for all my synths to find later that they were useless inside the Daw.

Btw, have you developed any panel?

Zitat

One idea.. I didn't know that Ctrlr could build .exe (does it build executables for mac as well?)

why don't you release a executable/standalone,

that way your users will not have to deal with the Ctrlr build, and you
will know you have released a working version. (since you will control
the ctrlr version)

Yes, once you open a panel on Ctrlr running as standalone you can save it as an .exe. On Mac too. And if you open the panel inside the Daw you can save the .dll for this panel, that is, the Vst version, just like any other plugin.

You are probably right. I didn't did this mainly because Ctrlr wasn't finished and I thought that this will no take much time , I was waiting a stable version that could work fine inside the Daw and then I would release the .exe and .dll versions. But yes, I will check it and will release a .exe version that will work 100%.
But as I said before, anyone can build the .exe (especially Mac users, as I'm on Windows and can't do the Mac build), just open the panel and "export as instance".

Zitat

Id like to also say , I was impressed with the panel, its obvious a considerable amount of work was put into it…

including a lot of experimenting with the TI to get the correct values as they are not documented.

Its impressive indeed, but I think many don't get past the Ctrlr problems to see this - which is a great shame.

Alles anzeigen

Thanks for your kind words. It was really a challenge, as I didn't found the docs about midi dumps and how to read them (in fact, there are still some bytes that are a mystery to me and don't know what they do, only that they are not for the sound engine). I think not so long ago the docs were published on this forum.

Hi boreg.

Standalone is fine. It's the Vst version what never fully worked. It depends on the revision, but it never worked 100% in vst mode. Of course you can move a slider and the message is sent to the Virus and vice versa, you can automate parameters and they work. But there was always some issue that, at least on my opinion, made impossible to work seriously inside a sequencer.

Newer Ctrlr revisions (1600 and above) broke all my file handling, ruining the library and patch management of the panel, and there is no current fix, plus adding some graphical glitches.

Hi thetechnobear.

Yes, I did my own docs with OpenOffice, they must be somewhere on my backups. I'll take a look and will upload it here. But I don't have it in the form of Page/Parameter Number = Virus Parameter. I did a table with a patch dump and wrote down what each byte did, it's parameter and it's midi message. But I don't remember too much, this was done 2 or 3 years ago.

The docs I found online are mainly for Virus A, B and C. And there is another one that must be for some older OS of the TI, and they are completely different form the real sysex specs, and even with OS 5 Access added more parameters.

Anyway, you can check in any modulator of the panel the message it delivers. Open the panel in Ctrlr, enter Edit Mode and select a modulator. On the right of the panel there is a list of every parameter of each modulator, including it's sysex or cc message. Or you can change any parameter on the Virus and connect it to a midi monitor to see what the Virus sends.

But give me some time and I'll post here the midi specs.

You talked about writing an editor in Max. I tried to do it on Maxforlive, but on Windows it's not easy to use Ableton and sysex messages, and Ctrlr was much more easy to work with.

Finally I found the Sysex and CC parameter list I made of OS5. It's HERE. If you plan to write the editor, it will be helpful.

After many tests I've found the.exe and .dll options aren't reliable.

In order to work with it, the panel must be loaded in Ctrlr either inside or outside the sequencer, and only one panel. Inside the sequencer the parameters can be automated, but only for one part.

I've uploaded a new version fixing some bugs, this is the download page.

Ctrlr revision recommended: 1590.

Hi kwtsh.

Glad to know you can solve some of your sync problems with the panel.

Zitat

Some of the Panel GUI updates according to the Virus knobs and can see
the parameter changing in Live in real time as I change parameters on
the Virus TI, just cant figure out how to record it successfully in
Live, (automation arm enabled in session view). Any ideas anyone?

To record automation, just click the triangle in the Ctrlr device (next to "device activator" button), now click "Configure" button, and finally click on any parameter on the panel. You should now be able to automate them.

Zitat

Some areas of the panel unfortunately dont seem to respond to knob changes on the virus, r.g. Effects

The Arp section in the panel seems to have no effect, maybe missing
something? Changing resolution/octave for example in user pattern I cant
hear any difference in the arp sequence. Turn the arp off in the panel
and the Arp stays on, on the virus.

By default, Ctrlr only has 64 parameters ready to be automated (and ready to be sent to the TI). That's why you can only tweak the first 64 modulators. To change this you have to create a file in the same folder where your CtrlrVst.dll is located.

Create a new text file and paste this content inside:

Zitat

<?xml version="1.0" encoding="UTF-8"?>

<ctrlrOverrides ctrlrMaxExportedVstParameters="3000"
ctrlrShutdownDelay="256"
ctrlrUseEditorWrapper="1"
ctrlrLuaDisabled="0"
ctrlrLogToFile="0"
/>

Alles anzeigen

Parameter "ctrlrMaxExportedVstParameters" is the number of modulators that Ctrlr export to the DAW to allow their automation and transmission. In the case of the TI, a single part uses more than 550 parameters, so you should have a value enough for all the panels you could use in a project per Ctrlr instance.

The file must be named with the same name as the .dll and with extension .overrides (in my case, the .dll is named "Ctrlr-VST-Win32.dll", so the file I created is "Ctrlr-VST-Win32.overrides").

Zitat

I was struggling to get Live to send Midi Clock to the virus through the
panel, but managed to get that working over MIDI, so can now control
arp tempo by adjusting live's BPM on push. Nice
Trick there was to enable Output: Midi Virus (on Motu) to Sync:On,
Change Midi Menu 2/3 on Virus to Sync to External and the final piece of
the puzzle is to start the transport!! (duh!) so that the midi clock is
being sent from Motu over SPDIF to Virus. Arps now respond very quickly
when increasing the BPM in Live. But a BPM light on the Virus TI panel,
like the Snow's panel would be great

Alles anzeigen

As far as I know is not possible to send Midi Clock messages trough the panel . If you don't mind to complicate things a lot, you cold use two pairs virtual midi ports, one from Ctrlr and another one from Ableton Live and merge them in the physical midi output to the TI. The one from Ableton should carry the Midi clock message (not tested).

Zitat

You mentioned back in a Feb post that the panel is only single part. Is
that correct for the 4.1 build? I have three stereo analog TRS outs
coming from the Virus into my Motu and would be great to have multiple
tracks in Live for different timbral parts. Any way this can be
achieved?

Yes, the panel is single part and will be this way until Ctrlr developer adds some new functionality to allow a faster way to load a panel with thousands of modulators, something requested ages ago.
But as you are on Mac and have multi-client midi ports, you can open several instances of Ctrlr, each one with one TI panel assigned to different TI parts. This is something I haven't tested directly (because my midi interface is not multi-client and I can only use 1 Ctrlr instance), but I think to remember that I tested this with virtual midi ports and it worked.

Zitat

Using output 1/2 over TRS, but when I go to selected parts 2 or 3 of the
multi timbal part on the panel and they using outputs 3/4 or 5/6 they
refuse to work (and the cables are plugged in and fairly sure my routing
is correct!!) only 1/2 seems to output. When selecting the Out 1 L/R
MultiTimbral Part on the Standalone version the text "Multi Part
Parameter Output Selected" appears in the Virus Display inside the Panel
GUI, but note in the AU version selecting a different MultiTimbral
Part, e.g. Out 1 L/R the text that appears in the Virus Display inside
the Panel GUI seems to indicate another USB output has been selected.
(Remember I'm not using USB), they seem mixed up in in the AU version
and OK on the standalone. I've tried them all but can only get 1/2
outputs working single timbre.

Is there any way we can achieve a 3 part multitimbral live set using the Ctrlr Panel with the Virus TI?

Alles anzeigen

I think this is related to the previous question about not been able to automate/receive some of the panel modulators.
Another aspect is that the panel has been tested only with a TI Snow, with only 1 pair of analog outs. The list of values I have for the main out parameter is this:

Zitat

Main Out: F0 00 20 33 01 k1 73 k0 2d xx F7

xx values:

Off = 0
Out 1 L = 1
Out 1 L+R = 2
Out 1 R = 3
Out 2 L = 4
Out 2 L+R = 5
Out 2 R = 6
Out 3 L = 7
Out 3 L+R = 8
Out 3 R = 9
USB 1 L = 10
USB 1 L+R = 11
USB 1 R = 12
USB 2 L = 13
USB 2 L+R = 14
USB 2 R = 15

Alles anzeigen

If some one can confirm that the list is correct, please let me know.

Zitat

Options:

1) Multiple Panels inside Ctrlr, not flexible enough for me, prefer to be able to add effects and routing in Live.

2) Multiple tracks in Live with different panel instances loaded, e.g.
Track 1 : MultiTimbral Part 1, Track 2 : MultiTimbral Part 2 etc?

If your midi port is multi-client try what I answered above. Load a Ctrlr instance for each track.

A problem that comes to my mind right now using this method is that each instance is not communicated with each other. I suppose that when you open a panel with several instances of the panel, they will send the patch dump may be at the same time or not allowing to finish on dump and start with another, and this could cause a bad reception of the data. You should re-send the patches one by one once the project has finished loading.

The optimal method to make the panel is having all 16 parts loaded in one instance of the panel, like in VC, this would allow an ordered data transmission to the synth, but Ctrlr is not good with thousands of modulators.

Zitat von kwtsh

Is this a silly question? You discuss how to increase the MaxExportedVstParemeters. Is there there any harm increasing this to a larger number, say 10,000?

I don't understand why you ask if is a silly question, I think it isn't.

When a vst is loaded in a Daw, it must export a defined number of modulators to allow communication of those modulators with the Daw. In the case of Ctrlr, Ctrlr doesn't know how many modulators a panel will have, so it's impossible for Ctrlr to know how many it must export at loading time, and by default it exports 64 modulators. That's why you must create this file with a number of modulators to export best suited to your needs. This doesn't happens when you create a .dll of the panel, because the .dll version of the panel stores the number of modulators it has, but as I said in a previous post the .dll version doesn't work fine.

I don't know if a big number will affect the performance, I think it should not.

Zitat

As I'm on Mac OSX what should I call this file and where should I put
it? Is this 64 parameter limitation why the Effects section doesn't respond? How about the ARP section? Any chance of the list of the 64 Parameters that can be automated?
Should I expect adjusting the parameters in the Arp section of the panel
to change the playing Arp?

Read the previous post. Find in your vst/au folder the file Ctrlr-VST.dll (I don't know how it's called on Mac and where is installed, I'm on Windows). On Windows is installed by default in C:\Program Files\VstPlugins\Ctrlr 1590. Create the file in the same folder with the text I posted and with the name I indicated, and the next time you load Ctrlr vst inside Ableton it will export the number of modulators written in the file.

If you don't create this file, Ctrlr will export only 64 modulators, leaving the remaining modulators (almost 500) not communicated with the synth and with Ableton, so yes, Effects, Arps, Matrix and many more parameters will not work.

Zitat

I get what you mean about combining the panel and and Live's MIDI ports
together. Are there any advantages to this complexity that you can see?

This was only in the case you needed Midi Clock to be sent to the Virus, but If you have it synced there is no need to do it.

Zitat

I did try creating multiple tracks in Live each with controller
instances, but as each can only output on channels 1/2 it doesn't really
achieve 3 tracks playing simultaneously over MIDI, each tweakable as
they haven't been bounced to audio...if we can do that!! Wow!

Again, the output modulator will not work if you don't export more than the default 64 parameters. You HAVE TO CREATE the file. You can change the output in the panel, but the midi message is not sent to the Virus.

Zitat

Sounds like Ctrlr needs this thousands of modulators improvement, but
with they way it's released this will then mean it'll break Juce with
any panel over 1590.....:(

This is what a normal modulator looks like in a panel (xml)

<modulator modulatorVstExported="1" modulatorMax="1" vstIndex="14" modulatorIsStatic="0"
       	modulatorGlobalVariable="-1" modulatorMuteOnStart="1" modulatorExcludeFromSnapshot="0"
       	modulatorValueExpression="modulatorValue" modulatorValueExpressionReverse="midiValue"
       	luaModulatorGetValueForMIDI="-- None" luaModulatorGetValueFromMIDI="-- None"
       	modulatorLinkedToPanelProperty="-- None" modulatorLinkedToModulatorProperty="-- None"
       	modulatorLinkedToModulator="-- None" modulatorLinkedToModulatorSource="1"
       	modulatorLinkedToComponent="0" modulatorBaseValue="0" modulatorCustomIndex="0"
       	modulatorCustomName="" modulatorCustomIndexGroup="0" modulatorCustomNameGroup=""
       	modulatorVstNameFormat="%n" luaModulatorValueChange="OSC1_SubOsc"
       	name="OSC1 SubOsc Shap" modulatorMin="0" modulatorValue="0">
  <midi midiMessageType="0" midiMessageChannelOverride="0" midiMessageChannel="1"
    	midiMessageCtrlrNumber="35" midiMessageCtrlrValue="1" midiMessageMultiList=""
    	midiMessageSysExFormula=""/>
  <component componentLabelPosition="top" componentLabelJustification="centred"
         	componentLabelHeight="8" componentLabelWidth="0" componentLabelVisible="0"
         	componentLabelAlwaysOnTop="0" componentSentBack="0" componentLabelColour="0xff000000"
         	componentLabelFont="&lt;Sans-Serif&gt;;12;0;0;0;0;1" componentVisibleName="OSC1 SubOsc Shap"
         	componentMouseCursor="2" componentGroupName="" componentGroupped="1"
         	componentSnapSize="0" componentIsLocked="0" componentDisabled="0"
         	componentRadioGroupId="0" componentRadioGroupNotifyMidi="0" componentVisibility="1"
         	componentEffect="0" componentEffectRadius="0" componentEffectColour="0xff000000"
         	componentEffectOffsetX="0" componentEffectOffsetY="0" componentExcludedFromLabelDisplay="0"
         	componentBubbleRoundAngle="10" componentBubbleBackgroundColour1="0x9cffffff"
         	componentBubbleBackgroundColour2="0xbab9b9b9" componentBubbleBackgroundGradientType="1"
         	componentBubbleValueColour="0xff000000" componentBubbleValueFont="&lt;Sans-Serif&gt;;14;0;0;0;0;1"
         	componentBubbleValueJustification="centred" componentBubbleNameColour="0xff000000"
         	componentBubbleNameFont="&lt;Sans-Serif&gt;;14;0;0;0;0;1" componentBubbleNameJustification="centred"
         	componentValueDecimalPlaces="0" uiImageButtonMode="0" uiImageButtonResource="Virus2_SubOsc_Bt"
         	componentRectangle="38 65 39 35" resourceImageWidth="39" resourceImageHeight="35"
         	resourceImagePaintMode="36" resourceImageOrientation="1" uiImageButtonTextColour="0xff000000"
         	uiImageButtonContent="0&#10;1" uiImageButtonTextPosition="none"
         	uiImageButtonTextWidth="0" uiImageButtonTextHeight="0" uiButtonTextFont="&lt;Sans-Serif&gt;;12;0;0;0;0;1"
         	uiButtonTextJustification="centred" uiButtonRepeat="0" uiButtonRepeatRate="100"
         	componentEffectAlpha="0" uiButtonTrueValue="1" uiButtonFalseValue="0"
         	uiImageButtonTextFont="12.0" uiImageButtonTextJustification="centred"
         	componentSnapSizeAllow="0" uiButtonIsToggle="0" uiImageButtonTextIsOverButton="0"
         	uiType="uiImageButton" componentTabName="Global Tab" componentTabId="0"
         	componentLayerUid="6ed639c400000000b4ed120020e9917c"/>
</modulator>

As you can see, there a a lot of parameters that aren't needed when using images to draw knobs or sliders, almost the entire component section. I asked Ctrlr developer to create a new kind of modulator that will only store the modulator and midi section and the minimum info possible about the component part. It is just ridiculous waiting more than 10 minutes to load a panel for a 16 multitimbral parts synth with more than 10K modulators. Look at this post.