Zynewave@LiquidProj3ct wrote:
Could you set Tab key to rotate between profiles please? I only use two of them and for me have one key for both would be ideal 🙂
But the tab key is used to switch between open panels, such as the inspector listboxes, tracks region, embedded editor and mixer. I use that quite frequently.
Zynewave@thcilnnahoj wrote:
@Zynewave wrote:
That may distress users that still use the old layout with both the embedded editor and mixer in the same profile. What say the community: Reassign F6 to browser, and reassign F7 to either editor/mixer?
Over here! 8-[
Aww, I really have no luck, do I! 😆 Just as I’m about to say I’m happy with the round buttons you present me this.
I seriously do not like the profile bar… Still, I can see the results of this vote, so let me try to propose something: allow the user to assign F7 and F8 to switch to a profile of their choice. What good is the profile rotation currently assigned to F8 anyway now, with the profile bar and all.
How about this: F6 is browser, F7 and F8 are shortcuts for the first and second resizable region in the profile. Combined editor/mixer profiles will then still work. Numeric keys 1-9 are shortcuts for switching to a profile. Go, no go?
By the way, when you switch from a profile that has an editor profile bar to one that doesn’t while hovering the mouse over it, prompting the pop-up help, the help bubble gets stuck.
I’ll fix that.
And it would be nice if you could group elements in the region properties with ctrl/shift-click and move them up/down together. At the moment, it moves only the element last selected.
That made it into 2.21. Thanks for the suggestion.
Zynewave@thcilnnahoj wrote:
@Zynewave wrote:
@thcilnnahoj wrote:
@Zynewave wrote:
I’m now going to start on the main 2.21 feature, which will be a new track toolbar. In the default setup it will sit right below the navigator.
Hmmm, let me ask… Do you have anything else planned then for the big empty space right above the track headers?
No, not besides the display of the marker name, tempo, time-sig and scale info that is currently displayed there. You’re of course free to remove the track toolbar, or move it directly above the tracks region. I think the track filter feature will justify using up space for the new track toolbar, but I need to experiment with that.
That’s too bad… I’m just guessing here, but I think more users would like to have a few useful buttons there instead of the info text. At least I don’t think it’s that important. Then again, it might even be a bit of a problem due to Podium’s design, assuming that the whole horizontal line is one region and cannot be easily split…?
To allow controls belonging to a region to be overlaid on other regions will complicate the profile customization too much I think. If you use a profile that does not have the tempo/marker lanes, then the floating global solo/mute buttons may no longer fit. I also like the horizontal division of the elements, even if it means there is a blank spot here and there. I’ve seen screenshots of other hosts where it seems that every nook and cranny have been stuffed with buttons. This does not appeal to me.
The menu bar simply takes away from Podium’s aesthetics, but that’s just IMO. Auto-hide is acceptable, but will also take some getting used to.
For example, when I want to open the inspector/browser with the mouse, I usually move the cursor in a big motion to the upper edge of the screen, since it doesn’t matter if I overshoot the target there. Now I have to either be more careful and stop early, or move down a little so the bar can hide again – but not too far down, or the cursor won’t land on the button when the bar disappears… 🙄 It’ll be fine when you’re accustomed to it, but right now it’s annoying.
Also, I can’t stand it if everything that’s on screen just jumps around… That’s why I’m keeping only one timeline region instead of the default four – don’t like my arrangement jumping up and down all the time when switching on loop/punch modes.
If you don’t like things jumping around, then surely you could not have liked the placement of the menu buttons between the inspector and project tabs? The menu buttons would jump every time you opened/closed the inspector. Considering that, what other options are there than to put the menus at the top of the window? Part of my decision to do this is also the fact that most people are used to access menus at this location.
If you don’t like the auto-hide behaviour, then what’s the problem with disabling the option: That the fixed menu bar takes up too much space, or that you accidentally open the project menu where you wanted to click the inspector?
Zynewave@Conquistador wrote:
I think the “Search for missing plugins” command does not work. For some reason nothing happens when I use this command.
Looks broken. Please verify… :-k
Check your VST plugin paths in the preferences. If you have run the beta exe from a folder that has a VSTPlugins subfolder, then that folder may have replaced your normal VSTplugins folder in your Podium.ini.
ZynewaveI fixed a critical bug, so I have just released 2.21 a little sooner than planned. The track toolbar didn’t make it into this release.
ZynewaveZynewaveOuch!. I got the crash. It’s in the code for the UI rendering of the waveform, which I recently speed optimized. 😳
I’ll fix it and release 2.21 within a couple of days.
Many thanks for reporting this.
ZynewaveBeta5 is up.
Lots of small adjustments to the toolbar elements, like the file/edit/view and snap menus now resize properly to the full toolbar height.
Also added 0.5 second delay to the menu bar popup. This should eliminate the menu bar flicker that could occur when you missed your aim for the inspector/browser tabs.
ZynewaveSend me a minimal project file, with a description of the steps you take to start the recording.
Are you doing anything in the Podium UI when the crash occurs?
Zynewave@kingtubby wrote:
Is there a key shortcut to open/close the browser pane?
Not yet. F1-F5 opens the panels in the inspector, so I’m tempted to reassign F6 to open/close the browser. F6 is currently assigned to the embedded editor, and F7 to the mixer. The new default setup introduced in 2.20 no longer has both the editor and mixer in the same profile, so it would be cleaner to reassign F7 to open/close the first resizable panel found in the profile. That may distress users that still use the old layout with both the embedded editor and mixer in the same profile. What say the community: Reassign F6 to browser, and reassign F7 to either editor/mixer?
ZynewaveHmm, it’s difficult to keep everybody happy when changing the UI design.
Beta 4 (the anti-bean-button edition):
• The stop, play and record toolbar buttons are now circular shaped like most other toolbar buttons.
• Added “slice button” and “stretch button” elements to the toolbar dialog. Placing the slice element before or after a button will make the button side rectangular instead of rounded. Placing one or more stretch elements after a button will widen the button.
• Added an apply button to the toolbar dialog.
I don’t know if “slice button” is understandable. Let me know if you have a better description.
Zynewave@LiquidProj3ct wrote:
Thanks Frits, i wanted to mean the showing of menu bar, the hiding doesn’t matter 🙂
Ok, so it’s the opposite of what I thought you meant. Why do you want to delay the showing? Is it because you often accidentally move the mouse to the top when reaching for the inspector/browser tabs?
Zynewave@LiquidProj3ct wrote:
A minor request, please could you delay 0.5 seconds the auto-hide/show of the title bar? I think it would feel more solid 😉
I can delay the hiding of the bar. I don’t think it would make sense to delay the menu bar pop up. Btw. I’m now calling it “menu bar” instead of “title bar”.
Zynewave@LiquidProj3ct wrote:
@Zynewave wrote:
Beta2:
• Moved the browser page tab next to the inspector tab. Selecting either the inspector or the browser will automatically hide the other.Frits I’m not sure about this, but I honestly think that this new behaviour is a little uncomfortable. When you allow the drag&drop from browser to plugins it could be interesting have both, inspector and browser, visible. I know, you can open a new browser windows, but I don’t like work with floating windows. I liked more the browser at right, maybe you could consider keep it as an option.
My reasons for doing this:
Simplification. Having both the inspector and browser page tabs next to each other makes it easier to understand what they do, compared to the project/arrangement tabs.
Users have commented on the forum that they would prefer the inspector and browser to be one panel instead. With this new layout the two panels act like one panel.
I concluded that it is very rare that you would need to have both open at the same time. Furthermore it’s only on large screen resolutions that there is room to have both panels open at the same time.
Zynewave@Mike G wrote:
I would need to keep making the change everytime a new tweak to layout of podium happens and I run “reload setup”.
-Just thought the default setup could make better use of space.THinking about it I think it would make more logical sense (to me) for these buttons to be immediately after the view menu.
I have to design the default layout so that it fits within the minimum system requirement, which I have listed to be 1024×768. That means there will be some wasted horizontal space on the screens used by most users. My first thought was to have the profile bar in the edit toolbar, but someone commented that this was too far away from the editor and mixer panels. The position above the transport toolbar is where similar panel selection buttons are placed in other host software, such as Logic Audio.