Closed ceelian closed 2 years ago
The enable
and control
primitives are considered experimental and have various problems. This is the reason they are not officially documented and supported. A new on demand primitive is worked out and should allow to re-implement the same kind of features in a cleaner way.
Thank you.
@sletz One more question related to this as I found out that the FAUST DX7 Library implementation is also using control()
.
Can you point me to some of the various problems using control() implies?
Because until on-demand primitives are implemented I guess I need to use control() as I have a similar approach as the FAUST DX7 implementation.
Thanks again for FAUST and for your understanding responses to my other comments 🙏.
AFAIR the generate code when using control/enable
primitives is not always correct, so we don't want to publicise them.
I would love to see the "on demand primitive" added to faust, or the enable
and control
ones fully supported.
Is this still being worked on? The specs repo hasn't been updated in a while, but maybe the specs are done?
Hi All,
On the master-with-mute branch, my understanding is that the only issue is that vector mode does not always work. The "everything-must-run" limitation forced me into using many small separately compiled Faust modules integrated into JUCE projects. Since JUCE does in-place processing, I also need the --in-place option, and that similarly only works in scalar mode! Thus, unless I am missing something, committing to scalar mode means I can use either JUCE integration or the master-with-mute approach. (Of course we give up some performance without vector mode.)
Is my understanding up to date?
Thanks, Julius
On Sun, May 7, 2023 at 3:54 PM Bart Brouns @.***> wrote:
I would love to see the "on demand primitive" added to faust, or the enable and control ones fully supported.
Is this still being worked on? The specs repo hasn't been updated in a while, but maybe the specs are done?
— Reply to this email directly, view it on GitHub https://github.com/grame-cncm/faust/issues/714#issuecomment-1537558935, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQZKFIRFNRW637FNIHIUJ3XFARZNANCNFSM5PUCL2CA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- Julius O. Smith III @.***> Professor Emeritus of Music and by courtesy Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/
enable/control
is supposed to be replaced by the ondemand
primitive, see: https://github.com/orlarey/ondemand-ifc22-slides
So ondemand
is still actively developed?
If so, that is great news!
First, thanks a lot for this awesome language und ecosystem!
While trying to create a performant way of switching between different synth engines at runtime I stumbled across these mysterious undocumented
enable
andcontrol
primitives.As far as I investigated, somehow these two primitives can disable a certain signal path from the processing loop and should therefore be better than
nselect
. But to be honest I couldn't find a documentation beside this testcase:https://github.com/grame-cncm/faust/blob/master-dev/tests/impulse-tests/dsp/osc_enable.dsp
There is a side note in a tutorial here which supports my assumption:
https://ccrma.stanford.edu/~rmichon/faustTutorials/#using-different-keyboards-to-control-different-synths
And there are two posts in the mailing list:
https://sourceforge.net/p/faudiostream/mailman/message/36488423/ https://sourceforge.net/p/faudiostream/mailman/message/36066132/
As this feature is now also available in the
master-dev
andmaster
branch since the year 2020 and the documentation of all other primitives is very good and feels kind of complete, I would have expected these two new primitives to be officially documented/mentioned somewhere as well. Especially how and when it should be used and if it is already safe/suggested to use or if it is still experimental.Thank you.