Conquistador.
Zynewave@acousmod wrote:
There is also a bug : when I resize an event, the length of the fade out changes !
It is shorter when the event is long and longer when it is short 😯
For example :
– the event is 60 seconds long
– I make a 10 seconds fade out
– I shorten the event to 20 seconds by dragging the right handle
– the fade is longer on the timeline (about 15 seconds)
– the numeric fade value is always 10 seconds but it lasts more
Or try to drag the right handle of an event : the fade out becomes shorter and disapears.
On the other hand, the fade in is stable.
I’ve checked your project file, and the problem happens because you play a 44k1 sound file in an 48k arrangement. One of the next major things I am going to look at is sample rate conversion. The implementation of this feature will fix issues like this one. You sent me a project a while back where you had a problem with curve sequences that did not align when being merged. This turned out to be a similar problem where the curve sequence used a different time resolution than the arrangement. This could have happened if you dragged the curve sequence object between arrangements that used different time resolutions.
So my advise for now is to make sure your sounds are the same samplerate as the arrangement. I’ll solve the time format issues when I start on SRC/timestretching.
ConquistadorThe fades look classy. Very classy. 🙂
The fade curves and the horizontal line.
Even when the waveform will reflect the sound amplitude, it is important to know at a glance if it is the original amplitude or if it is due to an event setting.
Like Max says, it would be nice if it is a global option.
Easily my biggest problem with the current fade implementation. One must be able to see at a glance what the state of each event in a project is regarding fades, essential IMO.
At the very least being able to view fades even when the mouse is not over an event, should be made optional. ❗
Great feature, it just needs a little more refinement. 😉
Currently when splitting an event, the two new events are assigned the same fade-in/out settings as the original event. Would you prefer that a split should always set fade-in/out to zero, or would you want the possibility to define the default fade times for splitting?
I think this should be optional.
The curve is updated as soon as you tab away from the value input field. You can also click and drag horizontally in the upper and lower halfs of the curve graphs to edit the curve values.
This does work and can be very effective at getting the desired curve but I think being able to make that sort of change to a curve on the clip itself would be far quicker. So…Fade properties for a bit more detail but quicker and more immediate results should be possible as you put it, if you were to…
“click and drag horizontally in the upper and lower halfs of the curve graphs to edit the curve values” but on the clip fades on the clip itself is the suggestion here, as well as the existing Fade properties horizontal drag action.
Also another problem I have is yet again the colour of one area in Podium is linked to another. In this case the fade hit points are linked to one of the existing colour settings in Podium. I really think this needs to be looked at again, please Frits. It is a real problem trying to balance colour settings to fit every area in Podium now. It should be something you simply set and forget.
Not asking for some sort of advanced colour palette here, don’t get me wrong, but there are many areas that really should not have the same colour setting in Podium. A few additional options would go a long way. Just a few.This problem is getting worse IMO.
Also I think it would be great to just right click on a clip to get a simple choice of fade shapes as in ACID. Very quick and simple.
For one developer I think it is a superb effort overall Frits. Really. Just some details that still need adjusting.
ConquistadorJust to clarify what I meant by “just a few changes” to the colour options…
1.The piano roll keys should not have *any* colour setting. I know this is not deliberate but Podium is the only sequencer that I know of that has a piano roll that can change colour!?!?!?
So the piano roll keyboard graphics should simply be always black and white.
2. The track icons. Change certain colours to something moderately dark and the icons follow suite making them almost impossible to see. They should always be white with black text. Again I think they should not be affected by *any* colour changes elsewhere.
3. The hitpoints for the new fades…now I think because clips will vary in colour they (hit points) *should* have a colour setting.
So really just a few changes are enough to make a big difference.
xis23@Conquistador wrote:
3. The hitpoints for the new fades…now I think because clips will vary in colour they (hit points) *should* have a colour setting.
maybe a cool idea would be if the hitpoints colours always pick the opposite colour of the clip they are employed on for maximum contrast and so it never blends into the colour of clips. this is to say for instance a clip that had hue 70 would have a hitpoint hue of 197 (as 127 is half of the 255 hue range adding 127 to a number would give the opposite hue exactly), obviously using mod 255.
this could result in some garish combinations but you would at least never have to worry about visibility problems
Conquistador@xis23 wrote:
maybe a cool idea would be if the hitpoints colours always pick the opposite colour of the clip they are employed on for maximum contrast and so it never blends into the colour of clips. this is to say for instance a clip that had hue 70 would have a hitpoint hue of 197 (as 127 is half of the 255 hue range adding 127 to a number would give the opposite hue exactly), obviously using mod 255.
this could result in some garish combinations but you would at least never have to worry about visibility problems
That is quite clever xis23, I think that actually could work very well.
Also Frits, to clarify further regarding which icons I suggested having separate colour options for…I was referring to the recent icons that were introduced in 1.68.
“icons for device mapping, preset and parameter objects.” These should at least have a white background and black text by default and other icons for MIDI input, audio input and audio output mappings should not be tied to other colour settings for other areas in Podium, as it can just too easily make them needlessly too dark.
As the purpose for the icons is to priovide increased visibility and to aid a user in better identifying certain aspects of Podium, anything that complicates that process should really be revisited.
Of course I am 99% certain none of the current issues with colours were intentional 😉 but with many more features now added to Podium since 1.68…I think the Piano roll, “1.68” icons and hit points need their own colour settings.
The Piano roll really does not even need a ‘colour’ setting but but simply black and white keys that do not change whatever colour settings are changed elsewhere in Podium.