we have waited far too long for a bug fix!!!
bye
Sorry about this Sam.
1.95 has turned out to be a mega update. I’ve stopped adding new features, and will now concentrate on testing and bug fixing.
From an old email from you, I was under the impression that you had been using one of the 1.95 betas which had fixed the bug you refer to. Maybe I misunderstood you.
@sam c wrote:
we have waited far too long for a bug fix!!!
bye
Why are you shouting here? You see how long to take an update from Steinberg, for example? 3-4 months. And there is a big team. Frits works alone. We all want, that graphical update would be done so, that never come back to this problem anymore.It’s good for us and Frits too. Just wait a little bit more, and you will get what you want. 😉
@Igr0 wrote:
@sam c wrote:
we have waited far too long for a bug fix!!!
bye
Why are you shouting here? You see how long to take an update from Steinberg, for example? 3-4 months. And there is a big team. Frits works alone. We all want, that graphical update would be done so, that never come back to this problem anymore. It’s good for us and Frits too. Just wait a little bit more, and you will get what you want. 😉
Personally while I agree that if we “wait a little bit more” we will get what we want, I don’t see what is wrong with Sam C expressing his views here regarding 1.95’s full release (not as a beta) which I think is what he was talking about.
There was a particular bug which still is IMO a major hassle to deal with, that under normal circumstances would have been addressed within 4 weeks max. It’s almost three months since the last Podium release.
Of course I cannot imagine Frits decided to stretch things out for 3 months on purpose, clearly it was unexpected and unforseen. But…based on the past 100 releases or so that Podium has had so far, (AFAICT all within a 4 -5 week timeframe), one can surely see why some peoples expectations are high for a return to quicker releases. Even more importantly IMO, quicker fixes that are not held up by the addition of more features which are of course welcome.
One simply wants to avoid trading a needed fix for new features. The 4 – 5 week time frame (even much sooner at times), solves that problem.
As for the Steinberg analogy…well they simply choose to work that way. There are many companies that choose an ultra secretive business model for their products, and longer release cycles for patches and fixes but it is a choice not a necessity.
Even Steinberg themselves in the past have released a patch within a 3 week time frame, so even with Steinberg’s huge product portfolio, Cubase 4.02.2217 was released on the 21st of March this year less than three weeks after Cubase 4.02 was released (2nd of March 2007).
Frits, Justin & Christophe (Reaper) are good examples of one or two people consistently developing a product with very short release schedules for features and patches (within 4-5 weeks).
Interestingly, neither Frits nor the Justin and Christophe combo have multiple products to juggle so they can focus on quicker releases which Frits has done about 100 times already since v.0.90. That is why I think it is easy to see why one can be rather eager for the usual quicker releases for Podium. It has always been that way.
Ableton: They have one product but choose to release it on an annual basis. But even they have released patches within a three week period in the past few months. Live.6.09 and Live 6.0.10 had less than three weeks between their releases.
Frits has clarified here and elsewhere on the forum that 1.95 does not represent a permanent change in release schedules for Podium, so I am not worried at all, but I do remain very eager for 1.95’s release as it does have a key fix in it that has been held up (not deliberately) by the addition of new features.
In any case 1.95 is certainly well worth the wait and the release schedule will return to it’s previous state after 1.95 released. 🙂
Which bug are we referring to, exactly? I’m still using 1.93 (I never upgrade in the middle of a paying project!) and was just about to update…
JP
http://www.zynewave.com/forum/viewtopic.php?t=1459
It disables the audio mixing option on a track if you add an effect by dropping it on the left edge of the track header. You can either manually reenable audio mixing afterwards, or add an effect by creating a group track first, and then assign the effect mapping to the group track.
@Zynewave wrote:
Sorry about this Sam.
1.95 has turned out to be a mega update. I’ve stopped adding new features, and will now concentrate on testing and bug fixing.
From an old email from you, I was under the impression that you had been using one of the 1.95 betas which had fixed the bug you refer to. Maybe I misunderstood you.
I certainly accept and appreciate your apology! I probably should have used the beta but i had a couple of very intense projects and I was concerned so i dealt with the fx bug.
thanks
Igr0, no shouting just a little frustrated. i use the fx drag to track feature an incredible amount and it is, well, frustrating to lose the gain and pan each time i do.
@jpleong wrote:
Which bug are we referring to, exactly? I’m still using 1.93 (I never upgrade in the middle of a paying project!) and was just about to update…
JP
Frits post…
http://www.zynewave.com/forum/viewtopic.php?t=1459
It disables the audio mixing option on a track if you add an effect by dropping it on the left edge of the track header. You can either manually reenable audio mixing afterwards, or add an effect by creating a group track first, and then assign the effect mapping to the group track.
…has the link to the exact bug I was referring to. Thats the one 😉
Well, that’s good since I was going to bypass 1.94 and go straight to the beta anyway!
JP