Zynewave.
aMUSEd@Zynewave wrote:
Hmm, 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.
Glad you added those because I liked the stretched versions (beans) but the rounded version looks measly.
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.
LiquidProj3ctThanks Frits 🙂
thcilnnahojAhh, the menu bar delay just doesn’t agree with me…
If it’s not too much to ask, I’d appreciate if it was optional (maybe in a right-click menu on the auto-hide button). I’d rather improve my aim a bit than having to wait! 😛
Also, the mixer menu (formerly known as view) button is missing its label when ‘show control buttons’ is activated.
H-man1. I really like the way that the Inspector and Browser windows store/remember their window size.
2. I’m a Bean-Button man …who would have thought?
3. Let’s have at those new track toolbar features! 😈 😛 😈
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.
Conquistador@Zynewave wrote:
I 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.
I really hope it makes it into 2.22. Your initial description of this feature sounds promising. Too early to draw any real conclusion as we have not seen it yet. But if it can simplify track management a bit more in some way or the other it should be a useful addtion to Podium.
This does sound very promising indeed now that I have just read it again… 🙂
“…track toolbar. In the default setup it will sit right below the navigator. I’m considering several new toolbar elements, such as: New track, Marker lane toggle, Tempo lane toggle, global bounce/solo/mute/record buttons, and a new “track filter bar” which will behave similar to the 2.20 editor profile bar.”
The whole Editor Bar style presentation is sooooo efffective.
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@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.
LiquidProj3ctCould 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 🙂
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.
LiquidProj3ctummmmm ok 😉
thcilnnahoj@Zynewave wrote:
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.
Well, I wasn’t directly looking at those buttons most of the time, but at the arrangement! 🙂
I don’t find one location for the menu buttons more obvious than the other. Podium never looked like a program that uses the Windows default layout to me anyway… Insofar it didn’t really bother me where they were placed.
Is it just my imagination, or is there a little more space between the tabs and the upper screen edge now? I could’ve sworn I was able to click on them while the mouse cursor was at the very top of the screen before.
@Zynewave wrote:
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?
Sounds great – by all means, go! 🙂
Zynewave@thcilnnahoj wrote:
Is it just my imagination, or is there a little more space between the tabs and the upper screen edge now? I could’ve sworn I was able to click on them while the mouse cursor was at the very top of the screen before.
There are now 5 pixels space. Previously there were 2 pixels from the top to the page tab, so clicking on the first two pixel rows did not hit the page tab.