@Zynewave wrote:
It already has a semi transparent handle on both sides. You’ve mentioned this quite a few times now, but you’ll have to create a mockup image so that I can see what you are suggesting.
EDIT:
Sorry I should have mentioned if the project is zoomed out you cannot see any handles…I have added a the mock up in a later post on this thread. I somehow thought I was posting a new reply when I was infact editing this post. #-o
Markus, whether you like it or not, paying someone some donations, then asking for some things, then getting angry when they don’t do them, looks very much like paying to get service. That’s not the service Frits offered, as far as I can tell. You’re being incredibly rude in the way you respond, and incredibly offensive in the way you expect to be heard and demanding attention. Language barrier or not (and in this case, not, because it’s emotions, not just slight word differences), there are boundaries beyond which it is rude and arrogant to act, and you have crossed them a few times now, especially with your most recent outburst.
I am sympathetic with you for not getting much response to what you like; that’s a bummer, but no one gave you a RIGHT to say how things should be. Frits might put some people’s suggestions in because they match what he wants for Podium, or it might be a reasonable compromise. Not all suggestions are equal in terms of what relevance they have to the update that Frits is planning.
You say the customer is always right, but the customer is not always right. And what companies bow and put any customer’s suggestions in? Cubase, Sonarand ProTools? No they don’t. If they did, they’d put a feature in one time, take it out the next, and god knows what after, because people want different things. No company does whatever the customer says. What good ones DO do is, have a vision, a goal, or idea of what to do, and take feedback from users, and use that feedback to further what they chose to do. That’s what Frits is doing, and mostly doing it quite well. Your demands (because they aren’t suggestions, they are demands, or you wouldn’t be angry when they aren’t done) are not customer being right, but customer trying to dominate.
Naturally, I can only speak for my own opinions, and I might be wrong about what Frits thinks and/or does, but I think I have the general gist of it correct.
I’m sorry everyone, but I had to have my say here (wrong thread, I know, but this thread was where the posts I’m referring to occurred). I have been feeling highly offended by some of Markus’ posts since he arrived; I don’t want you to go Markus, but I would greatly appreciate you keeping your tone civil and pleasant. I am by no means a forum administrator, of course, but it grates on my nerves when a person is unreasonably angry over something for no good reason.
I removed the scrollbar to save space. The navigator is essentially a scrollbar, only it shows a miniature of the timeline data in the background. To me it seems pointless to have both a navigator and a scrollbar in the same editor.
Ok… I see your point here. The similarities with a horizontal scroll bar and the opportunity to save space. Nothing wrong with that makes sense. However… 🙂
Part 1
1.Constant mouse scrolling up to the top of the UI for a simple horizontal scroll.
If the mixer or editor is not visible when working in Podium there is plenty of space for at least 5 or 6 tracks to be visible and for one to edit parameters, move objects around e.t.c and see those 5 or 6 tracks zoomed in clearly. But if you then want to simply horizontally scroll the project, if you are working on the bottom three tracks you have to drag your mouse all the way to the Navigator at the top for a simple horizontal scroll. Also you have to carefully get that double arrow to show up first to grab on the Navigator edges. Its simply far easier with a horizontal slider instead.
2.Flexibility and usability gains.
Horizontal scrolling is now effectively locked to the top of the UI to save space currently. A very small amount of space. Compare the vertical space the Navigator takes up with a horizontal slider that will move up or down as the bottom of the arrangement is pulled up or down. Allowing you to scroll horizontally from the middle or bottom of the UI.
So you lose huge amount of flexibility to save a really small amount of space.
Part 2
3. Space saving: Navigator vs. Horizontal scroll bar
a.The Navigator itself takes up *far* more space than a horizontal slider. 5 or 6 times as much space to provide essentially the same feature (horizontal scrolling).
b. If anything Frits I would suggest reducing the default vertical size of the Navigator. It does not have to be quite so big veritcally by default. You could easily reduce its size a little, add the horizontal slider as a default and still have the exact amount of vertical UI space we have now in 2.20.
c. The slider takes up hardly any space at all while providing a far easier way to horizontally scroll a project and avoid constantly moving your mouse up and down a project *every single time* just to scroll horizontally . The tiny amount of space you lose with the slider is far outweighed by usability gains.
Your losing a good deal of flexibility by removing it just to save so small an amount of space. That space is being put to extremely good use with a horizontal slider. It has worked perfectly well that way for years with Podium.
4. Workflow.
If a user always scrolls his project horizontally from the top of his arrangement then its 100% fine. But I cannot believe everyone here works that way. I am not the only one that requested the return of the horizontal slider on this thread.
Summary
I can’t see why I would use the Navigator when a simple horizontal bar will let any user scroll quickly from the middle or bottom of the screen much more easily. Navigator for a quick zoom to see the whole project or to veritcally move up or down the arrangement yes. Its ideal for that. But not as a full replacement for the slider. Please do reconsider. We are of course not talking about a bug here or something that is stopping anyone from using Podium (far from it). But still.
Its great you asked about UI enhancements but in a strange way in this case one perfectly good UI enhancement seems to be taking the place of another perfectly good feature. :-k The Slider Bar and the Navigator together compliment each other by offering far easier and more flexible way to navigate PDM, they do not even nearly clutter up the UI IMO the sliders vertical UI space really is tiny. See point 3b again to see what I mean.
HTH
@thcilnnahoj wrote:
Add a default track color to the default setup color settings. Grey events/notes on grey background are not the prettiest thing to look at, and totally new users might be turned off. The coloring feature could be nicely displayed if all tracks were colored already, and it would also automatically activate the color picker in the inspector, which you can’t miss then on opening your first project ever.
Very easy to do and would help, in my opinion. Even if you set the same gray as the default color it would at least still show the color picker. Otherwise the track coloring options might be a bit too deeply buried in menus for new users to pick up.
The problem with setting a specific color for new tracks, is that it can conflict with the users color scheme. The color could accidentally be the same as the color the user has defined for the background or the selection. When a color is not defined for the track, it will use the “default track color” specified in the color scheme, which should ensure that the color matches the color scheme.
Edit: Hang on, maybe you are just suggesting that the “default track color” option in the colors dialog should be enabled in the default setup? In that case it would not be a problem, and new tracks will have the track color picker enabled by default.
@thcilnnahoj wrote:
Very nice! 🙂
Even though you say shop’s closed, I’ll quickly try and pitch this one again, on the off chance that you missed it:
Add a default track color to the default setup color settings. Grey events/notes on grey background are not the prettiest thing to look at, and totally new users might be turned off. The coloring feature could be nicely displayed if all tracks were colored already, and it would also automatically activate the color picker in the inspector, which you can’t miss then on opening your first project ever.
Very easy to do and would help, in my opinion. Even if you set the same gray as the default color it would at least still show the color picker. Otherwise the track coloring options might be a bit too deeply buried in menus for new users to pick up.
Hmmmm you know what? this is an excellent observation IMO. If you can sneak this into 2.20 Frits it would be great. Its a very good observation and suggestion from thcilnnahoj nice.
@Zynewave wrote:
The problem with setting a specific color for new tracks, is that it can conflict with the users color scheme. The color could accidentally be the same as the color the user has defined for the background or the selection. When a color is not defined for the track, it will use the “default track color” specified in the color scheme, which should ensure that the color matches the color scheme
Good point Frits.
What about at least making this change for the default set up so that new users / demo users who surely would not have set up their track colours e.t.c could get up and running with the colour picker which they might not see as quickly otherwise?
The thing is that new tracks have track colour turned off, which means that the colourpicker in the inspector doesn’t show.
Just switching the colour checkbox on for new tracks would be an improvement.
Also: you could still set it to the default track colour of the colour templates. I mean: all colours set by the user are known by the program, so it should be possible to determine good track colours from those, or at least make sure the new track colours are sufficiently different from certain colours specified in the colour scheme. (allthough this will probably be harder to implement than just changing the default state of a checkbox)
@Zynewave wrote:
@LiquidProj3ct wrote:
Hey Frits, this is a bug (I think it’s a bug) present in olders Podium version also, but I didn’t know how replicate it, now I do know. The bug is that sometimes you cannot delete selected clip in arrangement view with SUPR key (DELETE).
Create any clip in any track, and edit it (add notes/audio/…). Then rotate between profiles with F8 until you reach again the original profile. now try to erase the clip with DELETE/SUPR key, you cannot.
Got it!. Fixed. Thanks.
Way to go LiquidProj3ct! I spent quite some time trying to replicate this bug without any success.
Top effort! 😀 😀 😀
@Zynewave wrote:
It already has a semi transparent handle on both sides. You’ve mentioned this quite a few times now, but you’ll have to create a mockup image so that I can see what you are suggesting.
Ok…here is the mock up…
These small handles could be visible on both sides of the Navigator. Even when the arrangement is fully zoomed out. That is what I have been trying to say. 🙂
The current handles do not show up when the project is fully zoomed out.
HTH
@Conquistador wrote:
@Zynewave wrote:
It already has a semi transparent handle on both sides. You’ve mentioned this quite a few times now, but you’ll have to create a mockup image so that I can see what you are suggesting.
Ok…here is the mock up…
These small handles could be visible on both sides of the Navigator. Even when the arrangement is fully zoomed out. That is what I have been trying to say. 🙂
The current handles do not show up when the project is fully zoomed out.
HTH
I have to agree. Unless one thinks instinctively to mouse-wheel on the Navigator, there is actually nothing to indicate the features within.
edit: Apart from the tool tip of course 😉
I might just suggest that the zoom scale be changed so that more of the existing handle is shown ‘when zoomed out’, however the arrows suggested by CQSD provide a little more information to the user.
The obvious problem is that half the time the arrows would be pointing in the wrong direction :P.
@Zynewave wrote:
The problem with setting a specific color for new tracks, is that it can conflict with the users color scheme. The color could accidentally be the same as the color the user has defined for the background or the selection. When a color is not defined for the track, it will use the “default track color” specified in the color scheme, which should ensure that the color matches the color scheme.
Edit: Hang on, maybe you are just suggesting that the “default track color” option in the colors dialog should be enabled in the default setup? In that case it would not be a problem, and new tracks will have the track color picker enabled by default.
Well, the problem you mentioned would still be there (if a user saves his project made with default colors and then loads a color setup that uses this exact grey) but for now, I think taking this small risk is better than leaving new users in the dark.
A deeper look into the coloring system might be a topic for another far off day. 😉