Variable size buffers

MusE is a DAW for Linux with both MIDI and Audio editing. https://muse-sequencer.github.io

Moderators: MattKingUSA, khz, spamatica

Post Reply
folderol
Established Member
Posts: 2069
Joined: Mon Sep 28, 2015 8:06 pm
Location: Here, of course!
Has thanked: 224 times
Been thanked: 400 times
Contact:

Variable size buffers

Post by folderol »

Does muse produce these for plugins or is it just fixed sized ones? i.e. change buffer sizes based on incoming events.

If so, is this always on, or enabled at user request?
The Yoshimi guy {apparently now an 'elderly'}
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Variable size buffers

Post by Tim E. Real »

Not sure the question exactly.
If you mean overall audio buffer segment size, no, it is fixed by what Jack or our dummy or RTAudio driver dictates.

If you mean midi event buffers that are passed to the plugins, yes, of course they are a variable size.

If you mean frame-accurate variable plugin 'run lengths' according to frame-accurate changes in plugin controllers, YES!
MusE breaks up the fixed overall audio segment size into variable sized run-lengths according to changes in controllers.
Thus MusE has frame-accurate audio and plugin controller handling.
[Edit:] And the minimum 'time-slice' that MusE will break up the segment is adjustable in Settings.
This avoids overloading the app or the plugin if a lot of frame-by-frame controller changes are happening too close together.

Side note: If you did mean the first answer, no that's not possible since audio plugins want a fixed buffer size
(barring controller changes as mentioned in the third answer).
What that describes is more like a streaming system where a plugin asks for a variable buffer size each time.
I brought this up on LAD once.
I pointed out that there is a whole class of plugins that all of our current real-time plugin systems lack:
Time stretchers.
That's because these plugins need to ask for a variable amount of input data each cycle and produce a variable amount of output data.
So for that reason, in my yet-to-be-merged branch 'audio_convert' which has built-in time stretching and automatic real-time (live)
wave file sample rate conversion, I had to do some work.
I had to construct an entire new plugin ecosystem to talk to these plugins.
[Edit 2:] Actually none of them are really 'plugins' at all since there is no plugin system that supports them. Instead they are libraries.
It has plugin discovery and so on just like the other plugin systems.
I designed it to be expandable so that new plugins could be supported as quickly as possible.
There are certain high-quality commercial plugins out there, so I was aiming to support them if the user purchased them.
folderol
Established Member
Posts: 2069
Joined: Mon Sep 28, 2015 8:06 pm
Location: Here, of course!
Has thanked: 224 times
Been thanked: 400 times
Contact:

Re: Variable size buffers

Post by folderol »

Thanks a lot Tim. That answers my question very nicely - an with extra info :)
I'm currently trying to improve Yoshimi's LV2 support (from a position of very little knowledge) and with my 'internal' build I currently seem to get excellent results from all except one host. I'm not saying which it is, but it's not muse :wink:
The Yoshimi guy {apparently now an 'elderly'}
Post Reply