Zynewave@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.
ZynewaveZynewave@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.
Zynewave@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.
Zynewave@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.
ZynewaveBeta10 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.
ZynewaveI 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.
Zynewave@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.
Zynewave@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?
Zynewave@koalaboy wrote:
Could the ‘default height’ of a parameter automation track, perhaps be made a little smaller at the default zoom ?
I’m going to revise the way that track heights are handled in a future update. Meanwhile, you can use the “apply track lane height” right-click command to set a default height for all parameter tracks.
Also, when a track is expanded in height, the selectors seem to pop-in in blocks… could they pop-in one at a time as the height allows ?
I don’t think it is a good idea to show a partial effect chain. You would then always be unsure whether the displayed chain is truncated.
Zynewave@thcilnnahoj wrote:
“Sir Bugalot” has another fiendish bug’s head on his lance to serve as trophy on the walls of King Fixalot’s castle! 😆
There’s a selection/key focus problem concerning tempo and marker events.
In this example GIF (245 KB) I try to select and delete a tempo event with the DEL key on the keyboard whilst different editors have focus.– First with focus on the arrangement editor – works fine.
– Then with focus on an “empty” embedded editor – here the tempo/marker event doesn’t become the active selection but still gets deleted, probably since there’s nothing else selected in the empty E.E..
– Focus on the embedded editor – works fine as well.
– And lastly, focus on the mixer. The event is not set as the active selection here either, and so it actually deletes the focus track in the mixer instead! :o)
It is on purpose that pressing delete with focus on the mixer will delete the track, even if there is an event selection. What do you recommend should be done: Should delete in the mixer delete any event selection, even though you may be on a mixer profile without a timeline and tracks region? Should clicking in the tempo/marker lanes force focus to the tracks region, removing focus from the mixer/embedded region?
Zynewave@thcilnnahoj wrote:
– Bouncing tracks that have no effects naturally leads to an empty track being created to hold the bounce event. However, this track is still labeled “Effect” (greyed out) in the mixer, even though “use name of device assigned to track” is automatically selected for bounce tracks in the track properties, and thus the track would actually be named “Bounce.”
It’s a little weird like this – I can’t think of a reason the mixer/rack selectors shouldn’t use the track name setting… Are names on effect tracks even used anywhere at the moment (apart from unhidden effect tracks, which you said are on their way out)?
I’m going to clean that up eventually.
– Is there a reason for the velocity buttons in note editor, point type buttons in curve editor and channel select buttons in sound editor to be aligned to the left instead of to the right?
If they were right-aligned, they would cover the value markings. I don’t think it would look good if they were aligned in the middle just left of the value markings.
Zynewave@UncleAge wrote:
@thcilnnahoj wrote:
– It seems the “live” color selection on the color picker constantly writes to the hard disk (podium.ini?) – I can even hear it scratching away! 😯
I don’t know about writing to the HD but moving the color selector around created some pretty big spikes in the cpu preformance meters according to the TaskManager. No biggie as long as its not adjusted while playback is going on.
I have already made extensive optimizations to the color updating. There are a lot of stuff that needs to be computed: Each pixel in texture bitmaps must be converted from RGB to HSL, hue/luminance adjusted, and then converted back to RGB. Buttons must be algorithmically rerendered with the new colors. Various UI elements that are cached in bitmaps for speed efficiency must be recreated. And so on. I don’t recommend you adjust colors while you’re recording. 🙂
ZynewaveI had made some tests with real-time adjustments of tempo, but I need to make some modifications to the engine to make it smooth. It probably will come in a future update.
Zynewave@UncleAge wrote:
Frits, is zplane one of the alternatives that you have considered? I for one would be willing to throw a bit more do-re-mi in the pot for something like this
Last time I had contact with zplane, they listed an annual license fee of about 3000 US$. That’s a lot of do-re-mi. 😉
