Waveform 9.0.38 Beta

[dRowAudio]

Waveform 9.0.38 Beta is now available in your Tracktion account: https://marketplace.tracktion.com/shop/ ... rchive?v=9

Mostly minor bugs and a few crashes fixed.

- Bugs: Fixed hang flattening audio clips
- Automation: Fixed a problem importing external plugin automation from W8 Edits
- Bugs: Fixed a potential crash deleting a MIDI clip showing the program change editor
- VST3: Fixed vstpreset files not loading on some VST3 plugins on the Mac
- Audio thumbs: Avoided mono audio clips resizing on pan changes
- Stacks: Fixed a problem where adding new plugins to the end of the list would place them at the start
- Stacks: Fixed a crash when clicking the Faceplate menu in the Stack editor if "single click to open plugins" is being used
- Modifiers: Fixed a crash assigning modifiers to their own parameters
- Browser: Fixed a problem where the patch bay plugin wouldn't automatically connect if added from the browser

[BushmasterM4]

Oh !! Did Slate Trigger 2 get fixed ?

[dRowAudio]

Oh !! Did Slate Trigger 2 get fixed ?

Unfortunately not. I spent a long time looking in to the problem with Trigger 2, it's a crash that happens when we try to read the text of one of the higher parameters (the 118th IIRC).

I think the crash happens in other hosts if you try to automate those high parameters (and the host tries to read the parameter text) but I can't be sure.
The difference with us is that we read all of these when we load the plugin in order to cache them for controllers such as Automap etc.

I reported all of this to their devs over a year ago along with detailed reports and stack traces.
We could work around this and limit the number of parameters we expose with this specific plugin but that's not really a reliable way forwards as if we did this for every plugin that there was a problem with, the code would be terrible and there'd be a performance penalty to pay.

This really needs a fix from the Slate side...

[Robert Randolph]

- Modifiers: Fixed a crash assigning modifiers to their own parameters

Thank you. I updated Part 2 of my review where I mentioned this behaviour. It's now struckout with a note of the fix.

Due to this fix, I noticed another issue.



When assigning modifier parameters to other modifiers, certain controls do not move smoothly. In the .gif above you can see that all of the parameters allow smooth % assignment except the rate control, which is jumpy.

This behaviour happens on the assignments window and the parameter search column as well.

The following modifiers controls exhibit this behaviour:

• LFO Rate
• Breakpoint Rate
• Step Modifier Rate
• Envelope Follower LP
• Envelope Follower HP
• Envelope Follower Attack
• Envelope Follower Hold
• Envelope Follower Release
• Random Rate

[BushmasterM4]

Oh !! Did Slate Trigger 2 get fixed ?

UNfortunately not. I spent a long time looking in to the problem with Trigger 2, it's a crash that happens when we try to read the text of one of the higher parameters (the 118th IIRC).

I think the crash happens in other hosts if you try to automate those high parameters (and the host tries to read the parameter text) but I can't be sure.
The difference with us is that we read all of these when we load the plugin in order to cache them for controllers such as Automap etc.

I reported all of this to their devs over a year ago along with detailed reports and stack traces.
We could work around this and limit the number of parameters we expose with this specific plugin but that's not really a reliable way forwards as if we did this for every plugin that there was a problem with, the code would be terrible and there'd be a performance penalty to pay.

This really needs a fix from the Slate side...

Thanks for the answer !! I sent in tickets to both (couple times) and received no replies. Slate has since added that there is an issue with Tracktion or Waveform and Trigger in their read me files. I continue to use Trigger (1). It works just fine. But again thanks for the reply. I will quit bugging about it here. Now I have to bug the heck out of Steven Slate !!!

[PierreG]

Auto Lock behavior issues.

Automation data does not move with the clips when using the Move Clip feature. It does move / copy the automation data if you drag the clips to a new position via mouse, yet when using this method, the clips don't visually move with the mouse cursor, until you let go of the mouse button, thus it's a blind move. Other versions have not liked dragging huge amounts of clips, especially comp clips with many takes, thus I've tended to use the Move Clip option, which is very fast, accurate and didn't cause hangs or crashes.

This behavior's been around for a while and I just tested it in 9.0.37 and it's still not working for me.

Comp clips: When takes are displayed, the take numbers on the left side are unreadable. They're a dark grey box with a barely different shade of grey for text.

Be cool to have the automation curve color know to switch to a well contrasted color to the clip color (when it's blue) so that it doesn't disappear unless you select it (turns from blue to red). Needing to change the clip color to see the automation curve on blue clips is not optimal. I know this is a niggle!

The above (copied from the .37 thread) were not addressed in this beta.

Please respond.

[HansP]

perhaps encoding or "escaping" of Slate Par 118 isn't done properly?
something like the Apple smartphone bug that crashed it when entering a certain unicode?
or one or two zeroes, in case we use "C" parameter convention where the zero value means end of string.
or the opposite, where the workhorse routine does not know when to stop with copying the parameter value to/from the buffer, because the zero was forgotten.

humble suggestion (plugin hint library):
I would think of having hints in a growing and updatable xml file about plugin quirks. it would start with an index of DLL/AU/... names.
it might have a thousand entries, so to keep fast operation, the DAW might look up in that list only after a plugin has crashed.
then, the crash would happen only once, and next time the "hint" has already been copied into the actual plugin list.
(WaveForm might have an auto-update function to regularly read new such library files from the Tracktion website.)

suggested structure of the "hint" object:
- [plugin name(s), file name(s), version numbers to identify the plugin] (all versions that apply to the same hints)
- upper limit for number of parameters to meaningfully read at all
hints by parameter number (collection):
- number
- readable parameter name
- parameter is readonly (y/n)
- strategy (just don't use/encode in a special way/use boundaries and add offset for a numeric value/...)
- encoding type (might specify character set family, unicode quirks, replacement characters, forbidden characters, per operating system)
- encoding: various sub parameters
- upper and lower boundaries for numeric parameter
- offset for numeric parameter
- user readable description to display in the DAW, to alarm the user of a problem and explain the workaround (might be the index into a string text list somewhere else in the xml)

the hint system might be public in a way that skilled users who understand the structure can suggest new entries, or software vendors themselves can suggest special handling of a parameter. or any DAW programmer who found out something special about a plugin.
at "redaction time" the official list gets updated and can include the contributions after a check.

[PierreG]

Have an edit that's MASSIVELY expanding while doing simple edits.

This is an edit migrated up from T7 and may have been in W8. Looked into this when saving the edit started to become slower and slower. It's gone from around 1MB to over 120mb!

Does this have to do with the automation import fix? in 9.0.37 and 38?



Edited: I don't have time to test this theory at the moment, yet I'm convinced this is a .38 issue that was not present in .37. Will regress to .37 and monitor the edit file size, then report back, hopefully this evening. I'm really hoping there's an easy way to deflate this massive edit while saving my work!

Update: Reverted to .37 and the issue is still in full bloom. Having the edit merely open and sitting there will expand the file size around 1mb every few minutes. I was able to copy one track at a time and paste them into a fresh new empty edit, which is only 1.5mb now, compared to the now over 137mb original edit! I did have poof crashes when clicking on the A to display the automation curves in the new edit. Also, the Stereo Pass Through racks I was using for Aux Send / returns showed up in the copied to edit as Rack type missing. I could select these racks. yet clicking on Delete to get rid of them poofs W. Right clicking on them to bring up the menu poofs W as well. The solution was to create another new edit and drag these faulty racks into it. This cleared up my rebuilt edit, yet not surprisingly, the racks still crash in the edit they were dragged into.

[gavindi]

Hi,

I've noticed that when I play a midi clip with the multi sampler, the first note(s) starting on beat 1.000 aren't played but all subsequent notes are played as you would expect.

If I set the cursor one bar back then the notes on the next bar at 1.000 will play.

Edit: Actually its a bit more weird than I first thought. If I set the cursor just before the clip, the notes at 1.000 play. If I back the cursor up more then they wont. back it up (further before) and it will play.
Edit 2: It also happens with the FM Synth plugin so its not solely the Multi-Sampler.
Edit 3: Only happens on some tracks in the song and not others.
Edit 4: If I move the start of the clip but keep the content fixed (Leftmost arrow) the first note will then play!
Edit 5: Seems to only happen with linked clips.

Cheers,
Gavin

[dRowAudio]

Have an edit that's MASSIVELY expanding while doing simple edits.

This is an edit migrated up from T7 and may have been in W8. Looked into this when saving the edit started to become slower and slower. It's gone from around 1MB to over 120mb!

Does this have to do with the automation import fix? in 9.0.37 and 38?



Edited: I don't have time to test this theory at the moment, yet I'm convinced this is a .38 issue that was not present in .37. Will regress to .37 and monitor the edit file size, then report back, hopefully this evening. I'm really hoping there's an easy way to deflate this massive edit while saving my work!

Update: Reverted to .37 and the issue is still in full bloom. Having the edit merely open and sitting there will expand the file size around 1mb every few minutes. I was able to copy one track at a time and paste them into a fresh new empty edit, which is only 1.5mb now, compared to the now over 137mb original edit! I did have poof crashes when clicking on the A to display the automation curves in the new edit. Also, the Stereo Pass Through racks I was using for Aux Send / returns showed up in the copied to edit as Rack type missing. I could select these racks. yet clicking on Delete to get rid of them poofs W. Right clicking on them to bring up the menu poofs W as well. The solution was to create another new edit and drag these faulty racks into it. This cleared up my rebuilt edit, yet not surprisingly, the racks still crash in the edit they were dragged into.

I doubt this has anything to do with the automation import, it sounds like something is being added to the Edit too many times though. I've not seen this myself.
Usually the only things that would be big enough to do that would be some huge plugin state.

If you open up the Edit in a text or XML editor it might be fairly obvious what's going on.
Can you share the large Edit with me via Dropbox, Google Drive or WeTransfer?
If I can tell what's causing it I'll fix it asap.

Also, Roland has fixed the Rack crashes you mention, it sounds like you've got some corrupt Racks though as they shouldn't be able to be created in this way..

[PierreG]

I doubt this has anything to do with the automation import, it sounds like something is being added to the Edit too many times though. I've not seen this myself. Usually the only things that would be big enough to do that would be some huge plugin state.

If you open up the Edit in a text or XML editor it might be fairly obvious what's going on.
Can you share the large Edit with me via Dropbox, Google Drive or WeTransfer?
If I can tell what's causing it I'll fix it asap.

Dug into this as suggested, which I was planning on doing. Looking at the contents of the edit file revealed a ton of data after the Youlean entry in the master section, which led me to the the source of the problem, which is indeed the Youlean Loudness Meter ver 1.9.0 / 1.9.1. I removed all instances of Youlean from the plugin tab, downgraded Youlean to version 1.5.0 and rescanned plugs. Removing Youlean from the master in the troubled edit, reinserting ver 1.5.0 then saving the edit, miraculously trimmed the edit size down from over 120 mb to 1.5 mb. I have the bloated edit file uploaded to Google Drive if you still want me to share it.

Update: Left the edit with the regressed Youlean plug (1.5.0) placed in the master section idle for a few hours and came back to see that it had grown by 30mb, thus the issue remains intact.

Also, Roland has fixed the Rack crashes you mention, it sounds like you've got some corrupt Racks though as they shouldn't be able to be created in this way..

Cool on the Rack crash fix. Created in which way? What to do regarding corrupt Racks?

[HansP]

My workaround for Rack issues is to export a (good) rack to xml preset format.
Sometimes rack parameters don't get loaded correctly the normal way, opening an edit. Culprit might be a plugin. Then I know that I must import the rack from the file, and sometimes must delete and remake all rack instances of this one in the mix, esp. when it crashes.

-
Automation into racks is sometimes quirky, esp. when the rack sits in the mastering section.

The [>] button under the track name opens and closes all automation tracks of the actual track.
After I edited some automation, then close the automation track, and after some listening and other editing, I open these automation tracks once more, as soon as I click and drag an automation point, or double click on the automation curve to create a new point, the poof crash may occur.
Suspicion: either there is something with "out of buffer memory" for the click (or copy-paste when duplicating tracks or curves or rack instances), or the connection from the automation curve on screen to the plugin internal ID and particular parameter somehow broke off during that re-opening.
Also there is a clear issue with recreating racks from preset, and when the mix edit has automation for that rack already. Either it must recreate all these internal links with some good heuristics, because it is the same rack anyway, or it must delete the automation because its object got lost.
Thus, it would be useful to export an automation curve to xml, and on import, assign it to a certain plugin and parameter. (Would spare some mouse exercises and possible buffer overflows.)

This was observed with T6, but I describe it here because the mentioned issues look a bit similar.

[dRowAudio]

My workaround for Rack issues is to export a (good) rack to xml preset format.
Sometimes rack parameters don't get loaded correctly the normal way, opening an edit. Culprit might be a plugin. Then I know that I must import the rack from the file, and sometimes must delete and remake all rack instances of this one in the mix, esp. when it crashes.

This shouldn't be the case, this is most definitely a bug we'd like to fix if we can reproduce it.
My main concern is that you say these findings are with T6? Automation has been completely re-written and designed with W9 in order to support macros and modifiers.
I'm not saying the issues don't still exist (they could have been missed or new bugs introduced in this process) but we'd need some reproducible steps in W9 before we can take a closer look.

Automation into racks is sometimes quirky, esp. when the rack sits in the mastering section.

The [>] button under the track name opens and closes all automation tracks of the actual track.
After I edited some automation, then close the automation track, and after some listening and other editing, I open these automation tracks once more, as soon as I click and drag an automation point, or double click on the automation curve to create a new point, the poof crash may occur.
Suspicion: either there is something with "out of buffer memory" for the click (or copy-paste when duplicating tracks or curves or rack instances), or the connection from the automation curve on screen to the plugin internal ID and particular parameter somehow broke off during that re-opening.
Also there is a clear issue with recreating racks from preset, and when the mix edit has automation for that rack already. Either it must recreate all these internal links with some good heuristics, because it is the same rack anyway, or it must delete the automation because its object got lost.
Thus, it would be useful to export an automation curve to xml, and on import, assign it to a certain plugin and parameter. (Would spare some mouse exercises and possible buffer overflows.)

This was observed with T6, but I describe it here because the mentioned issues look a bit similar.

As above, do you have some reproducible steps in W9 that show these crashes?
It's not likely to be an "out of buffer memory" error but a dangling pointer as the old automation may not have been correctly cleared away. I'm struggling to picture the process by your description though, perhaps some bullets might help?

Thanks!