AuburnSounds / AuburnSounds/Dplug
Bus concept, more semantics with channels?
- Dominant language
- D
- Stars
- 564
- Forks
- 34
- PR merge metrics
- No merged PRs in 30d
Description
Instead of N ins, M outs, a plugin would specify buses and each buses would have a (potential?) number of channels.
For VST 2.4 the bus would be flattened.
This item would require to put more knowledge of bus and channels into the client (currently they only exist in the audio callbacks), in order to implement bypass and other things in this place too.
Some things are in clients derived implementation when they should be in parent.
Hopefully this would allow to be more harmonious with how AU work, and handle mono and stereo buses likewise. The main problem is that I know next to nothing about VST3 and AAX, and that IPlug is like that for a reason.
Contributor guide
Research direction
No files or tests are named. Start by tracing the audio callbacks and the client-derived versus parent implementations, then compare the stated VST 2.4, VST3, AAX, and AU constraints. Done should define consistent bus and channel semantics that support the client-side behaviors mentioned, including bypass, without leaving duplicated knowledge in derived clients.
Written by the indexing model from the issue text.
Assessment
- Domain
- audio-video-rtc
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100