Zynewave's Forum Page

Forum Replies Created

Viewing 15 posts - 1,591 through 1,605 (of 5,972 total)

← 1 2 3 … 106 107 108 … 397 398 399 →

January 5, 2010 at 22:10 in reply to: 2.23 #17229

Zynewave
Keymaster

@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.

January 5, 2010 at 22:02 in reply to: 2.23 #17228

Zynewave
Keymaster

@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?

January 5, 2010 at 21:48 in reply to: 2.23 #17227

Zynewave
Keymaster

@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.

January 5, 2010 at 11:43 in reply to: Preview 2.24: Embedded plugin editors in the rack #17217

Zynewave
Keymaster

@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. 🙂

January 5, 2010 at 11:36 in reply to: Scroll-wheel Tempo Adjust #17216

Zynewave
Keymaster

I 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.

January 5, 2010 at 11:33 in reply to: Wave Pitch editing? #17215

Zynewave
Keymaster

@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. 😉

January 4, 2010 at 23:51 in reply to: 2.23 #17209

Zynewave
Keymaster

@thcilnnahoj wrote:

Tiny aesthetics thing: If the track name is longer than the mixer strip is wide and it gets cut off, there is always still a little padding space on the left side, but not on the right.

Great. I’m glad to see it’s working as I intended 😉

How else would you want it to look? I’ve tried cutting the text off with the same border on the right side, but it does not look good when the text is abruptly cut in mid-air.

Only improvement I can think of is to truncate the text and append “…” to indicate the text does not fit. But I think there are a lot of things on my todo list that have higher priority.

January 4, 2010 at 22:35 in reply to: 2.23 #17208

Zynewave
Keymaster

@thcilnnahoj wrote:

Is it impossible to have the part of a line that’s editable (as in there’s an automation event present) be colored differently than the rest?

No, but that will require a bit more work than I planned to spend on it for this release. I’ll leave it as it is, and consider it for another release that deals with an update on track events.

January 4, 2010 at 16:22 in reply to: 2.23 #17203

Zynewave
Keymaster

@thcilnnahoj wrote:

Ahem… Not really a bug, but a little visual inconsistency, maybe:
As opposed to other events, the contents of automation events are not colored with the selection text color. Example: red active selection font color – the curve is colored ever so slightly with the track color (green).

Since the automation overhaul, the automation lines may of course be handled a little differently altogether.
By the way, why is it that pan automation events always display a “ghosted” line at the center position as well as the actual line? :-k

Edit: forgot to mention why this can become a problem!
If you use darker selection colors with bright text like I like to do, the selected event’s curve can become rather hard to see. And the same happens at the other end of the spectrum too, of course.

This is a bit tricky. The reason the color of the curve is not the same as the color of e.g. note events, is that the curve is global for the track, and not each individual curve sequence. The curve is also drawn on areas where there are no curve sequences, so the curve color cannot be based on the selection state of the curve sequence events. I’ve now changed it so that the color is based on the timeline fill/text colors instead of the track header colors. That makes it stand out more. But it’s difficult to prevent that extreme track event colors may make the curve line hard to see.

The thin base line for pan tracks just show where zero is. You’ll see the same line for pitchbend tracks etc. The purpose is to make it clear whether the automation is actually changing the parameter, or if it is neutral.

January 4, 2010 at 13:44 in reply to: Preview 2.24: Embedded plugin editors in the rack #17202

Zynewave
Keymaster

@thcilnnahoj wrote:

– I don’t see the point of the rectangle around the gain fader. If the size of slider/fader hitboxes is not obvious enough from the overlay box that appears when you hover the cursor over it, then all sliders would need a bounding box too (this is not a suggestion! :P). The problem I have with it is that the bottom edge will go right through the level markings, depending on mixer size.

I’ll remove the frames from the gain faders. How about leaving them on the parameter track faders? The reason I tried adding the frames was to try to emphasize the fader area. The gain fader is bordering up to the meter which helps with the separation.

– 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! 😯
Maybe the color selections could stay in memory and could only be written to file when you leave the UI color selection, by switching back to track color selection.

That must be because you have a track background image in the project properties? The original image is reloaded to apply the panel dye coloring. To avoid this Podium would need to keep two copies of the image in memory, which I think is a waste.

January 4, 2010 at 13:15 in reply to: Preview 2.24: Embedded plugin editors in the rack #17200

Zynewave
Keymaster

Thanks. The new beta9 should fix these color issues.

@Malcolm: You can load the “Colors – Default” setup to get the old colors back.

January 3, 2010 at 23:52 in reply to: Preview 2.24: Embedded plugin editors in the rack #17196

Zynewave
Keymaster

Beta8 is up.

I’m about half way through fixing the bugs reported in the 2.23 release topic. To mix up the tedious work of bug-fixing I took time off to make some nice changes to the UI coloring options:

Changed the layout in the Colors setup dialog and added new settings for button and slider knob colors.

The track inspector color picker can now be used to adjust Podium UI colors. Use the color picker right-click menu to select among the different UI colors. The available options matches the colors found in the Colors setup dialog.

Furthermore there are some changes to the “new effect” buttons in the mixer. I also made some UI speed optimizations on color change and resizing. Let me know if you find issues with color changes and UI resizing.

January 3, 2010 at 23:38 in reply to: 64-bit support #17195

Zynewave
Keymaster

I prefer to wait with this until I get a Windows 7 64-bit installation so that I can try out all the features of jbridge. I don’t know when I’ll order a new PC. I’m waiting to see what the verdict is on the new range of multitouch laptops that are about to come out.

January 1, 2010 at 14:37 in reply to: Arrangement snap settings stored per profile #17182

Zynewave
Keymaster

In a future update I could add an option that toggles whether the snap/tool settings are remembered by the editor or by the arrangement/sequence object (saved with the project).

January 1, 2010 at 14:33 in reply to: Extend Podium’s track hierarchy concept #17181

Zynewave
Keymaster

@UncleAge wrote:

From the OP:
@Mike G wrote:

…Uses for splitting MIDI…

1 – You could use it to have one midi input drive many “stacked” synths.

Is it possible in Podium to have the app be aware of which vsti’s/vst’s, (in use on the tracks) output midi and just add that group of instruments to the possible inputs at the track level?

I don’t understand your question. Perhaps you could rephrase it with a bit more detail.

As for the possibility to use one MIDI input to control stacked synths: That can be achieved by assigning the same MIDI input object to each of the synth tracks. You’ll need to use the “assign/copy to track” command by right-clicking the MIDI input in the the inspector input panel. You can also hold the control key while dragging inputs to assign/copy it.

Viewing 15 posts - 1,591 through 1,605 (of 5,972 total)

← 1 2 3 … 106 107 108 … 397 398 399 →