Repository navigation
Put effects on the audio plugins and show how each is doing - #4
Merged
Merged
Conversation
Brack.NET 1.2.0 puts a chain of effects on each instrument and on the master, and meters each chain. The audio plugins window is laid out again around them: a card for each instrument with its MIDI lamp, its level, its CPU load and its effects, which can be bypassed and dragged into order; the master's effects after the cards; and the output's device, level, load and dropouts above its settings. Instruments and effects are added from a list that can be narrowed, which offers only the effects built for the CPU their chain runs on. An editor's hold on the audio ends when Brack says it closed, which it now does for the editors a reload or a removal takes with the chain. A rack with only master effects is saved on closing. The view model's tests keep the scan's cache in a settings folder of their own.
The buffer is kept in Brack's session in frames, worked out from the length chosen at the rate the output device runs at. While the audio is stopped that rate came from the device list, its highest, which need not be the one the device runs at shared. Brack now opens the device to tell it (BrackLibrary.AudioDeviceRate).
Brack now refuses a message to a plugin that failed to load or crashed (MidiSendResult.NotLoaded) rather than letting its queue fill, so a full queue means only that messages come faster than the plugin takes them. The rack's status is read again only for a refused message, to say Brack's reason. A test sends to the crashed instrument before reloading it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Puts effects on the audio plugins and shows how each is doing, and takes Brack's word for the output device's rate and for why a plugin refuses MIDI.
Effects and meters
Brack.NET 1.2.0 puts a chain of effects on each instrument and on the master, and meters each chain.
BrackVersiongoes to 1.2.0.BrackLibrary.Architecture), as Brack runs a chain in one process.BrackLibrary.DescribeSession).The output device's rate
The buffer is kept in Brack's session in frames, worked out from the length chosen at the rate the output device runs at. While the audio is stopped that rate came from the device list, its highest, which need not be the one the device runs at shared. Brack now opens the device to tell it (
BrackLibrary.AudioDeviceRate).Refused MIDI
Brack now refuses a message to a plugin that failed to load or crashed (
MidiSendResult.NotLoaded) rather than letting its queue fill. A full queue so means only that messages come faster than the plugin takes them, and a refused message says Brack's reason. Playback stops on it with that reason, as on any output that is lost.Testing
dotnet test, 951 tests, with Brack beside.