Zynewave's Forum Page
Forum Replies Created
-
@thcilnnahoj wrote:
@Zynewave wrote:
Sure. Probably coming in 2.24.
Otherwise known as Podium 4.0! =P~
@Zynewave wrote:
– I think the ‘default track color’ setting is ready to be retired. With the default opacity settings, it messes everything up if you select anything but shades of grey.
Can you clarify?
Um, I’ll try, but I can’t guarantee that my explanation will make sense to you! 😆
For reference, example 1 has 2.23’s default color settings: overall color opacity 100%, track background opacity 20%, some random track colors and no default track color assigned.Before 2.23, you could select a default color and still override it when you set per-track colors, provided you set opacity to 100%.
Now, the strips are always colored, even if you set rack/header/strip opacity to 0. Even on higher opacity levels you don’t override the default track color but can only add various track colors to it instead. So you have a choice between all track backgrounds being pretty much shades of the same color (ex. 2, low opacity) or getting a real color mix (ex. 3, high opacity), like in previous versions, but coloring the whole strip this time. All in all very bright compared to the default settings. (Edit: It can of course be dark as well – I meant to say it’s quite intense.)
Setting the default color to a shade of grey is a little more useful, as you can make tracks appear generally brighter or darker, if moderately applied. (Edit: Sorry, this is of course not correct. It can be achieved by setting a lighter or darker shade of the panel background color! It’s just that I always use grey…) 😉
Thanks for the screenshots. You’re right. I made an experiment in beta11, where the opacity setting would fade into the default track color, instead of the panel color. That resulted in the fully colored track background in your screenshot. I’ve now reverted back to fading into the panel color. That makes the “default track color” still relevant, I think 😉
Btw. I’ve modified the default track coloring slightly in the new beta14, and specified a new default track color. Let me know if the new default colors present problems.
@LiquidProj3ct wrote:
This is the little piano roll bug I said before:
Best regards 🙂
edit: I’m also getting tons of freezes exiting podium, when the system ask if I want to save the project and I say ‘no’, around 1 each 3 times. I don’t know how to replicate.
That’s intended. Podium will scan how many octaves contains notes in the the displayed range of the sequence event, and then display this centered. In your sequence the second note is placed in the octave below the first note, so the display is offset with an octave.
Please let me know if you find a way to reproduce the freeze bug.
@thcilnnahoj wrote:
@thcilnnahoj wrote:
– Track headers don’t always show the same elements even if they’re supposedly the same height after using the ‘set default track height’ option.
It seems this happens because there’s a larger space between selector buttons and the faders when there’s an effect added to the chain.
Here are two tracks – only the second one has effects on it.
On the top row, they’re both at the smallest possible size where you can still see everything except the effect chain. On the bottom row, the additional space is easily visible after setting track size so that you get to see the controls on the second track too.
Thanks. Fixed in the new beta14.
There’s also a little extra space on the right side of the track headers, even when you disable vertical meters and the color bar. It’s more apparent now with the selection frame – it looks a bit strange that it doesn’t cover the whole header.
You mean the space for the horizontal drag bar? Clicking this will not select the track, so I think it would be wrong to extend the focus frame onto this bar.
@LiquidProj3ct wrote:
You’re right… did I tell you about the knob version where if you left click on knob you change its value and if you left click in the rest of the button you start a drag’n’drop operation? 😀
I think this is important, that’s the reason that i’m mastering MS paint 😀
Why do you think it is important; Is it only because you want to minimize the vertical space used by the current slider?
Whatever solution we can agree on, it will have to wait to a later release. I’ve stopped adding features to 2.23, and is now concentrating on bug-fixing.
The suggestions about having two different drag actions depending on whether you drag horizontally or vertically, will not be reliable unless you have a very steady hand.
@LiquidProj3ct wrote:
If you allow me, this is my idea of “sends” 🙂
Where you can send the signal to the send track in any point of chain
Good effort. But if clicking anywhere on the button will start a send adjust drag operation, do you suggest that it should not be possible to drag sends up/down in the chain or to other tracks?
@thcilnnahoj wrote:
@Zynewave wrote:
Unfortunately this behaviour is not very “touch screen” friendly. I’m not saying I’m going to change the entire Podium UI to focus on touch screen support, but I do think that touch screen operation will become more prominent in the future. So I keep that in mind when I design UI behaviour. Pressing on a touch screen will perform a click, and so you don’t have the usual mouse cursor you can move over controls to reveal more options.
Interesting! I don’t know anything about the subject – I imagined they’d have a way to recognize fingers hovering above, like graphics tablets do… just without a pen. So, would the “finger size” setting you mentioned resize buttons, mostly, or make the whole mixer absolutely huge? I can’t imagine it to be much fun to hunt buttons as tiny as they are now (and I have small hands).
The “finger size” setting would only resize the clickable controls. It will not scale the whole UI.
– I think it’s strange that effect chains are drawn in two different places depending on whether there’s a send track at the top of the chain. In my opinion it would be better if they were always placed in the same spot, and effect tracks would start to appear from bottom to top instead, like on track 1, no matter if there are send tracks already. When there are no effects, the + button would be placed just where the first effect track appears.
It would also fit the hierachy better if the chain was built bottom-up as opposed to the new effects being stacked on top pushing the others down. This also ensures that the group level of effect tracks is easily visible across all mixer strips.
I thought it important that sends are aligned, so that you can easily glance along horizontally to see how how much each track is sending to for example “Send 1”. Since sends are mostly placed as the last element in a chain, this requires that the chains are aligned to the top. I’m wondering if it would be a good idea to split the chain up, so that sends are aligned to the top, and effects to the bottom. :-k
This split would of couse not be done on chains where you place sends between effects.– The last thing that’s kind of missing now would be drag-rearranging of tracks in the mixer. It looks like moving tracks, especially to and from groups would be much simpler with the layout of the mixer. It is a little confusing sometimes in the tracklist, but I think the new way you proposed to display the group level there would help with that, too.
Coming in a future update.
