Beta of upcoming bug fix update available: Live 5.0.3b4!
Not installed the beta yet - will do this afternoon.
However, here are my big two bugs from 5.02.
This saturday, after defragmenting my drive, half of the clips on one track in my set (the later clips) started to glitch on first launch. After they had been launched once they were fine. However, on "pre-launching" all the clips before starting my set after a few minutes of "pre-launching" everything started going a bit nuts and would only play half a second of EVERY clip. This would happen if I launch "too-many" glitching clips.
I immediately tried 5.01 and that worked fine. In fact, after trying 5.01 and going back to 5.02, the latter worked fine.
I was able to reproduce the following EVERY time: The first version of Live I used after startup suffered this problem and upon switching to another the problem went away. Switching subsequently back to the first version used upon startup worked fine too.
VERY strange.
Secondly, PLEASE PLEASE PLEASE address this bug, it's been brought up several times on the forum and confirmed by several users:
http://www.ableton.com/forum/viewtopic. ... yager+midi
However, here are my big two bugs from 5.02.
This saturday, after defragmenting my drive, half of the clips on one track in my set (the later clips) started to glitch on first launch. After they had been launched once they were fine. However, on "pre-launching" all the clips before starting my set after a few minutes of "pre-launching" everything started going a bit nuts and would only play half a second of EVERY clip. This would happen if I launch "too-many" glitching clips.
I immediately tried 5.01 and that worked fine. In fact, after trying 5.01 and going back to 5.02, the latter worked fine.
I was able to reproduce the following EVERY time: The first version of Live I used after startup suffered this problem and upon switching to another the problem went away. Switching subsequently back to the first version used upon startup worked fine too.
VERY strange.
Secondly, PLEASE PLEASE PLEASE address this bug, it's been brought up several times on the forum and confirmed by several users:
http://www.ableton.com/forum/viewtopic. ... yager+midi
Last edited by Hedroom on Thu Dec 08, 2005 9:08 am, edited 1 time in total.
Oh... and I just remembered another BIG one!!!
UAD-1 card:
1) If I use the UAD-1 in a set it works fine, as expected. However, if I then open another set using the UAD-1 I ALWAYS get a CPU exceeded message from the UAD-1. As if the UAD-1's resources are not relieved upon closing a set which uses them.
2) Freezing a track which uses the UAD-1 does not free up it's resources thereby defeating the object of freezing.
3) Often in a track if I am reaching the limit of my UAD-1 CPU I will activate one plugin, say a reverb in the first 8 bars of the song (intro), and then turn it off and activate another. On playback I don't get CPU overload because both plugs are never used simultaneouusly. However, if I later run out of computer CPU and need to render I get a UAD-1 CPU overload message. It is as if rendering requires both plugs to be activated simultaneously. As a result, I am unable to render what I have written.
UAD-1 card:
1) If I use the UAD-1 in a set it works fine, as expected. However, if I then open another set using the UAD-1 I ALWAYS get a CPU exceeded message from the UAD-1. As if the UAD-1's resources are not relieved upon closing a set which uses them.
2) Freezing a track which uses the UAD-1 does not free up it's resources thereby defeating the object of freezing.
3) Often in a track if I am reaching the limit of my UAD-1 CPU I will activate one plugin, say a reverb in the first 8 bars of the song (intro), and then turn it off and activate another. On playback I don't get CPU overload because both plugs are never used simultaneouusly. However, if I later run out of computer CPU and need to render I get a UAD-1 CPU overload message. It is as if rendering requires both plugs to be activated simultaneously. As a result, I am unable to render what I have written.
And another...
Render is very unreliable. I often get big glitches in a rendered file. These are often rhythmical - i.e. corresponding with a snare from impulse. I stress that this happens when using no external plugins.
As a result, I prefer to resample. However, if I have a CPU intensive track such that audio starts glitching on playback I have a big problem. I would normally resample with some tracks turned off. However, muting a track makes no difference to the CPU. I actually have to press the stop button to free up those resources.
One more minor one.... Presumable the soundcard's latency setting should have no effect on playback? If I activate and EQ4 effect (perhaps a drastic "telephone-EQ effect") exactly on the bar and then increase soundcard latency, the audible EQ activation happens late. I.e. you hear the unaffected signal for a little bit before EQ4 kicks in. To solve this I have to activate EQ4 a little earlier than I need it if I am to be playing back at high latency (to conserve CPU when producing CPU intensive tracks).
There we go... should keep you busy Your work is much appreciated guys.
Cheers
Gaz
Render is very unreliable. I often get big glitches in a rendered file. These are often rhythmical - i.e. corresponding with a snare from impulse. I stress that this happens when using no external plugins.
As a result, I prefer to resample. However, if I have a CPU intensive track such that audio starts glitching on playback I have a big problem. I would normally resample with some tracks turned off. However, muting a track makes no difference to the CPU. I actually have to press the stop button to free up those resources.
One more minor one.... Presumable the soundcard's latency setting should have no effect on playback? If I activate and EQ4 effect (perhaps a drastic "telephone-EQ effect") exactly on the bar and then increase soundcard latency, the audible EQ activation happens late. I.e. you hear the unaffected signal for a little bit before EQ4 kicks in. To solve this I have to activate EQ4 a little earlier than I need it if I am to be playing back at high latency (to conserve CPU when producing CPU intensive tracks).
There we go... should keep you busy Your work is much appreciated guys.
Cheers
Gaz
-
- Posts: 7251
- Joined: Thu Sep 29, 2005 8:34 am
- Contact:
Quite possibly but none of these are in the change log so I suspect they haven't been addressed. Secondly, I felt it best to make the issues known as early as possible so that they stand the best possible chance of being addressed before 5.03 is rolled out.
Tis all.
I may well come back tomorrow and say all these things have gone away. I hope so...
Tis all.
I may well come back tomorrow and say all these things have gone away. I hope so...
-
- Posts: 92
- Joined: Sun Nov 13, 2005 9:35 pm
- Location: alba
so far so good with the beta regarding the following issue.
ran a set that was hurting on 5.02 when i whacked another plug on there, in fact, it was crushed when i put the audio damage 907 filter plug on the end of an effects chain. cpu meter just jumped to 128% blah blah. and audio went into stutter hell. couldn't get out of it. Had to re boot live after a restart. I think relaunching the core audio driver would have done it in retrospect.
It seems that the cpu headroom thing has been addressed. In 5.02 it would seem to hit 70% then anything after that would cause problems as if that last 30% didn't actually exist and it was infact at 99%!
anyhow, better, much better.
The midi input timing is still fuckd, ref other posts for the problem.
can't fault being able to give feedback like this direct to the codewriters.
Any company that gives direct feedback to it's customers these days is a godsent in these times of remote call centres with latency on phone calls! so i can forgive the shortfallings in the meantime but lie in wait for the fix.
ran a set that was hurting on 5.02 when i whacked another plug on there, in fact, it was crushed when i put the audio damage 907 filter plug on the end of an effects chain. cpu meter just jumped to 128% blah blah. and audio went into stutter hell. couldn't get out of it. Had to re boot live after a restart. I think relaunching the core audio driver would have done it in retrospect.
It seems that the cpu headroom thing has been addressed. In 5.02 it would seem to hit 70% then anything after that would cause problems as if that last 30% didn't actually exist and it was infact at 99%!
anyhow, better, much better.
The midi input timing is still fuckd, ref other posts for the problem.
can't fault being able to give feedback like this direct to the codewriters.
Any company that gives direct feedback to it's customers these days is a godsent in these times of remote call centres with latency on phone calls! so i can forgive the shortfallings in the meantime but lie in wait for the fix.
macbook 2.16 ghz, live 6...studio with gear now gathering dust.
Re: Beta of upcoming bug fix update available: Live 5.0.3b4!
This is very good, the old behaviour was confusing. Works the same on BCF2000 with Mackie/Cubase emaulationAlex wrote: -----------------------------------------------------------------
Improvements: Mackie Control Support
-----------------------------------------------------------------
-> Bank switches will now never align the tracks to the last strip, but always wrap by the number of available strips (8, when using only the main Mackie without any extensions).
Re: Beta of upcoming bug fix update available: Live 5.0.3b4!
Yeah the old behaviour was indeed confusing - I found often found myself getting "lost" when banking back and forth between a large number of tracks.djsynchro wrote:This is very good, the old behaviour was confusing. Works the same on BCF2000 with Mackie/Cubase emaulationAlex wrote: -----------------------------------------------------------------
Improvements: Mackie Control Support
-----------------------------------------------------------------
-> Bank switches will now never align the tracks to the last strip, but always wrap by the number of available strips (8, when using only the main Mackie without any extensions).
JaseFOS
-Live10.1 |Push2|Maschinemk2|KeyLab61|LaunchPad|MCUpro|MCExt|MCExt|iPad2|TouchABLE2
-Mac Pro 5.1 (dual hex core Xeon 3.46gHz, 28Gb RAM) running MacOS 10.13.6
-Universal Audio Apollo Quad (firewire)
-SHITLOADS OF HARDWARE SYNTHS
-Live10.1 |Push2|Maschinemk2|KeyLab61|LaunchPad|MCUpro|MCExt|MCExt|iPad2|TouchABLE2
-Mac Pro 5.1 (dual hex core Xeon 3.46gHz, 28Gb RAM) running MacOS 10.13.6
-Universal Audio Apollo Quad (firewire)
-SHITLOADS OF HARDWARE SYNTHS
Re: Beta of upcoming bug fix update available: Live 5.0.3b4!
If that affects the CPU usage too, we may have to redo the Adam Jay's Live 5 test from the beginning....Alex wrote: -----------------------------------------------------------------
Improvements: Memory usage
-----------------------------------------------------------------
We were able to reduce the memory usage of Live. Depending on how many clips and how many different physical audio files are used within a set Live could need up to 25% less memory.
Let's see, I'll try home with the final version
Best,
amo[/quote]
Live 5.0.3 - IBM Thinkpad R51 1.5ghz Centrino - 1,5 Go RAM - 7200 RPM 2nd HDD intern - RME Multiface - Windows XP Pro SP2
Sampletank 2 issue not corrected in 5.0.3
description:
Midi track with Sampletank2 stop responding and it is not possible to revive it with other VSTi (until restarting Live). After this bug Live5 usualy show bug report and crash imediately.
I sent description of this bug several times to your support without answer.
I am sad because I must using Live 4 instead of my Live 5 (it is more than 4 months). Live 4 has no problem with ST2...
description:
Midi track with Sampletank2 stop responding and it is not possible to revive it with other VSTi (until restarting Live). After this bug Live5 usualy show bug report and crash imediately.
I sent description of this bug several times to your support without answer.
I am sad because I must using Live 4 instead of my Live 5 (it is more than 4 months). Live 4 has no problem with ST2...
-
- Posts: 1119
- Joined: Tue Nov 22, 2005 6:29 pm
Yes Yes and yes. The TC Powercore resources are also not relieved upon shutting down a set. I would love to see the overall support for both these dsp cards continued.Splashmas wrote:Oh... and I just remembered another BIG one!!!
UAD-1 card:
1) If I use the UAD-1 in a set it works fine, as expected. However, if I then open another set using the UAD-1 I ALWAYS get a CPU exceeded message from the UAD-1. As if the UAD-1's resources are not relieved upon closing a set which uses them.
2) Freezing a track which uses the UAD-1 does not free up it's resources thereby defeating the object of freezing.
3) Often in a track if I am reaching the limit of my UAD-1 CPU I will activate one plugin, say a reverb in the first 8 bars of the song (intro), and then turn it off and activate another. On playback I don't get CPU overload because both plugs are never used simultaneouusly. However, if I later run out of computer CPU and need to render I get a UAD-1 CPU overload message. It is as if rendering requires both plugs to be activated simultaneously. As a result, I am unable to render what I have written.