buendiainside.
michi_maksome feedback given – no functionality gained – development has slowed down considerably …
tayfuni really love podium but i wil left it for the control surfaces support.
in my opinion developers should make mapping unite like other Daws and source code publish in internet for the free version. if souce code will publish, development will be accelerated.
make coding with one person is very difficult for the development.People always ask you to do better and keep up with requests for a single person will be very tiring.
SlomoYeah, publish the source code so you can remove the limitations of the free version, and make it a full version. What an excellent idea. Will most likely not happen.
@michi_mak, with the feedback you provide, the developement could come to a halt.
michi_mak@Slomo wrote:
Yeah, publish the source code so you can remove the limitations of the free version, and make it a full version. What an excellent idea. Will most likely not happen.
@michi_mak, with the feedback you provide, the developement could come to a halt.
if you say so ❓
SlomoWell, I do say so.
Here you have both the controller and the beta installed, a great opportunity to do some beta testing and provide good feedback to propel the development forward, but for some reason you choose to not do that. Too bad…
michi_maki never applied as beta tester – so i don’t feel like beta testing!!!
i’d be happy to use Podium on a regular basis but there are too many issues left…
SlomoYeah, I am sorry, I know. Beta testing takes skill, and not everybody has that.
So you have to excuse me. I am so used to be surrounded by creative and skilled people, who make things happen, that I forget that the opposit exists as well. My bad.
Zynewave@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.
KlempererEdit (just had written here, and afterwards a “grounding of my KORE2 hardware ended the “zig zag” I have had for long – other tryings were in vain for months, this must be my lucky day^^)
the new beta and Kore2 as Mackie-universal-controller seems to WORK!!
Just loaded beta3, chose Kore2 (which is nearly discontinued now after NI built all their products around the controller, which is a shame, but there are a load of Kore users around) as control surface.
And it works! Kore users just have to activate Kore2 as midi controller (“Mackie control” mode) – and voilà!
I had not much time to look into it further up to now, but it works just like you’d expect. Wonderful, Frits!!! knob 1 of Kore2 is, if I don’t configure Kore2 hardware else, master vol, 2 is track 2 vol, any parameter I choose works right like expected however you like to configure Kore.
That would be GREAT news for me! I’ll report problems if I find some, and I already wrote a mail to another Podium user who in the past liked to see Kore2 support for Podium. Maybe he’ll test and write here too, at least I told him about the news 🙂
This indeed would be SUPERB, a feature I have waited for since a long time, as the auto-detect did not work for Kore2 hardware.
As the Kore is discontinued you would not want to work hard if any Kore-only-problems were coming – but as I said, there are a lot of Kore2 users, and maybe they should know it is working now…It will be updated for 64bit and a few bugs will be ironed out, after which it will be discontinued because they hype their “Maschine” now.
Thanks a many many times and more, Frits, do you want some german self-made cakes (of only the first quality of course, done by me around midnight many days) in return 😀 😀 (delicious, makes coding a bit more fun, and I already send some to Sverige next week 😆 A short pm and an address, and I’d send them straight from Hamburg, I am really happy, Kore2 works after 2 zigzag years and getting dusty, and Podium supports it now!! )
rwelterothHi Frits,
thanks for beta3.
Gave it a try and can report that assignment of visible tracks to controller channels works much more obvious now.
But I still have a problem with certain channels not responding to controller movements that can be easily reproduced like this:
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?
Frits, is this of help for more bugfixing?
Greetings,
Richard
Zynewave@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.
ZynewaveBeta4 is up. This should fix the problem with faders/pan knobs not responding on some tracks. Please report if there are further problems.
rwelterothHi 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
MelodyManAre cheaper controllers like the Presonus faderport also supported?
Zynewave@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.