Zynewave's Forum Page

• 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.

@Zynewave wrote:

@mezhick wrote:

Rewire doesn’t work (win xp sp3) !! Sad
I can’t see buses in devices section and rewire soft doesn’t start in slave mode (reason 5).

in version 3.01 everithing was fine…

I’ll do some testing. All I did was update to the latest Propellerheads ReWire SDK, with some minor tweaks to the Podium code. Maybe I overlooked something.

Done testing:

The new ReWire SDK (which supports both 32-bit and 64-bit) expects to find the ReWire.dll file in a different folder than the older ReWire SDK versions. The old SDK expects to find ReWire.dll in “C:WindowsSystem32”, where the new SDK expects it to be in “C:Program FilesCommon FilesPropellerhead SoftwareReWire”.

The latest Reason 6 installer will install ReWire.dll in the proper folder under Common Files, and Podium 3.0.2 will work as expected with Reason 6. If however you use Reason 5, the ReWire.dll is in the System32 folder, and Podium 3.0.2 will not be able to open ReWire.dll.

The Propellerhead ReWire SDK documentation recommends that third-party software that supports ReWire should include the ReWire.dll in their installers, but I think that is a messy solution. Whenever Propellerhead updates the ReWire.dll, there will be a large number of third-party installers that will try to install older ReWire versions. IMO a better solution would be if Propellerhead offered a free download of a dedicated ReWire.dll installer. That way third-party software developers can refer users to download the latest ReWire from the propellerhead website. Similar to how soundcard manufacturers offer downloadable driver updates.

If you are comfortable with using a file explorer, you can make Podium 3.0.2 work with Reason 5, by creating two folders and copying the ReWire.dll file:

Note that the “C:Program FilesCommon Files” folder may be different depending on your Windows OS language.

Create a new “Propellerhead Software” folder under Common Files.
Then create a new “ReWire” folder inside the Propellerhead Software folder

Copy the ReWire.dll from the folder “C:WindowsSystem32” into the “ReWire” folder you just created.

@rwelteroth wrote:

Hi Frits,

I sent you kind of a midi event log of a full left to right and back sweep of a pan pot on my nanokontrol2 via email.
Maybe you can use it for further optimization of the control surface support in podium.

Greetings
Richard

Thanks for the MIDI log. It seems that NanoKontrol pan knobs uses a value-range of 252. I don’t know why Korg chose this range instead of the more logical 128. Perhaps it is because other DAWs expect pan values in this range. Each delta-value message from the NanoKontrol changes the value with 2, so the knob resolution is in reality only 128.

I’ve uploaded beta2. Podium will now use the pan range of 252, when the device is not a genuine MCU. The NanoKontrol is probably the most populer MCU emulation device, and with a bit of luck, other MCU emulating devices also implement pan this way. I’d appreciate if you could test beta2 and let me know if pan on NanoKontrol now works ok.