Zynewave's Forum Page

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

@rwelteroth wrote:

Hi all,

just received my korg nanokontrol2 and tried with the 3.10 beta. Played a bit around with the settings of the nanokontrol2 and now it works, using the “Live” setting (set marker/stop).
Only thing that I don’t like so far ist that the pan pots just work in an area quite close to the central position. I get to the left-/rightmost pan setting by just turning about a quarter to the left or right.
Maybe there is a way to scale the mapping of the pot.

I keep on testing and provide more info as far as I find out anything new.

Many thanks for testing.

1/ Are the nanokontrol2 pan knobs endless encoders, or do they have a fixed min/max position?

2/ Does the knobs adjust the pan positions differently if you turn the knobs fast or slow?

3/ Does the range of the knobs differ if you select the other DAW modes?

Some technical info on how the MCU pan works:

On the Mackie MCU the “V-Pots” are endless encoders with no “notch” in the dial, and they use a LED light ring around the knob to indicate what the actual value is. The V-Pots transmit standard MIDI control change values to the DAW, but the values are delta-ticks, and not absolute values. Podium collects the delta-values and calculates how much pan should be adjusted. It then transmits the resulting pan position back to the MCU V-Pot light ring. The Mackie MCU furthermore adjusts the transmitted V-Pot delta-ticks according to how fast the user turns the V-Pot. Turn it fast, and you can pan from left to right with a single hand movement. Turn it slow, and you need to turn the V-Pot 360 degrees several times.