Zynewave's Forum Page

• Extended zoom snapshots with options for partial recall of horizontal/vertical settings.
• Various improvements and bug fixes.

Topic: 2.41
Topic: 2.42

• Extended support for MCU compatible control surfaces.

Topic: 3.1.0

@rwelteroth wrote:

Hi Frits,

beta4 works (almost) as expected. The indicated channels can now be controlled by the respective channel on the controller no matter wether there are effects or not. Only the visible channels can be controlled. If I change visibility of channels for example by opening or closing a group channel, channel assignment is adjusted (ok at least to my needs).
Only thing I would change is that neither the master channel nor return channels can be assigned to the controller (or am I missing anything?). At least the possibility to control the return channels would be nice.
Maybe it’s alright for 3.1.0 right now but as you are currently working on this, some more improvements might be welcome and maybe also quite easy to implement (one idea that comes to mind here is the option to fix the master channel to controller channel 1 while assigning the other controller channels dynamically).

Greetings
Richard

Thanks for testing. Please try beta5. I’ve set the inclusion of master and bus tracks as default, and only if the device is a genuine MCU (with its own separate master fader) will the master track be deselected from the main faders. Track 1 should then be the master track on the NanoKontrol2. It won’t lock fader 1 to the master track, since this will stray too far away from MCU compatibility I think. Let me know if there are other minor issues that needs to be corrected.

@Klemperer: Thanks for testing. Good to know that Kore2 now works.

@rwelteroth wrote:

Create a new group track with one child track and automation of the level on the child track.
In the mixer, these 3 tracks can be controlled by the first 3 controls on the nanokontrol.
Add an vsti effect to the child track and the child track cannot be controlled with the respective control channel on the controller anymore.
Remove the effect from the child track and it can be controlled again.

Can anyone confirm this?

Confirmed. I’ll look into this tomorrow. I’ll probably upload a beta4 once I find out what’s going on. With a bit of luck, that will be the final beta before 3.1.0 can be released.

@rwelteroth wrote:

Hi all, me again.
Still trying with the beta2. Now, I’ve come across an issue that seems to be caused by the minimalistic design of the nanokontrol2.
Selecting tracks puzzles me. I have an arrangement with group tracks, audio tracks and automation tracks (track levels). Since they are quite many in total (41 audio tracks, a couple of groups, many automation tracks), I ordered the tracks logically and I select several track views via the track tags.
When the nanokontrol is active, the 8 tracks that are controlled by the controller are marked with the numbers respectively. The nanokontrol has buttons to select previous or next track group (8 tracks each). The tracks are selected for control no matter if the groups are expanded or not (so that unexpanded group members are controlled though they are not visible).
Some tracks have the corresponding number of the control channel but cannot be controlled using the fader and pan pot.
I understand that the sophisticated Mackie control offers the possibility to select several different operation modes, defining how group tracks and automation tracks are handled.
To my opinion, using some simple control like the nanokontrol should either be able to control just the visible tracks (i.e. the expanded groups and the tracks selected by the track tags) or each track no matter if selected and displayed or not. I have no right idea how to define a better control setup for simple hardware controllers right now but am willing to share my ideas in further development to improve Podium any further.

Discussion very welcome.

Greetings,
Richard

Thanks for the report.

Good point about the MCU tracks not matching what is visible on screen. I think I wrote the MCU code before I made a series of updates to the track hierarchy, such as the track tags feature, which explains why there is a discrepancy. I’ve now modified the mapping of MCU tracks so that they only map to tracks that are currently visible. I don’t see the problem with tracks not responding to fader/pan, but maybe that has been fixed with the changes I made in beta3. Please try the new beta3, and report if you still find unresolved issues.