Zynewave's Forum Page
Forum Replies Created
-
January 13, 2010 at 18:12 in reply to: Restricted to Podium license owners
ZynewaveKeymasterThis content is restricted to Podium license owners.
ZynewaveKeymaster@Conquistador wrote:
Screenshots as promised… 😉
This is with ClearType on. Reaper IMO has much clearer text compared to Podium here. I really do not know why Podium looks much less clear compared to Reaper :-k
Podium is on the left and Reaper is on the right. Look at the “Fabfilter Timeless” text for the inserts.

But if I switch off ClearType…can you spot the difference between the two applications “Fabfilter Timeless” text now? I can hardly tell them apart…below…

Podium is far sharper than the first image now that Cleartype is off and matches (maybe even goes further than) Reapers text for clarity in the second image. Quite a difference and quite easy to see IMO with those screen shots.
So Podium it appears benefits clearly from having anti aliasing disabled for certain areas (inserts on tracks and mixer strips) but anti aliasing is very helpful elsewhere in Podium that is why I think adding some kind of option to disable anti aliasing for the Insert, Source and Input buttons (just for the tracks and mixer strips) will solve this problem.
I hope that helps.
Thanks.
Anti-aliasing of fonts and other graphic elements are two different things. Podium uses its own anti-aliasing routines when rendering buttons and lines etc.
When it comes to fonts, Podium uses the default smoothing options selected in the OS, such as Clear-type. Podium uses the “Microsoft Sans Serif” font, which is the default Windows font used way back on the earliest Windows versions. Reaper probably uses a different font, since there are small differences in the letters at the small size.
I’ve done some experiments with alternative fonts. I also tried to set the small font to be aliased, while the normal font is anti-aliased, and frankly I think the two shown together looks horrible 😕
In a future update I’ll add the possibility for the user to select a custom font in Preferences.
ZynewaveKeymaster@H-man wrote:
At the risk of sounding like a broken record, would this be a good time to add the option of different colours (ie. lighter colours for darker themems) for the markers on the level meters?
Are you talking about the dark 0, -3, -6, -12 dB indicator lines within the meter? If so, would the solution be to use the configured text color instead of black to highlight the lines?
ZynewaveKeymasterMaybe some of the sound tools you have compared with apply compression to the output?
Otherwise I can’t see why Podium should have lower sound output. I have never experienced that problem myself. If you have the opportunity, try comparing with a different audio driver, or with a different soundcard.
ZynewaveKeymaster@LiquidProj3ct wrote:
Hi Mr Frits 🙂
Podium automation doesn’t respect the ‘-inf’ in my project:

The automation curve on the track is constructed from all the points that are within the range of the curve sequence events. The first -inf point you have highlighted falls before the start of your Level sequence event, and so is not included. You need to place the event snapped to bar 17.
ZynewaveKeymaster@thcilnnahoj wrote:
When you change the play/power color, the play cursor head still keeps the old one.
Fixed. Thanks.
ZynewaveKeymaster@thcilnnahoj wrote:
Edit: I guess it’s intentional, but why has the project information text below the recent projects box been removed?
The info text has not been removed. It’s just written with the same color as the background 😳
Happened during the color optimization. Now fixed.
ZynewaveKeymaster- Embedded plugin editors in the rack and mixer strips.
- Extended editing features in the zPEQ plugin editor.
ZynewaveKeymaster@thcilnnahoj wrote:
Heh, got another one for you. 😛
There’s a strange behaviour when Alt-clicking “overlapping” ghost notes: GIF animation (250 KB).
I don’t know about you, but I think it should always switch over to the note that’s visible as a ghost (brown one in the example), even if it means other notes occupying the same tonal space become unavailable as clickable ghost notes.
Too late =; . I am currently building the 2.24 release.
ZynewaveKeymaster@thcilnnahoj wrote:
I’m sure there’s a valid reason for this: Why does the hue still change when I try to get a color gradient simply fading to black or white?

I cannot help but smile of some of the “bugs” you dig up 😉
Achromatic colors (such as black and white) have an undefined hue value, so previously the hue value was set to a default value (bluish I think). I’ve now changed it so that in the case of achromatic colors, the hue value of the opposite lo/hi color is used instead.
ZynewaveKeymaster@UncleAge wrote:
@Zynewave wrote:
I’m going to revise the way that track heights are handled in a future update.
And when you do get to this revision, would there be a way to turn off the “squeezing” of the tracks region/arrangement area that occurs when the mixer or editor is opened? It would be nice to have an option that could turn that feature off.
I’d like the bottom window to give the appearance that its just sliding over the top. That way I can still have the topmost tracks still in view while making adjustments in the mixer. As it sits right now, when I open the mixer I adjust the track height for the track I am working on so I can see more clearly the events. Then when I minimize the mixer, the tracks are much taller then I would prefer. So I end up readjusting everything again.
If there is an option in the profile editors to turn this off I could not find it.
That is indeed one of the things I’m going to change.
ZynewaveKeymasterBeta10 is up, with the latest batch of bugfixes. This is hopefully the last beta. Unless you find some issues with this, I’ll make a release within a couple of days.
ZynewaveKeymasterI looked at the Dirac free sdk a while back, but I dismissed it for various reasons. Not being able to process a multi-channel file with phase lock of the channels is unacceptable.
I already have the basic components for a crude time-stretch and pitch shift. I made those when I implemented the zPitch plugin. The algorithm is similar to the one used in SoundTouch, meaning it is light in CPU use.
ZynewaveKeymaster@druid wrote:
Real-time adjustments… Does that mean that having a parameter track to adjust tempo could be possible? Not quite the same I guess; but I was wondering if making the engine work better for real-time adjustment was possible, perhaps the same edits could be used for tempo modulation? That would make slowing and speeding tempo up easier as then just a curve could be used.
I don’t think tempo changes would be on a parameter track. Maybe an extension to the tempo events.
ZynewaveKeymaster@druid wrote:
@koalaboy wrote:
I had a couple assigned, and then when I used the ‘selector’ in one, I assumed I could change the parameter that would be automated, keeping the actual data.
Instead, when I selected a parameter, it created a brand new automation track keyed to that parameter.
Ah! I think I’d noticed this before but had forgotten, due to my lack of action in the music sector recently (little earlier than recently).
I think this is a bit strange; if you change a “paramter” on the track itself, it makes more sense to swap what parameter that track is adjusting. On the other hand, you’d need an intuitive and easy to reach way to add a parameter track. Perhaps it was decided that this was a good way to add a specific parameter track? Still, I think I’d be more “familiar” with right-clicking on the parent track to add specific parameters, and then changing the parameter track itself would change that specific parameter assignment.
With that said, I’m not sure how often I’d change assignments, because usually if I have a parameter track, it’s because I want to change that one parameter. Also, I use energyXT VST so I use that to map VST parameters to energyXT’s own, meaning I could just load the VST and change the assignment in there (in fact, I’d have to).
I made the parameter selector create new tracks, because I reasoned that you would more frequently need to create new parameter tracks than reassign a parameter to an exisiting automation track.
Do others have an opinion on whether the parameter selector should create new parameter tracks, or reassign the parameter to the existing parameter track?
