Master effects #6359

vsverchinsky · 2024-04-29T07:41:33Z

Resolves: #6346

Known issues:

UI: Master effects section does not fit automatically to the contents
No micro fades applied to solo/gain change
Latency increased for track controls in real-time (delay between the moment you press TC button and the moment you hear changes is audiable)
I signed CLA
The title of the pull request describes an issue it addresses
If changes are extensive, then there is a sequence of easily reviewable commits
Each commit's message describes its purpose and effects
There are no behavior changes unnecessary for the stated purpose of the PR

Recommended:

Each commit compiles and runs on my machine without known undesirable changes of behavior

QA:

LWinterberg · 2024-04-29T08:21:00Z

No micro fades

As in, it doesn't honor the micro-fades preference?

dozzzzer · 2024-04-29T10:52:31Z

@vsverchinsky when playing a mono clip, only the left channel is playing audio:

saintmatthieu

Haven't finished yet the review, but stumbled on a potential crash.

saintmatthieu · 2024-05-08T09:07:43Z

libraries/lib-realtime-effects/RealtimeEffectManager.cpp

@@ -68,6 +72,14 @@ void RealtimeEffectManager::Initialize(

   // Leave suspended state
   SetSuspended(false);
+
+   //Register the master channel group


I don't know if this comment is relevant only to the following two out-commented lines or to what follows, too. Why keep the dead code?

saintmatthieu · 2024-05-08T09:15:13Z

libraries/lib-realtime-effects/RealtimeEffectManager.h

@@ -50,6 +50,8 @@ class REALTIME_EFFECTS_API RealtimeEffectManager final :
   public Observer::Publisher<RealtimeEffectManagerMessage>
 {
 public:
+   static const ChannelGroup* MasterGroup;


Looks like even the pointer should be const, i.e., static const ChannelGroup* const MasterGroup;
Also, I'd prefer the initialization to take place here as well for clarity, rather than in the source file.

saintmatthieu · 2024-05-08T09:18:29Z

libraries/lib-realtime-effects/RealtimeEffectManager.h

@@ -151,9 +153,10 @@ class REALTIME_EFFECTS_API RealtimeEffectManager final :
   };

   void ProcessStart(bool suspended);
+


trailing spaces

saintmatthieu · 2024-05-08T09:18:53Z

libraries/lib-realtime-effects/RealtimeEffectManager.h

@@ -202,7 +200,7 @@ class REALTIME_EFFECTS_API RealtimeEffectManager final :
   }

   AudacityProject &mProject;
-   Latency mLatency{ 0 };
+   //Latency mLatency{ 0 };


Why not just removing it?

saintmatthieu · 2024-05-08T09:21:44Z

libraries/lib-realtime-effects/RealtimeEffectManager.cpp

+   //mRates.insert({MasterGroup, sampleRate});
+
+   VisitGroup(MasterGroup, [&](RealtimeEffectState& state, bool) {
+      scope.mInstances.push_back(state.AddGroup(nullptr, numPlaybackChannels, sampleRate));


nullptr aka MasterGroup ?

If so I'd prefer MasterGroup over nullptr, in case one looks for all places where it's used.

saintmatthieu · 2024-05-08T10:00:18Z

libraries/lib-audio-io/AudioIO.cpp

@@ -148,6 +148,7 @@ struct AudioIoCallback::TransportState {
               assert(false);
               continue;
            }
+            //TODO: initialize with sequence own channels count and sampleRate


Why ? Isn't this used by AllocateChannelsToProcessors to "plug" an effect's output channels to the number of playback channels. Why should this change with the master channel?

The comment isn't specifically about master channel.
When we allocate two mono effects to one stereo track there is at least one problem with UI : you can't see the output of the second channel.
I think configuring effects to process samples in native track format and rate could have benefit of reducing CPU load in case if playback sample rate is higher compared to playback rate. But that may be conceptually wrong.

Regarding the CPU, I don't know, it looks like there is no negotiation at the moment: the framework dictates the sampling rate to the effect instances, which I guess is much simpler. Also, I think resampling is inevitable, so I'm not sure we want to try and minimize it.
My point is that this TODO should probably be tempered with some doubt, e.g., "consider initializing (...) because (...)"

saintmatthieu · 2024-05-08T10:22:09Z

src/RealtimeEffectPanel.h

@@ -81,5 +86,9 @@ class RealtimeEffectPanel : public wxPanel
   void SetFocus() override;

 private:
+
+   void MakeTrackEffectsPane();


I think correct English would be MakeTrackEffectPane (even if there's more than one effect).

saintmatthieu · 2024-05-08T11:00:50Z

libraries/lib-audio-io/AudioIO.cpp

+      }
+   }
+
+   auto samplesAvailable = std::min_element(


This crashes when playing a MIDI file on an empty project, because mPlaybackSequences and, consequently, mProcessingBuffers, are then empty.

Maybe a solution: the size of mMasterBuffers equals the number of playback channels, maybe it could be used instead.
Also, AFAICS these buffers always have the same size, so a simple mMasterBuffers[0].size() would be more expressive and sufficient.

Or mPlaybackBuffers.

saintmatthieu

Finished reviewing the first commit (the audio part) ; nothing major besides that crash, but hopefully this is an easy fix.
Please remove the dead code ; I don't see why it should be kept, and it's noisy and sometimes confusing.

saintmatthieu · 2024-05-08T11:24:54Z

libraries/lib-audio-io/AudioIO.cpp

-            mOldChannelGains.resize(mPlaybackSequences.size());
-            size_t iBuffer = 0;
+            // Bug 1763 - We must fade in from zero to avoid a click on starting.
+            //mOldPlaybackGain = 0.0f;


saintmatthieu · 2024-05-08T11:25:08Z

libraries/lib-audio-io/AudioIO.cpp

-                  mPlaybackBuffers[iBuffer++] = std::make_unique<RingBuffer>(
-                     floatSample, playbackBufferSize);
-
+


trailing spaces

saintmatthieu · 2024-05-08T12:01:31Z

libraries/lib-audio-io/AudioIO.cpp

-   // Avoiding std::vector
-   const auto pointers = stackAllocate(float*, mNumPlaybackChannels);
+   // Do any realtime effect processing, after all the little
+   // slices have been written.


I don't see any side effect if pScope == nullptr, so shouldn't the if (pScope) be on this line?

Paul-Licameli · 2024-05-09T11:50:37Z

libraries/lib-realtime-effects/RealtimeEffectManager.h

@@ -166,26 +171,21 @@ class REALTIME_EFFECTS_API RealtimeEffectManager final :
   // using StateVisitor =
      // std::function<void(RealtimeEffectState &state, bool listIsActive)> ;

-   //! Visit the per-project states first, then states for group
+   //! Visit states for group


" or for the master when group is null"

Paul-Licameli · 2024-05-09T13:00:54Z

libraries/lib-audio-io/AudioIO.cpp

@@ -2015,104 +2023,208 @@ bool AudioIO::ProcessPlaybackSlices(
         // warping
         if (frames > 0) {
            size_t produced = 0;
+            // Check for asynchronous user changes in mute, solo status


Comment "mPlaybackBuffers correspond many-to-one with mPlaybackSequences" above this line is no longer correct

Paul-Licameli · 2024-05-09T13:09:54Z

libraries/lib-audio-io/AudioIO.cpp

+               auto& buffer = mProcessingBuffers[iBuffer++];
+               const auto offset = buffer.size();
+               //there could be leftovers from the previous pass, don't discard them
+               buffer.resize(buffer.size() + frames, 0);


I would add a comment that this resize is expected not to allocate memory in the worker thread, because sufficient size should have been reserved in AllocateBuffers. Perhaps, test capacity before and after and assert no change.

Paul-Licameli · 2024-05-09T13:36:36Z

libraries/lib-audio-io/AudioIO.cpp

+                     .0f);
+               }
+               else
+                  //TODO: mixer->Process() may be wasting CPU cycles


I don't think the mixer can be properly eliminated in the case that it does resampling of a track whose rate does not match the device output rate, or there is a time track. There will be some state in the resampler dependent on previous input.

However, note that the mixer stands as a producer in relation to this function which is its consumer. Perhaps, if it really matters, another thread could mix in advance.

But all that effort at overlapping computation may be unnecessary because this thread really spends most of its time idle anyway, going faster than the ultimate real-time consumption of its output.

Or then again maybe it might matter in future because we want to have ever more capacity for complicated calculations like more effects, more stretching, more pitch shifting.

Or again, maybe you were thinking of power consumption, not performance.

I though that mixer could be "advanced" without doing any actual work

Paul-Licameli · 2024-05-09T13:41:42Z

libraries/lib-audio-io/AudioIO.cpp

+               else
+                  //TODO: mixer->Process() may be wasting CPU cycles
+                  //TODO: fade out smoothly
+                  std::fill_n(buffer.data() + offset, frames, 0);


I notice that as part of this PR you have moved the logic to silence tracks (which might be driven by unpredictable presses of the mute buttons by the user) from the low-latency thread to this high-throughput thread.

Was that for simplification of the former, so that it does less work? Or some other reason?

Does this comment mean you have not yet restored the microfading feature? (I have not yet read enough to answer that for myself)

I think I like this change because as I recollect, the microfading had a dependency on the buffer size given to audacityAudioCallback which can depend on operating system or larency settings. That should not be: the duration of the fade in or out should be independent of that.

Was that for simplification of the former, so that it does less work? Or some other reason?

The reason is that we can't do master effects processing on low-latency thread and that processing should happen after all the tracks have been mixed into playback channels.

Does this comment mean you have not yet restored the microfading feature? (I have not yet read enough to answer that for myself)

Micro-fading isn't completely restored, it doesn't happen when you move gain, pan sliders or press solo/mute buttons.

saintmatthieu

Not requesting changes because I'm not certain of my analysis, but I think there is another bug, already present in the first commit but that I missed before.

saintmatthieu · 2024-05-10T06:58:34Z

libraries/lib-audio-io/AudioIO.cpp

   // Choose a common size to take from all ring buffers
   const auto toGet =
      std::min<size_t>(framesPerBuffer, GetCommonlyReadyPlayback());

+   // Poke: If there are no playback sequences, then the earlier check


I don't know what earlier check is meant here. Could it be that this comment is also outdated?

The comment refers to what now happens inside CallbackCheckCompletion. Amend the comment to make that more explicit. And it's now "below" not "above".

saintmatthieu · 2024-05-10T07:01:39Z

libraries/lib-audio-io/AudioIO.cpp

@@ -2682,19 +2719,21 @@ bool AudioIoCallback::FillOutputBuffers(
      return true;


A little bit higher, line 2712 on this commit, is the line float *outputFloats = outputBuffer;, which only seems to be an alias to the same thing, maybe a remnant of older code. Would you remove it if you get the chance?

saintmatthieu · 2024-05-10T07:21:42Z

libraries/lib-audio-io/AudioIO.cpp

-   for(auto& buffer : mMasterBuffers)
-      std::fill_n(buffer.begin(), samplesAvailable, 0);
+   //introduced latency may be too high...
+   //but we don't discard what already was written


There might be a mini bug here: if adding a real-time effect during playback increased latency such that samplesAvailable becomes 0, what would be played for that frame would be the samples of the previous mPlayoutBuffers, possibly leading to a repeated playout of the last few ms.
Solution might be to return false, such that the AudioThread doesn't read the content of mPlayoutBuffers ?
It would be worse if a real-time effect had variable latency, but I don't think there's a use case for that.

That would apply to the next if(samplesAvailable == 0) too.

I think the answer to your question is in FillPlayBuffers. If for some reason samplesAvailable will be zeroed, then there will be more processing passes until GetNeeded() == 0. Otherwise if I return false as you suggest then extra buffer exchange step will be initiated for same frame, which I think is less preferrable.
May be we should test how it works now with latency values that are much larger than our regular buffer sizes

saintmatthieu · 2024-05-10T08:00:00Z

libraries/lib-audio-io/AudioIO.cpp

+   //Prepare master buffers.
+   //These buffers may also contain leftovers from the previous pass
+   //Remember initial offset for each of them
+   const auto masterOffsets = stackAllocate(int, mMasterBuffers.size());


I have doubts about the correctness of the handling of latency for the master channel.
The discardable value returned by a real-time effect is the number of leading samples that can be discarded.
For the track effects, this is indeed what is done:

for(int i = 0; i < seq->NChannels(); ++i) { auto& buffer = mProcessingBuffers[bufferIndex + i]; buffer.erase(buffer.begin(), buffer.begin() + discardable); }

For the master track, however, no leading samples are discarded, and then

unsigned bufferIndex = 0; for(auto& buffer : mMasterBuffers) { mPlaybackBuffers[bufferIndex++]->Put( reinterpret_cast<constSamplePtr>(buffer.data()), floatSample, samplesAvailable, 0 ); }

which means trailing samples are discarded instead. It was already that way in the previous commit but I missed it.

If I'm correct, the consequence of this mistake would be that, if the master channel has an effect that adds delay, an artefact due to zeroed audio would be heard at the beginning of playback.

I also don't see the necessity of masterOffsets. I don't think there can be left-overs from one ProcessPlaybackSlices to the next, as it would mean this method would produce more audio samples than asked for, and I don't see it to be the case.

The problem does exist indeed. In the attached video, you can hear an audible crackle at the beginning of the playback with a non-zero latency effect (TDR Limiter) added to the stack:

Screen.Recording.2024-05-10.at.16.15.45.video-converter.com.mp4

Thanks @dozzzzer .

Doing latencies really right is a known bit of technical debt. I have had ideas. I didn't find time to elaborate and share them yet.

Removing change request because the particular bug was fixed.

Paul-Licameli · 2024-05-10T12:47:14Z

libraries/lib-audio-io/AudioIO.h

   // Temporary buffers, each as large as the playback buffers
   std::vector<SampleBuffer> mScratchBuffers;
   std::vector<float *> mScratchPointers; //!< pointing into mScratchBuffers

   std::vector<std::unique_ptr<Mixer>> mPlaybackMixers;
+   std::unique_ptr<Mixer> mMasterMixer;


Paul-Licameli · 2024-05-10T13:03:33Z

libraries/lib-audio-io/AudioIO.cpp

+      mLastPlaybackTimeMillis = ::wxGetUTCTimeMillis();
+      return false;
+   }
+
   // The drop and dropQuickly booleans are so named for historical reasons.


Comment refers to variables that no longer exist

Paul-Licameli · 2024-05-10T14:04:37Z

libraries/lib-audio-io/AudioIO.cpp

+      }
+   }
+
+   //samples at the beginning of could have been discarded


delete "of"

Paul-Licameli · 2024-05-10T14:06:58Z

libraries/lib-audio-io/AudioIO.cpp

+   //introduced latency may be too high...
+   //but we don't discard what already was written
+   if(samplesAvailable == 0)
+      return progress;


I am reminded that the handling of latency is still not satisfactory. I had ideas for fixing it that I have not found time to implement.

Paul-Licameli · 2024-05-10T14:28:19Z

libraries/lib-audio-io/AudioIO.cpp

+      unsigned bufferIndex = 0;
+      for(const auto& seq : mPlaybackSequences)
+      {
+         //TODO: apply micro-fades


Is that really TODO? I think you have conserved the micro-fade logic on the consumer side in FillOutputBuffers

IIUC that one handles the changes in the volume slider, which are global. This is for the track-specific mute/unmute.

saintmatthieu

#6359 (comment)

Paul-Licameli · 2024-05-10T14:50:09Z

I have completed a review of changes in AudioIO.cpp.

If my contribution of per track meters is also wanted, there is a lot of needed work to make these compatible.

I may volunteer my own very different rewrite of AudioIO.cpp to support a master channel in the right way.

I understand that:

The sequence of transformations on individual tracks includes time warping (for time track), muting (of individual tracks), effects (stacked on single tracks), panning, in that order.
Then you mix tracks and apply the master stack, on the PRODUCER side of the RingBuffer. (As for individual stacks. We must avoid who knows what computations in opaque code, on the low-latency consumer side.)
Micro-fading is still applied on the consumer side.
There are only one or two RingBuffers corresponding to the device output channels.

The old version, without a master stack, differed in these ways:

There was a RingBuffer for each WaveChannel.
Applying mute and pan, and mixing of the RingBuffer outputs, was done on the consumer side.

Questions might arise about subtle differences of results, moving the muting before the effect processing. (Is it better with your change? Have you tried muting a track with a reverb, during play -- which before, would just mute it at once, but after, might instead produce the decaying tail of what was unmuted?)

Also, whether pan should apply before a per-track effect or after: It might make a difference for certain effects like reverbs that are not simple LTIs but might work in terms of mid and side channels. (@saintmatthieu, opinion?)

More later...

Paul-Licameli · 2024-05-13T14:31:55Z

More:

The existing ring buffers should not be removed. Ring buffers for the master mix should be added. The consumer thread should take equal samples out of all of them. Only the samples from the master mix are stored in the output buffer of the audio io callback.

This allows future development to send the buffers of pre-mixed per-track data inter-thread, back to the master thread for drawing.

See SendVuInputMeterData and SendVuOutputMeterData which now do such inter-thread communication: but I would need to send other buffers too.

My thinking is this: the consumer thread needs to have access to intermediate states of calculation of the mix samples, corresponding in time to the ultimate output. Those intermediates should be sent to other code that performs graphical display, keeping as closely synchronized as possible with the real-time playback. That synchronization will not be perfect, given the reality of frame refresh rates.

Still, the latency of the RingBuffer itself should be accounted for in that drawing update. Sending the per-track information to the main thread more directly from the producer thread would make less perfect synchronization of the display.

Therefore, more data should be travelling through ring buffers from the high-throughput but variable-latency producer thread, to the more regularly updating consumer thread.

saintmatthieu · 2024-05-15T04:36:48Z

libraries/lib-audio-io/AudioIO.cpp

@@ -2036,8 +2037,15 @@ bool AudioIO::ProcessPlaybackSlices(

               auto& buffer = mProcessingBuffers[iBuffer++];
               const auto offset = buffer.size();
+               const auto toConsume = std::min(


What are these new lines fixing ? It looks like we are now ensuring that no new memory is allocated in that function. This comes at the risk, though, that we provide less than frames samples, if for some reason the capacity of the buffer is insufficient. Wouldn't that be worse ?

I wonder if this change is motivated by the initial playback click that we hear in @dozzzzer 's video above. I suspect this not to be due to buffer allocation, but simply because he is playing a sine wave without any sort of smoothing envelope, and it's then completely normal to hear this click.

It looks like we are now ensuring that no new memory is allocated in that function.

Yes

This comes at the risk, though, that we provide less than frames samples

Memory allocations are not better. The disadvantage of this code is that it's not capable to handle very large latencies (usually > 250ms).

I wonder if this change is motivated by the initial playback click that we hear in @dozzzzer 's video above

No, I did that in response to Paul's comment above

saintmatthieu · 2024-05-15T04:59:15Z

@Paul-Licameli good point about reverb.
I confirm that muting a track may not instantly mute the sound but any effect with a tail will continue ringing.
It may sound better but I don't think this is the wanted behaviour: muting is muting. What if the effect is a long echo ?
@LWinterberg ?

saintmatthieu · 2024-05-15T05:04:16Z

About panning before or after, yes, if the effect is non LTI, this would make a difference. If there is one place for panning and gain, I think it should be where it is a the moment, after the effect stack. I guess other DAWs do it that way, too (or may have also a "pre-gain"), and if a non LTI effect such as a compressor comes in, it will come with its own pre-processing gain parameter.
A mid/side encoding/decoding operation is a linear operation, though, so in that particular case it should not make a difference.

Will approve now, pending Vitaly's rework on the mute behaviour.

Paul-Licameli · 2024-05-16T11:16:09Z

I disapprove.

please wait to see my alternative that will be compatible with oerctrack meters.

expext it today.

saintmatthieu · 2024-05-16T13:58:27Z

Approving for now. My purpose is not to override @Paul-Licameli's disapproval, because maybe his alternative makes this very complex logic easier ? I'll leave up to @vsverchinsky to decide but I don't want to block QA anymore.

Paul-Licameli · 2024-05-16T14:03:54Z

Let it merge then: but my PR will begin with reversion of all the changes in AudioIO.cpp (not of other UI changes) and then a more careful stepwise rewrite.

QA will likely need to re-test everything involving sound quality, but not the UI changes.

chinakov · 2024-05-17T12:38:01Z

Found issues:

When a User adds MT-A Plugin by Mercurial to the Master Effects, and uses the built-in bypass feature, the audio played back is panned 100% to left, instead of stereo playback.
When a User adds Kilohearts Distortion plugin to the Master Effects, and playbacks some audio, full scale noise can be heard for a second after playback has been initialized.
If a User has added any Master Effects, and enabled them, the effects are not applied to files on file export (I am not sure what to expect here, should Master Effects render when they are enabled?)

LWinterberg · 2024-05-17T13:03:13Z

(I am not sure what to expect here, should Master Effects render when they are enabled?)

Yes!

Paul-Licameli · 2024-05-17T13:04:57Z

Let it merge then: but my PR will begin with reversion of all the changes in AudioIO.cpp (not of other UI changes) and then a more careful stepwise rewrite.

QA will likely need to re-test everything involving sound quality, but not the UI changes.

My changes are more complicated than expected.

However, I might be fixing long standing problems with effect latencies. Search for issues with “latency”

saintmatthieu · 2024-05-17T13:30:22Z

Looking into the export/render problem.

DavidBailes · 2024-05-20T07:46:28Z

@vsverchinsky . Serious accessibility issue, logged here: #6456

DavidBailes · 2024-05-20T08:07:17Z

@vsverchinsky . Another accessibility issue, logged here: #6457

vsverchinsky · 2024-05-22T14:59:45Z

libraries/lib-audio-io/AudioIO.cpp

@@ -1243,7 +1243,7 @@ bool AudioIO::AllocateBuffers(
               ));
               for(auto& buffer : mProcessingBuffers)
                  buffer.reserve(playbackBufferSize);
-


@saintmatthieu Please avoid unnecessary formatting changes if you don't change the line itself - it complicates the search through commit history and review process

vsverchinsky · 2024-05-22T15:04:28Z

libraries/lib-audio-io/AudioIO.cpp

@@ -2241,7 +2241,10 @@ bool AudioIO::ProcessPlaybackSlices(
         );
      }
   }
-
+
+   for(auto& buffer : mMasterBuffers)


There is a finally block already that does cleanup job

vsverchinsky · 2024-05-22T17:15:20Z

Completed review of @saintmatthieu commits 👍

vsverchinsky force-pushed the master-channel branch from 7c13e9c to 5eb496e Compare May 4, 2024 00:00

vsverchinsky marked this pull request as ready for review May 5, 2024 18:44

saintmatthieu self-assigned this May 6, 2024

vsverchinsky requested a review from saintmatthieu May 6, 2024 13:06

saintmatthieu previously requested changes May 8, 2024

View reviewed changes

saintmatthieu reviewed May 8, 2024

View reviewed changes

vsverchinsky force-pushed the master-channel branch from 5eb496e to 91823e4 Compare May 8, 2024 20:03

vsverchinsky requested a review from saintmatthieu May 8, 2024 20:03

Paul-Licameli reviewed May 9, 2024

View reviewed changes

saintmatthieu reviewed May 10, 2024

View reviewed changes

saintmatthieu self-requested a review May 10, 2024 08:09

Paul-Licameli reviewed May 10, 2024

View reviewed changes

libraries/lib-audio-io/AudioIO.cpp Outdated

}

}

//samples at the beginning of could have been discarded

Copy link

Collaborator

Paul-Licameli May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete "of"

Paul-Licameli reviewed May 10, 2024

View reviewed changes

saintmatthieu previously requested changes May 10, 2024

View reviewed changes

vsverchinsky requested a review from saintmatthieu May 13, 2024 15:14

saintmatthieu reviewed May 15, 2024

View reviewed changes

saintmatthieu approved these changes May 16, 2024

View reviewed changes

vsverchinsky force-pushed the master-channel branch from 9640a33 to cb589a0 Compare May 17, 2024 18:06

vsverchinsky force-pushed the master-channel branch 3 times, most recently from 6c76721 to a4856a2 Compare May 22, 2024 09:30

vsverchinsky commented May 22, 2024

View reviewed changes

saintmatthieu force-pushed the master-channel branch from 1f29456 to d37c90f Compare May 22, 2024 15:06

saintmatthieu assigned vsverchinsky May 22, 2024

vsverchinsky force-pushed the master-channel branch from 7925014 to 86a297a Compare May 22, 2024 20:23

vsverchinsky requested a review from saintmatthieu May 23, 2024 12:57

saintmatthieu approved these changes May 23, 2024

View reviewed changes

vsverchinsky and others added 4 commits May 27, 2024 09:05

AudioIO & realtime effects changes

329d172

Master effects UI

7438528

Tempo detection fix: don't analyse empty track

54447e2

Export renders master effect stack

c7b4779

vsverchinsky force-pushed the master-channel branch from c2848dc to c7b4779 Compare May 27, 2024 06:13

vsverchinsky merged commit 972b06e into audacity:master May 27, 2024
10 checks passed

vsverchinsky deleted the master-channel branch May 27, 2024 09:01

		@@ -151,9 +153,10 @@ class REALTIME_EFFECTS_API RealtimeEffectManager final :
		};

		void ProcessStart(bool suspended);

		mPlaybackBuffers[iBuffer++] = std::make_unique<RingBuffer>(
		floatSample, playbackBufferSize);

		@@ -2682,19 +2719,21 @@ bool AudioIoCallback::FillOutputBuffers(
		return true;

Master effects #6359

Master effects #6359

Conversation

vsverchinsky commented Apr 29, 2024 • edited by chinakov

LWinterberg commented Apr 29, 2024

dozzzzer commented Apr 29, 2024

saintmatthieu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

saintmatthieu left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Paul-Licameli May 9, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Paul-Licameli May 9, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

saintmatthieu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

saintmatthieu left a comment

Choose a reason for hiding this comment

Paul-Licameli commented May 10, 2024 • edited

Paul-Licameli commented May 13, 2024

saintmatthieu May 15, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

saintmatthieu commented May 15, 2024

saintmatthieu commented May 15, 2024

Paul-Licameli commented May 16, 2024

saintmatthieu commented May 16, 2024

Paul-Licameli commented May 16, 2024

chinakov commented May 17, 2024 • edited

LWinterberg commented May 17, 2024

Paul-Licameli commented May 17, 2024

saintmatthieu commented May 17, 2024

DavidBailes commented May 20, 2024 • edited

DavidBailes commented May 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vsverchinsky commented May 22, 2024

vsverchinsky commented Apr 29, 2024 •

edited by chinakov

saintmatthieu left a comment •

edited

Paul-Licameli May 9, 2024 •

edited

Paul-Licameli May 9, 2024 •

edited

Paul-Licameli commented May 10, 2024 •

edited

saintmatthieu May 15, 2024 •

edited

chinakov commented May 17, 2024 •

edited

DavidBailes commented May 20, 2024 •

edited