Recent Posts

Pages: [1] 2 3 ... 10
General Discussion / Re: Some controls on Komplete Kontrol Mk1 not recognized
« Last post by azslow3 on April 16, 2019, 06:42:19 AM »
These controls can send something with a "special integration" only. That requires bi-directional initialization from the DAW side.
I do not have the keyboard to test and NI has no public documentation.

So, theoretically it is possible to send required handshake from AZ Controller and so make Cakewalk recognized as at least partially "integrated". But practically that requires experienced is that staff person with the keyboard.
General Discussion / Some controls on Komplete Kontrol Mk1 not recognized
« Last post by Notecrusher on April 15, 2019, 09:14:00 PM »
I'm running the latest version of Cakewalk Bandlab, NI Komplete Kontrol Mk1 with latest firmware and KK software, and AZ Controller (3/15/19) with the MackieTransport preset. AZC has been setup according to instruction here, and the keyboard's transport controls control Bandlab nicely.

The 4 arrow buttons and large rotary on the right side of the keyboard are not recognized by AZC. When I press them with the AZC property page open, Last MIDI event doesn't respond.
General Discussion / Re: Problems with Komplete Kontrol Mk1
« Last post by Notecrusher on April 15, 2019, 07:37:54 PM »
Thanks, I found the solution in one of the KK tutorials. You have to click the little keyboard icon at the top of the KK instance you want to activate.
Accessibility tools / Re: AZ Accessible OSC (AOSC)
« Last post by azslow3 on April 15, 2019, 05:19:39 PM »
Using AOSC
Enable OSC in the TotalMix and AOSC configurations. Check that port numbers match. IP address should be set to in both programs, as long as you start AOSC on the same computer where TotalMix is running. In case you want audition peak level, set corresponding option in the TotalMix OSC settings.

Precaution. TotalMix and AOSC are not programs which you can use intuitively without knowledge about RME interface. Please read RME documentation or at least my introduction.

As full scale digital mixers, RME interfaces have thousands of parameters and it is easy unintentionally modify something. TotalMix support saving configurations into files, I recommend to use that feature so you can always revert to working preset when in trouble.

For all operations in AOSC it is essential to know currently set channel type and currently set submix. Submix is reported at several relevant places. Current channel type is not obvious, please use custom names for different channels and types, setting that in the Totalmix layout. Otherwise no matter how long you use AOSC, at some moment you will enable direct monitoring instead of changing output volume. I repeat, by default all channel types have the same names and parameters. But these parameter control completely different things.

Channel type.
When working with channel parameters, current channel type determines which channels you can control. That setting is global for the Mixer and Selected channel trees. You can check and change current type using buttons on the top pages of both trees. You also can use Shift+I,O,P shortcuts to switch channel type. Note that there is no audition for shortcuts, till currently selected element text depends from the setting. For example, if you was controlling outputs and switch to inputs and you are on the channel name in the tree, the name will only change in case you have set custom name for each channel type as I have suggested before. In case you are on not named by channel name element, for example  Volume slider in the channel page, you will not get any audition after the type change.

Except Channel input page, almost all parameters are current submix specific. Submix is a part of several elements in the tree, to remind you what you are changing.
Switching submix is a bit complicated. First select outputs, then visit Mixer/Submix select or solo page. Here you can select desired submix by checking corresponding channel.
RME has combined solo and submix selection controls in OSC. Solo make no sense for outputs since each output is strictly bound to one particular submix, so that submix is always in solo for the output. Inputs and playbacks are not submixes, but logically can be soloed within current submix.

Switching banks.
If you have Babyface you probably will never need to change channel banks, but for other interfaces you need to use bank switching to select the range of channels you need.
Use buttons in the top page of both trees or Ctrl+Shift+N,P shortcuts.

Switching channels.
In the current channel tree, you can use Ctrl+N,P to switch the channel you want to control. It is simpler to do this when on an element with current channel name, to get immediate audition which channel you have selected. Please note that final selected channel depends from the channel type and in most cases current submix. You can not for example switch from an input to playback for phone submix just using the channel switch.

Volume, mute, solo, pan and phase are submix specific. Please note they are controlling submix only, till you are using loopback submixes. The volume does not influence recording level in the DAW. The DAW and other software records pre-fader. Other way of thinking about that: input volume controls direct monitoring level, playback volume controls application volume, output volume controls hardware output volume.
Input gain, phantom power and pad exist for hardware input channels only and global. You can not set different gains for one channel in different submixes, each channel physically has only one pre-amp.
Loopback works for output channels only and feed that output submix as input for all other submixes and software.
There are many other parameter, what they are doing you can find in RME documentation.

Please note that not all RME devices have equal functionality. AOSC was designed for UFX, so it includes all available for it parameters. Many settings have no meaning for UC(X), Babyface and other smaller interfaces.
Accessibility tools / Re: AZ Accessible OSC (AOSC)
« Last post by azslow3 on April 15, 2019, 03:04:12 PM »
Mono and stereo channels
All channels in RME interfaces are mono. But 2 sequential channels can be combined into one stereo. That can be done in the channel configuration in AOSC using "Stereo" option.
Once set, the interface will count both channels as one and corresponding parameters, for example pan, will work as expected.

Note that stereo combining works separately for 3 major channel types. So you can set inputs 1 and 2 to be mono, combine playbacks 1 and 2 into stereo and set submixes 1 and 2 as mono. The later can be desired in case the interface has limited number of channels, for example Babaface Pro, and you need very sophisticated routing.

Routing examples
I want demonstrate several real life cases when flexible RME routing options can help.

Just a DAW with a screen reader on the same channels:
* No loopback, so all software inputs are corresponding hardware inputs.
* all submixes have just one corresponding playback at unity, may be with some input.  That mimics a simple audio interface without or with direct monitoring.
* the DAW and the screen reader output to the same software outputs, RME driver supports that independent from the driver models in use.

A DAW with a screen reader on different channels.
* the screen reader/windows sounds set to output to unused channels, for example ADAT3/4.
* ADAT3/4 playback is used to mix the screen reader into required submixes
In comparison to the first example, that allows to route the screen reader differently. For example, mix it with the DAW output into headphones submix but not into monitor submix.

DAW output to skype, with mic and with or without screen reader.
* DAW output is sent to ADAT3/4, screen reader to ADAT 5/6, skype output to monitors/headphones directly
* ADAT3/4 output set too looback, playbacks ADATA3/4 and ADAT5/6 are mixed into it, together with Mic. Also windows/screen reader playback, if desired.
* skype  input is set to ADAT3/4 software input, which is submix
* DAW input mic from its original analog input

DAW, skype, mic, screen capture, screen reader, headphone mix separated from the monitor mix.
* DAW output to ADAT 3/4, skype to ADAT 5/6, screen reader to ADAT7/8
* ADAT 3/4 and ADAT5/6 are set to looback, preparing mixes for the screen capture and skype
That configuration is most flexible, so mic, skype, screen reader and the DAW can be arbitrary mixed to compose monitors and headphones outputs together with  skype and screen capture inputs.

Note that described configurations are possible even with Babyface Pro and require no extra cables or software, introduce no signal degradation, work with lowest possible latency including direct mic and/or instruments monitoring with FX and proved to work stable.


Accessibility tools / Re: AZ Accessible OSC (AOSC)
« Last post by azslow3 on April 15, 2019, 02:18:50 PM »
RME audio interfaces
All RME audio interfaces are full scale digital mixers. Even in case someone is going to use one of this device just as a DAW audio interface, I strongly recommend to understand what device can do. That is not only essential  for controlling it without frustration. The device has solutions for many common problems, especially in Windows OS. In particular it can route your screen read output where and how you want, in parallel with skype, podcasts, etc.

RME user manual describes complete functionality of particular device, with all corresponding settings of TotalMIX application. The following has no chance to replace it. I have decided to write just a brief introduction to introduce terms used in AOSC.

Audio channels.
Simple audio interfaces have 2 channel types. There are hardware inputs and hardware outputs, both  are visible in software and inputs and outputs. In case of ASIO driver model, audio streams are bit to bit the same. So what comes from a hardware input is received by a DAW, what the DAW output is sent to the hardware output. Most interfaces have yet another option call direct monitoring. When used, a part of hardware input signal is sent to the hardware output, bypassing the DAW.

RME interfaces can be configured the same way. In fact that is the factory default configuration. But it can be changed using TotalMix and AOSC. There are more then 2 channel types:
  • hardware input. That is where a cable can be connected. Options fro hardware inputs, for example input gain, are gobal and influence all streams where the input is used.
  • software input. That is what a DAW, Skype or other programs see as an input. It can be corresponding hardware input or corresponding submix output. In both cases corresponding means from the same strip. So, software input 3 is hardware input 3 or submix 3. It can not be hardware input 5 or submix 1. I will explain submixes in a moment and give real world examples later.
  • software output. So when you select particular output in a DAW, screen reader or other program. In RME that is called playback channel. Note that for RME these are input channels. Yes, for the software they are output channels, but from a mixer perspective they are inputs. Also note they are completely separated from any other channel types and not bounded to strips, software output 10 can separately be routed to any submix, f.e. it can be at unity in submix 10, -20dB in submix 1 and muted for all other.
  • submix. At least RME call it so. More conventional will be a bus. All software inputs (potentially including other submixes outputs, that is why they are called submixes) and all playbacks are always mixed to any submix, so submix 4 can be a mix for hardware inputs 1 to 4, software outputs 8 and FX strip. Each submix is completely independent from other, if you let say add direct monitoring from input 1 to submix 4 that does not change direct submix 2. A submix can be set into loopback mode. In that case it is routed to the corresponding software input
  • hardware output. There is where you connect monitors, headphones, etc. Each hardware output carry corresponding submix. So submix 1 is is routed to hardware output 1 and so on

Channel types in TotalMix. While logically there are 5 channel types, RME interface expose 3 combined channel types. It is important to understand that different controls inside one interface type steer parameters of different logical channel types:
  • Inputs. That is a combination of hardware and software input parameters. For example the gain controls the hardware input gain, while volume controls software input volume in currently selected submix.
  • Playbacks. Software outputs, expliitly
  • Outputs. Submix, hardware output parameters and one software input parameter. For example the volume is for hardware output. Loopback is for software input, when set, this submix is used as software input, the routing in this case is explained in a moment.
In RME OSC design there is just one page with controls for any channel. And so in AOSC. That means all channel types have all possible controls, even in case they make no sense. For example the gain for a hardware output. Corresponding controls will simply not work. Most confusing is looback. It exists for intput channel, influence input channel but should be set in output channel.

Loopback and routing.
That is a bit tricky, so I want explain that in more details. In any particular submix corresponding software input is always the hardware input. For example input 1 always mixed as hardware input 1 into submix 1, independent from submix 1 loopback mode. Logically, if we mix an output into itself we will create a direct audio loop. That is always useless and bad.
But once a submix in loopback mode, corresponding software input for all other perpose is coming from submix, not from the hardware input. So in the last example, in case a DAW will record input 1, it will get submix 1 there instead of hardware input 1. Also do not forget that loopback should be set in the output/submix channel configuration, not in the input channel.

RME by default gives the same name for all channel types of one strip. Already a bit confusing for a sighted user, that can be a brick wall for accessible steering. In the TotalMix menu there is layout setting, where meaningful names can be given for each channel type separately. For example let say you use Mics on first 2 analog inputs, your DAW output is using the first 2 playback channels and your primary monitors are connected to the first 2 analog outputs.  By default inputs, playbacks and outputs will be named as AN1/2. So when you change the volume parameter for AN1/2 without renaming, you should keep in the head currently selected channel type to know what are you really controlling, direct monitoring, DAW output or hardware output. 
General Discussion / Re: Problems with Komplete Kontrol Mk1
« Last post by azslow3 on April 15, 2019, 09:17:00 AM »
What you describe sounds like a problem with Komplete Kontrol. I suggest you ask on Bandlab forum and/or NI directly.

Keys, transport and knobs in MIDI mode are routed throw the DAW. So DAW settings and plug-ins, including AZ Controller, can influence how that controls work.

Knobs in Instance mode are routed internally by NI, the DAW and AZ Controller are not involved.

What a DAW plug-ins can do is, taking a tip from particular instance automation parameter and currently selected in the DAW track into account, ask KK to switch into particular instance automatically. But that obviously is not going to work in case you can not switch manually.
Also such automation is possible, it requires a possibility to find KK for selected track (Cakewalk does not have such functionality to surface plug-in directly and AZ Control workarounds are not always working). And there should be a call to convert automation parameter value to instance, I guess AZ Controller should be modified to do this.
I do not have NI keyboard, so I can not test/develop such integration.
General Discussion / Problems with Komplete Kontrol Mk1
« Last post by Notecrusher on April 15, 2019, 12:26:08 AM »
I'm running the latest version of Cakewalk Bandlab, NI Komplete Kontrol Mk1 with latest firmware and KK software, and AZ Controller (3/15/19) with the MackieTransport preset. AZC has been setup according to instruction here, and the keyboard's transport controls control Bandlab nicely.

My problem is when running multiple instances of the KK container.

When I load two instances of KK in Bandlab, the keyboard keys correctly trigger the selected track and its associated instance of KK. On instruments that display a virtual keyboard, the virtual keys depress in sync with the keyboard. I can load an instrument and multiple FX in the first KK instance, and the keyboard's rotary knob parameters will update correctly based on the device I click in KK.

But I cannot get the keyboard's rotary knobs to sync with the 2nd instance of KK. The rotary knobs ALWAYS display and control instance 1's parameters, even when the keys are triggering instance 2.

According to the KK doc, you're supposed to be able to switch KK instances by pressing the INSTANCE button on the keyboard. When you press the INSTANCE button, a screen overlay is supposed to display a list of all your KK instances to allow you to select the one you want to control. But this doesn't work. A screen overlay does pop up. But all it displays is the text "MIDI MODE", an image of a midiplug, and beneath that, the text "Switch to MIDI mode".

Clicking on the midiplug image or anywhere else on this display does nothing. The keyboard parameters remain stuck on the first instance of KK.

I have tried clicking the other buttons on the keyboard, including SHIFT+INSTANCE, as well as everything I can find to click in the KK property window of the 2nd KK instance, but nothing I do will get the keyboard rotaries to control the parameters of the 2nd KK instance.

Is there a way to configure AZ Controller to handle KK instance switching?
Wishes / Re: Behringer X32 OSC
« Last post by icw on April 11, 2019, 04:58:00 AM »
I would be glad to test and report back. If we can get integers to work, I think select button could set state channel then have unused button arm track and change the scribble strip color to give a visual of armed tracks. That would be really helpful.
Wishes / Re: Behringer X32 OSC
« Last post by azslow3 on April 02, 2019, 10:24:58 AM »
Yes, that is why I have mentioned incomplete OSC. AZ Controller does not support INT parameters in OSC at the moment. Colors is a different story.

I do not have X32. But since it seems like you are serious about using it, in case you promise to test and report if it works, I can try to extend AZ Controller to support
missing features.
Pages: [1] 2 3 ... 10