* possible causes and workarounds, shared by users.
* patterns and probabilites, to gather intelligence for helping the bug fixing.
* info by makers, e.g. links to how-to descriptions, and listings of incompatible plugins.
info about confirmed issues, linking to current listings and some comments what do do about.
* compare crash behavior across different versions. needs fine definition of the particular crash situation.
-------------------------------
T6 on windows7 pro here.
many of my crashes disappear with avoiding certain plugins, e.g. a very old "mda" series.
some plugins pass the test, but later seem to disbehave. so there is room for a "rigid test" function that may work slower. it should mimick all functions of the DAW including rendering on different sample rates, and reading/writing parameter blocks in the form of Tracktion presets. reinitializing. latency requery.
some plugins will crash some mixes, when I change a value that has impact on latency.
I have crashes with just clicking on certain plugins, which has to do with the graphics handling, and perhaps bios interrupt. it happens more frequently when windows was running for a couple of days.
on freshly rebooted windows, T1, T5 and T6 all have fewer crashes. remarkably. most commercial software is quite immune, of course until RAM has been eaten up e.g. by Firefox greed.
some crashes occur immediately while loading an edit, but disappear with rebooting.
there is a crash possibly when the file, that the mix should be rendered to, exists and already is open with a sound editor. sometimes, just the file name is changed by T6 to something else, after I change it to an existing file for overwriting, and nothing bad happens.
there are crashes with copy/paste operations that contain multiple tracks. sometimes this goes away when I exclude a certain track with a certain plugin. but the plugin otherwise seems to work correctly.
graphics crashing has reduced from T5 to T6.
-----
your turn folks.
The Crash Topic
-
- KVRist
- Topic Starter
- 320 posts since 9 Sep, 2017
I would love the simple automation that can do almost anything.
but when it becomes complex, it fails.
example (win 7/64 pro):
create an auto track with the [+]. then have the particular rack construction of the parent track open, and pull the [A] onto a rack plugin, that handles this track, while the rack is part of a number of other tracks as well, and the problem occurs especially on one of several identical (stock) volume riders, as there is a parallel system in the rack. (multitimbral synth, some 'browerizing', whatever). choose volume, then draw a curve.
now after a couple of recalls, the automation curve ends up in nowhereland and crashes on touch, or it points to some random bus volume plugin a mile elsehere in the mix.
additional crash: when I start the curve on the original (real) track, then hide this curve, create an automation track instead, select the existing curve into that one, and then use the generic shift/expand tool in the property section (dragging the arrow to the right or to the left for general volume change). when I do this immediately, there is a crash. when I first create some additional autopoints within the virtual automation track, it sometimes realigns the internal data connection, and then the volume shifting operation works. but sometimes I cannot create that point, and it crashes on the double click attempt to do so.
and active rack settings do not save properly within the edit file. only some do, and it changes. T1 had its own rack handler, and what it could do, it could save.
---
error handling seems poor.
error in response by graphics chip: crash
error in requesting more memory from the OS: crash (on windows, we are getting more and more fragmented memory, until we reboot. seems not being handled well).
better give the user a warning: out of linear buffer memory or something -> save and close.
graphics engine errors should give a warning, do a retry, invoke some heuristics, and serve a [graphics reset] button to restart all display systems and operations.
but when it becomes complex, it fails.
example (win 7/64 pro):
create an auto track with the [+]. then have the particular rack construction of the parent track open, and pull the [A] onto a rack plugin, that handles this track, while the rack is part of a number of other tracks as well, and the problem occurs especially on one of several identical (stock) volume riders, as there is a parallel system in the rack. (multitimbral synth, some 'browerizing', whatever). choose volume, then draw a curve.
now after a couple of recalls, the automation curve ends up in nowhereland and crashes on touch, or it points to some random bus volume plugin a mile elsehere in the mix.
additional crash: when I start the curve on the original (real) track, then hide this curve, create an automation track instead, select the existing curve into that one, and then use the generic shift/expand tool in the property section (dragging the arrow to the right or to the left for general volume change). when I do this immediately, there is a crash. when I first create some additional autopoints within the virtual automation track, it sometimes realigns the internal data connection, and then the volume shifting operation works. but sometimes I cannot create that point, and it crashes on the double click attempt to do so.
and active rack settings do not save properly within the edit file. only some do, and it changes. T1 had its own rack handler, and what it could do, it could save.
---
error handling seems poor.
error in response by graphics chip: crash
error in requesting more memory from the OS: crash (on windows, we are getting more and more fragmented memory, until we reboot. seems not being handled well).
better give the user a warning: out of linear buffer memory or something -> save and close.
graphics engine errors should give a warning, do a retry, invoke some heuristics, and serve a [graphics reset] button to restart all display systems and operations.
-
- KVRist
- Topic Starter
- 320 posts since 9 Sep, 2017
one issue, now reproducable:
* draw an automation curve, that points to a parameter in a rack plugin.
* get a problem with the rack data recall (after reopening edit, maybe a plugin is faulty, different issue that)
* reload _correct_ rack settings from rack preset file. (also think of A/B testing with whole rack setups of same structure but different sound settings)
=> automation curve becomes "orphaned", and when we click on it, crash & back to square one.
--
so, that's not justified, though we can understand the logic of the problem.
refining the ID concepts will solve it very elegantly.
at first, the forgotten orphaning issue must be monitored, there may be some more instances where it might happen. we must at least prevent a crash.
second, the background system should offer solutions.
with the composite key concept, the reconnection-logic can simply compare physical track number, then the (userdefined) names of plugin and rack instances, and then plugin name and path (when plugin 'short' ID is invalid). this can be iterated with widened scope, until something that looks reasonable has been found. all that per orphaned object of potentially many, in two roundtrips, first trip is for anything that has a 99% match, and then consequently make attempts for what is still unresolved.
then give a message to click [ok] or [manual reconnect], that tells us, I found automation curves (and whatnot) with the following names and descriptions, and I will reconnect with the following racks and plugins: ... ... ...
so the user gets warned that she did something not so trivial, and can correct the problem manually and quickly before chaos happens, if not the system figured out the obvious relationships by itself.
* draw an automation curve, that points to a parameter in a rack plugin.
* get a problem with the rack data recall (after reopening edit, maybe a plugin is faulty, different issue that)
* reload _correct_ rack settings from rack preset file. (also think of A/B testing with whole rack setups of same structure but different sound settings)
=> automation curve becomes "orphaned", and when we click on it, crash & back to square one.
--
so, that's not justified, though we can understand the logic of the problem.
refining the ID concepts will solve it very elegantly.
at first, the forgotten orphaning issue must be monitored, there may be some more instances where it might happen. we must at least prevent a crash.
second, the background system should offer solutions.
with the composite key concept, the reconnection-logic can simply compare physical track number, then the (userdefined) names of plugin and rack instances, and then plugin name and path (when plugin 'short' ID is invalid). this can be iterated with widened scope, until something that looks reasonable has been found. all that per orphaned object of potentially many, in two roundtrips, first trip is for anything that has a 99% match, and then consequently make attempts for what is still unresolved.
then give a message to click [ok] or [manual reconnect], that tells us, I found automation curves (and whatnot) with the following names and descriptions, and I will reconnect with the following racks and plugins: ... ... ...
so the user gets warned that she did something not so trivial, and can correct the problem manually and quickly before chaos happens, if not the system figured out the obvious relationships by itself.
-
- KVRist
- Topic Starter
- 320 posts since 9 Sep, 2017
automation curves not only crash with disconnected rack plugin references.
there seems another issue, even with the standard volume automation. it seems related to windows memory fragmentation, or with a GPU error. it seems not to happen on a freshly rebooted system.
most frequent scenario is using the add/multiply tool that graphically exists with the two arrows to drag, in the properties section at the bottom of the T6 GUI.
but also by double clicking the curve to create a new point, it can happen. seems as if this requests quite a lot of buffer memory from the system.
it is happening with the virtual automation tracks, created with the [+] symbole below the [A]. perhaps they have more than one disconnection-problem.
it is very random. when I restart T6 it may happen again or not. after a couple of attempts and many minutes, it usually works. at least with the previously ill-fated curve. then, the next one crashes, that I did not touch during a couple of edit sessions, but right now.
----
worst unprofessional issue:
the position of the automation curves gets out of sync more and more when there is latency in the mix routings.
latency computation is quite smart, though.
but the automation curve does not benefit. editing syllable strength with automation fails when we need it most: on vocals where we use also some autotuner, or any plugin that demands latency to be able to do its work.
offset can e.g. be as bad as 0.3 sec. difficult to hit the attack of a leading consonant or anything.
last night I had to shift a certain segment of the curve about 250 ms to the right, when it should be exactly under the visible waveform. will this work still, when I insert another plugin to this vocal track?
on same severity level:
"send" effect functionality does not support latency? no modern complex reverbs?
using a rack as a "send" workaround so far seems to function. but clumsy to manage, because of the missing on-the-fly renaming of plugins.
there seems another issue, even with the standard volume automation. it seems related to windows memory fragmentation, or with a GPU error. it seems not to happen on a freshly rebooted system.
most frequent scenario is using the add/multiply tool that graphically exists with the two arrows to drag, in the properties section at the bottom of the T6 GUI.
but also by double clicking the curve to create a new point, it can happen. seems as if this requests quite a lot of buffer memory from the system.
it is happening with the virtual automation tracks, created with the [+] symbole below the [A]. perhaps they have more than one disconnection-problem.
it is very random. when I restart T6 it may happen again or not. after a couple of attempts and many minutes, it usually works. at least with the previously ill-fated curve. then, the next one crashes, that I did not touch during a couple of edit sessions, but right now.
----
worst unprofessional issue:
the position of the automation curves gets out of sync more and more when there is latency in the mix routings.
latency computation is quite smart, though.
but the automation curve does not benefit. editing syllable strength with automation fails when we need it most: on vocals where we use also some autotuner, or any plugin that demands latency to be able to do its work.
offset can e.g. be as bad as 0.3 sec. difficult to hit the attack of a leading consonant or anything.
last night I had to shift a certain segment of the curve about 250 ms to the right, when it should be exactly under the visible waveform. will this work still, when I insert another plugin to this vocal track?
on same severity level:
"send" effect functionality does not support latency? no modern complex reverbs?
using a rack as a "send" workaround so far seems to function. but clumsy to manage, because of the missing on-the-fly renaming of plugins.
-
- KVRAF
- 1790 posts since 30 Dec, 2012
Hi Hans, thanks for the bug reports but are all of these issues in T6? As T6 is now free, we can really only offer support on the OEM and latest versions. There have been many, many updates since T6 so some of these issues may have already been fixed.
Additionally, starting with Waveform 8, we added much improved crash logging to the app so if you send us the appropriate crash reports, we should be able to relatively easily find out where the crashes are and fix them.
I'm currently in the process of doing a lot of work on automation so will check the issues you mentioned but as far as I can tell it should already be accurate to the buffer size. In T7 we introduced finer resolution automation for curves and LFO driven parameters so maybe this would help?
Additionally, starting with Waveform 8, we added much improved crash logging to the app so if you send us the appropriate crash reports, we should be able to relatively easily find out where the crashes are and fix them.
I'm currently in the process of doing a lot of work on automation so will check the issues you mentioned but as far as I can tell it should already be accurate to the buffer size. In T7 we introduced finer resolution automation for curves and LFO driven parameters so maybe this would help?
-
- KVRist
- Topic Starter
- 320 posts since 9 Sep, 2017
thanks for considering and answering!
it's not that I ask for "support" on T6.
I had started with T1 on Gearslutz, then T4 and T5.
having just a more general consideration, about the progress of the project.
to know these things have been fixed in the meantime, would be very encouraging.
T6 however is already quite a high version number, so I would have expected a bit less of that.
thus, T7 and the Waveforms, are unclear of corresponding progress until clearly documented.
then, most issues fixed and public protocol about that, it would be easier to argue that the latest version is worth buying.
but T6 before was charged for also. the low prices probably did justify the attempt and many users took the deal.
so, if you could fix much of that already, it's great progress, but if you could manage to inject the corrections also into T6, it wouldn't be called support, but the best advertising ever. because then, the new features make sense, after everything else can be trusted on the more basic levels.
the automation curves so far were fine-grained enough for me, but some of them happen to get really shifted out of sync.
as I said they seem not to be subject to the latency correction routines, which would be a severe omission.
in short, 2 issues with automation.
1) some crashes, 2) some time-shift, so I must draw a pattern e.g. 0.3 seconds later.
--
(generally speaking, there are 2 frequent types of "buffer" space errors on low-level. one happens, when memory gets requested from the OS, but it cannot manage that right now, perhaps some seconds later. the other comes when we lend buffer space to a third party component, but they messed up and overrun the buffer, destroying some data that wasn't their business.
other problems may come from a weak or boiling GPU that fails a request. the GUI might then crash or anything. but more fallback routines would be great. windows does not crash. after 2 seconds of black screen, it tells me that the graphic subsystem had died but it was reinitialized. this happens when the motherboard is overheating.)
I am describing my experiences here also for the benefit of the current versions, to double-check if everything has been fixed.
to look back, what was it, what did we do then, what infrastructure and measures have since then been helpful to prevent such glitches, and what could still be done.
does T6 generate crash reports that are useful enough to you? for a moment I looked into a log, but it said only that plugin x or y had crashed, which wasn't news to me.
---
what about racks not saving plugin state? was anything like that ever reported?
when I move a project from T5 to T6 it seems not to happen. in this case, there are always two edit xml files. trkedit and tracktionedit.
>>... so some of these issues may have already been fixed.
but if there is no one who can quickly remember, or look up in a minute, then the complexity of the undertaking might reach dangerous levels, growing faster then the tool set, infrastructure and meta abstraction of programming.
e.g. microsoft had obviously introduced innovative, strong paradigms to curb the explosion of complexity. still a hard struggle, but win 7 wouldn't have been possible without strong innovation on meta level.
all the best!!
it's not that I ask for "support" on T6.
I had started with T1 on Gearslutz, then T4 and T5.
having just a more general consideration, about the progress of the project.
to know these things have been fixed in the meantime, would be very encouraging.
T6 however is already quite a high version number, so I would have expected a bit less of that.
thus, T7 and the Waveforms, are unclear of corresponding progress until clearly documented.
then, most issues fixed and public protocol about that, it would be easier to argue that the latest version is worth buying.
but T6 before was charged for also. the low prices probably did justify the attempt and many users took the deal.
so, if you could fix much of that already, it's great progress, but if you could manage to inject the corrections also into T6, it wouldn't be called support, but the best advertising ever. because then, the new features make sense, after everything else can be trusted on the more basic levels.
the automation curves so far were fine-grained enough for me, but some of them happen to get really shifted out of sync.
as I said they seem not to be subject to the latency correction routines, which would be a severe omission.
in short, 2 issues with automation.
1) some crashes, 2) some time-shift, so I must draw a pattern e.g. 0.3 seconds later.
--
(generally speaking, there are 2 frequent types of "buffer" space errors on low-level. one happens, when memory gets requested from the OS, but it cannot manage that right now, perhaps some seconds later. the other comes when we lend buffer space to a third party component, but they messed up and overrun the buffer, destroying some data that wasn't their business.
other problems may come from a weak or boiling GPU that fails a request. the GUI might then crash or anything. but more fallback routines would be great. windows does not crash. after 2 seconds of black screen, it tells me that the graphic subsystem had died but it was reinitialized. this happens when the motherboard is overheating.)
I am describing my experiences here also for the benefit of the current versions, to double-check if everything has been fixed.
to look back, what was it, what did we do then, what infrastructure and measures have since then been helpful to prevent such glitches, and what could still be done.
does T6 generate crash reports that are useful enough to you? for a moment I looked into a log, but it said only that plugin x or y had crashed, which wasn't news to me.
---
what about racks not saving plugin state? was anything like that ever reported?
when I move a project from T5 to T6 it seems not to happen. in this case, there are always two edit xml files. trkedit and tracktionedit.
>>... so some of these issues may have already been fixed.
but if there is no one who can quickly remember, or look up in a minute, then the complexity of the undertaking might reach dangerous levels, growing faster then the tool set, infrastructure and meta abstraction of programming.
e.g. microsoft had obviously introduced innovative, strong paradigms to curb the explosion of complexity. still a hard struggle, but win 7 wouldn't have been possible without strong innovation on meta level.
all the best!!
-
- KVRAF
- 1790 posts since 30 Dec, 2012
It's a bit difficult to say exactly if a bug still exists or not because:
a) Some bugs are reported on here that get missed because they get buried in threads and don't have a proper tracking system so we can't verify a specific issue has been solved
b) Many bugs get resolved due to changes elsewhere in code. For example, I seem to remember a bug years ago where automation wasn't being correctly reset after the transport looped. We re-wrote how the automation tracks the position which fixed that particular bug. It could be that these changes also fixed the issue you're describing.
So really the only way to fully determine if a bug still exist is to try the latest version.
a) Some bugs are reported on here that get missed because they get buried in threads and don't have a proper tracking system so we can't verify a specific issue has been solved
b) Many bugs get resolved due to changes elsewhere in code. For example, I seem to remember a bug years ago where automation wasn't being correctly reset after the transport looped. We re-wrote how the automation tracks the position which fixed that particular bug. It could be that these changes also fixed the issue you're describing.
So really the only way to fully determine if a bug still exist is to try the latest version.