Thanks Albert and Stephane for the explanations.
I made the lexical shortcut of FAUST's polyphony as architecture files
seem part of FAUST to me... But sure, it is independant the FAUST-dsp
syntax.
The polyphony management is mostly falling in the control side, and the
negotiation with the DSP essentially confined to :
- knowing when a voice is busy or not.
- having a criterion (namely pitch or channel) to allocate a free voice
- having a criterion to steal a voice (oldest/softest/random/etc.
voice), when stealing is enabled
The voice-stealing strategy, and more generally-speaking the voice
allocation is *not* addressed by the MPE specifications as far as I can
see (only in the guideline
<https://docs.google.com/document/d/1vpjxoPHw82X3xyNvE6_hsDeL86vloNQZC83NHD8edow/edit?pref=2&pli=1#heading=h.ep4z2p1rbk4m>)
and left to the instrument maker.
I feel that what mess up this strategy is the tendency to tie a voice
allocation to a pitch, which use to make sense when music was played
with keyboards (sarcasm intended) as there is no two key with the same
pitch, but is absurd otherwise and really unconvenient in many cases. It
seems to me that this confusion is why polyphony handling in VST
instrument leave the user always a bit incertain about what will come
out of the synth.
It is also the way poly~ "note" messages are implemented in Max,
although it is possible to use whatever number (beyond the 0-127 range)
in place of the pitch to trigger a voice.
If the plan is to tend toward a unique "industry" implementation, then
probably the best option is to follow the MPE way and have a
"MPE-enabled" option on the DSP, which allocate voices based on the MIDI
channel, with a master zone as defined in the MPE specs.
When not MPE-enabled, the voice allocation can fall back to a
pitch-based polyphony. The confusion betwen pitch and voice is still
there and ugly, but that may be the best compromise between backward
compatibility and openness.
Personnally, I prefer a more open schema where the voice-number is an
explicit input parameter, as is the case with poly~ in Max. It allows
for more flexible designs in term of mapping, but that's not a
ready-made solution for all DAWs.
Vincent
Le 02/03/2016 21:20, Stéphane Letz a écrit :
Le 2 mars 2016 à 20:46, Albert Graef <aggr...@gmail.com> a écrit :
On Wed, Mar 2, 2016 at 2:44 PM, Vincent G. Listes <infopap...@yahoo.com.sg>
wrote:
Is there a document somewhere outside the code that explains polyphony handling
in FAUST ?
That's easy to explain: There is no polyphony handling in Faust. :) This falls
outside of Faust's scope, all handling of MIDI and other specific control
interfaces is done in the architectures.
That said, Stéphane has recently added a polyphony implementation to the Faust
headers, which was used to implement the polyphony support in FaustLive. He
should be able to tell you more about this
Stéphane will surely correct me if I'm wrong :), but I think that right now the
most mature polyphony implementations is in the faust-lv2 and faust-vst
architectures, featuring MIDI CC mapping, MIDI master tuning and pitch bend
range controls, MTS tunings, and multi-channel voice allocation. (All that
baggage might actually get in the way if you want to roll your own
implementation, but it might be worth taking a look at.)
Sure, the poly-dsp.h implementation is much simpler than Albert's faust-lv2 and faust-vst
architectures, and was intended to be "good enough"… But now the question is : what is
"good enough" ? ((-;
My initial idea was to possibly share more code with faust-lv2 and faust-vst
architectures, but since the code is not so easy to follow, and even not
completely shared between faust-lv2 and faust-vst..., I gradually improved an
initial implementation of Romain + Yann done for Android.
Basically, the convention is that a dsp intended to be used as an instrument should provide control parameters labelled
"freq" (pitch in Hz), "gain" (velocity normalized to the 0-1 range) and "gate" (0/1
signal indicating whether the voice is playing or not, to be used as a trigger for the envelop) and implement a
monophonic synthesizer using these. The rest is up to the architecture. There are also some conventions concerning
control meta data indicating CC mappings ("[midi:ctrl n]") and such. Some of those meta tags concerning MIDI
and OSC are described in the Faust Quick Reference, IIRC. There's also a recent article from Grame about that here:
http://faust.grame.fr/news/2016/01/14/controlling-with-midi.html. This mostly applies to FaustLive, I guess, but
[midi:ctrl n] is implemented at least by some of the polyphonic plugin architectures, among them faust-lv2 and
faust-vst. Presumably an MPE synth architecture would implement its own voice allocation and interpret some special
meta tags in order to assign the MPE controllers to corresponding controls in the Faust program. At least that's how I
would go about implementing it.
You're right, all this really needs to be documented somewhere. ;-) As it
stands, the above conventions were first implemented in some early
architectures and then became a kind of de facto standard way of doing these
things.
I will be at LAC@Berlin in April, and I've heard rumors that Yann might be
there as well. ;-) So if any of you guys attend LAC we could have a discussion
about all these things.
Albert
If you guys think we can at some point create a unique implementation, usable
by plugins and standalone applications, this would surely be better...
Stéphane
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Faudiostream-devel mailing list
Faudiostream-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
