SWAM Trombone has different output on playback vs export

[Sengin]

Tiny repro attached, includes .reason file, an exported wave file, and a wave file recorded by loopback recording (via Audacity).

I noticed that with SWAM Alto Trombone, I get different output depending on if I'm listening to it via playback or by exporting to a file. I'm pretty sure that the playback version is correct. The exported version seems like it gets squashed, time-wise, so that the note starts later than it is supposed to. This happens with all the SWAM trombones, but not the SWAM saxes. I can sort of work around this by moving the note start earlier by about a 1/32nd triplet or so, but it does change the groove a bit. I also can't just slightly nudge the note un-snapped - it appears there's a min duration extra that's needed.

Anybody else run into this? Because it happens to all the trombones but not to the saxes, I assume this is a SWAM bug, but maybe not?

[EverybodyNeedsA303]

Tiny repro attached, includes .reason file, an exported wave file, and a wave file recorded by loopback recording (via Audacity).

I noticed that with SWAM Alto Trombone, I get different output depending on if I'm listening to it via playback or by exporting to a file. I'm pretty sure that the playback version is correct. The exported version seems like it gets squashed, time-wise, so that the note starts later than it is supposed to. This happens with all the SWAM trombones, but not the SWAM saxes. I can sort of work around this by moving the note start earlier by about a 1/32nd triplet or so, but it does change the groove a bit. I also can't just slightly nudge the note un-snapped - it appears there's a min duration extra that's needed.

Anybody else run into this? Because it happens to all the trombones but not to the saxes, I assume this is a SWAM bug, but maybe not?

What versions of the SWAM VSTs are you running and on what OS and version of Reason?

[Sengin]

Should be the newest everything - SWAM 3.7.0, Win10, and Reason 12.6.1d72. Tried vst2 and vst3 versions.

Edit: I also tried SWAM 3.6.0 and it still repros.

[joeyluck]

Technically the latest is 3.7.1 as of a few days ago.

Does it make a difference if you nudge the entire song to be 1 bar in and then export with silence at the beginning?

[Sengin]

I updated to 3.7.1 and the same.

Nudging the entire song by a bar doesn't affect it. In the full song, there are multiple cases of the note being cut short - this was just the most minimal of a repro I could find. It appears to be related to the rhythm or the offset - it seems more likely to happen if the first note in a while does not occur on the downbeat/quarter - in this case, the full song, and in another song, it only happens when the first down of the clip ('the first note in 'a while') starts on an eighth note offset into a beat. Note that extending the clip doesn't matter, and it doesn't mean that every note that starts off the downbeat is affected.

[joeyluck]

Ok gotcha. I only have SWAM strings, so I can only check that. I would report it to Audio Modeling. If you're on facebook, they have a group where you might have a better chance of responses from other SWAM Trombone users https://www.facebook.com/groups/3682115991838947

Does it make any difference if you bounce in place? Or does it result in the same when doing that?

[Sengin]

I deleted facebook a few years ago, but I'll be opening a support ticket. I just didn't want to do that if it was a Reason vst3 issue - I know the support for them is relatively new and there were a few bugs (e.g. the Pro-Q 3 solo band not working, but was fine in the vst2 version).

Good idea about bouncing - it appears that it uses the same backend as exporting as it does repro with a bounce in place. That is, the generated audio also has that first note time-squashed. What's REALLY interesting though is that when bouncing, *both* phrases are time-squashed. If I export, the first phrase is normal and only the second is squashed.

[joeyluck]

Yeah that's weird. Do you have any other DAW to test with?

[Sengin]

I do not, unfortunately.

[jam-s]

This sounds like another of those plugins which does not cope with non-realtime rendering (like East West Symphony). It might be a quirk in the implementation of Reason, but the plugin might be at fault also by not following the VST spec closely.

[EverybodyNeedsA303]

Should be the newest everything - SWAM 3.7.0, Win10, and Reason 12.6.1d72. Tried vst2 and vst3 versions.

Edit: I also tried SWAM 3.6.0 and it still repros.

I have SWAM on Mac and it doesn't do this for me. i did have a separate bug where opening the plugin would crash Reason, but I fixed this by changing in the interface options for it to use OpenGL to render its interface instead of the default setting.

[ljekio]

This sounds like another of those plugins which does not cope with non-realtime rendering (like East West Symphony). It might be a quirk in the implementation of Reason, but the plugin might be at fault also by not following the VST spec closely.

Almost it is. I had a similar experience and when rendering in a heavily loaded project, the my brass section were rendered sporadically out of timing.
I assumed that it was from a large chipboard load and was also somehow connected with an external sound card. And, of course, because the SWAM is not a normal instrument and has a lot of CC messages when using a wind controller.
There is an option in the settings related to audio rendering, you can try to disable it. But I only had this in one project and in the end I still had to quantize my stubs somewhere.

[robussc]

Something I just found with SoundPaint is it (at least) needs some time to get rolling so extending the part at the lead in to the notes helped a bunch (I was also getting a different result on export vs playback). Perhaps Reason manages VSTs differently from other DAWs (only sending timing info while the part is under the playback head?) Anyway I hope that might help?

[Sengin]

I finally have an update on this, after going back and forth with Audio Modeling support, Reason support, and Reason Beta support after joining the reason beta program to get access to the next layer of support.

This looks to be a bug in SWAM (at least Trombone, if not others) that's related to BOTH the audio buffer size set in Edit | Preferences | Audio, AND the positioning of the midi notes. Sometimes shifting the notes by a 16th is enough to move into the realm of the bug, but anything an 8th or greater won't. So for me, I get "sometimes fine sometimes mangled" behavior if a note that is 1/16th in length starts at position X.X.4.0. If my buffer size is 4096 I can nearly always get the mangled note, but at 2048 it's normal. Abelton has no 4096 buffer size setting, but reason support was able to see some sort of similar tendency to mangle the note the higher the buffer size.

2048 is glitchy audio with pops and cracks for me during realtime playback, but it's easy enough to keep it at 4096 during realtime playback but bump it down to 2048 in the render. I can use this as a workaround until the bug can be fixed in SWAM.

@robussc might be worth a shot when trying this with SoundPaint if you are still seeing some weirdness

[Sengin]

...Or not! After digging into this more, there is a setting in Audio preferences under Performance called "Render audio using audio card buffer size setting." If this is checked, the problem shows up. If unchecked, no problems. So I would recommend playing around with this setting if you are seeing this type of issue.

[Sengin]

Doesn't look like I can edit, so unfortunately have to make this a triple post. Here's everything I've found out about this (my Reason support ticket is closed so I don't expect any more information unless SWAM fixes it):

This is most definitely a bug in SWAM Trombones (possibly all of Brass but the other types of instruments don't seem to have this) related to the buffer size - the larger the buffer the more noticeable the problem is. It affects Abelton as well, but since Abelton's max buffer size is 2048 it is far more noticeable in Reason, which defaults to 4096 as a buffer size for DX audio drivers in Windows. Based on testing Reason support did, my interpretation is that SWAM Trombones shouldn't be used with larger than a 512 sample buffer. However, instead of messing with buffer sizes (which can affect realtime playback - a 2048-sample buffer on the DX driver produces glitches and stutters during realtime playback) or installing ASIO4ALL (which is low latency enough to run 512 realtime perfectly for me but requires exclusive access of your output device), you can just uncheck the "Render audio using audio card buffer size setting" option underneath the buffer size. Leaving this option unchecked will cause Reason to use a buffer size of 64 during rendering/bouncing (but keep using the specified buffer size for realtime playback). I don't know why the bug only reproduces during rendering/bouncing but not realtime playback, even if the same buffer size is used - Reason support wasn't able to nail this down, and since this affects another DAW it's not really on them to.

Hopefully in the worst case SWAM can update their FAQ/Known Issues to include this.

TL;DR:
- bug in SWAM, also affects Abelton
- easiest workaround: uncheck "Render audio using audio card buffer size setting" in Preferences | Audio
- other workaround: install ASIO4ALL, set Reason to use this audio driver in Prefernces | Audio, and set buffer size to 512 or lower (other apps may not have apps while running Reason)
- other workaround: reduce buffer size (may have adverse affects for realtime playback)

[buddard]

Another workaround is to set up the plug-in's mixer channel as a recording source in Reason, and then record it in real time onto a new audio track. It's of course a chore to do this every time you change something on the instrument track, but at least exporting the song/stems should work as expected afterwards.

[robussc]

Something I noticed a different brass sim VST (name eludes me first thing in the morn) is that it needed some warmup time from the sequencer.. If the start of notes was right at the start of the part it would glitch (and mostly only during export), I extended the start of the part to give it some preroll time and that eliminated it for me.

Hope that might be useful?