Dear Yann,
I can try...
In SC, a demand-rate UGen graph is encapsuled into one of (currently) three
different UGens:
Demand.ar/kr
Duty.ar/kr
TDuty.ar/kr
Their functionality vary marginally (triggered execution/execution every `dur`
secs, etc.).
Each of them has three slots:
1. update input — either a trigger (Demand) or a Demand-rate UGen / scalar
(duration, Duty/TDuty)
2. reset input — if value passes from neg to pos, reset the value stream to
initial conditions
3. value stream — a Demand-rate UGen graph
Demand-rate UGens are UGens that calculate their values every time they are
triggered to do so from the outside, read more elaborate descriptions on this
here:
http://doc.sccode.org/Classes/Demand.html
and
http://doc.sccode.org/Classes/Duty.html
internally, the wrapper-UGens (Demand et al) implement the following behavior:
```
if reset:
call `next(nan)` on Demand-UGen in demand chain, this makes it reset.
else if call for next value:
calculate how many values are needed for the current block (N)
ask for N values from demand chain by providing
else:
keep last value (Demand/Duty), or 0 (TDemand)
```
A demand-rate UGen with parameters in its param-slots does this if its next
function is called:
```
if numSamples == nan:
for each UGen in param-slots:
call `next(nan)`, this makes it reset.
reset myself
else:
for each UGen in param-slots:
call next(numSamples) and collect values in array
compute numSample output based on parameters
```
All relevant source code for the implementation is here:
https://github.com/supercollider/supercollider/blob/develop/server/plugins/DemandUGens.cpp
hope this helps and I did not make too many errors...
Till
--
Till Bovermann
https://tai-studio.org | http://lfsaw.de | https://www.instagram.com/_lfsaw/
> On 2. Aug 2020, at 18:40, Yann Orlarey <orla...@grame.fr> wrote:
>
> Hi Till,
>
> Thanks for the offer! Could you explain in a few words how demand-rate works
> in supercollider?
> Cheers
>
> Yann
>
> Yann Orlarey
> Directeur scientifique/Scientific director
>
>
> orla...@grame.fr T : +33 (0) 4 72 07 37 00
> GRAME - Centre national de création musicale
> 11 cours de Verdun Gensoul | 69002 Lyon
> www.grame.fr | facebook | instagram | twitter
>
>
> Le sam. 1 août 2020 à 18:29, Till Bovermann <lf...@lfsaw.de> a écrit :
> dear list, yann, james,
>
> this is exciting news indeed! i think, faust will substantially benefit from
> an on-demand evaluation possibility. i am very happy to help with my
> experiences as a long-term supercollider user and developer. it might be
> interesting to look at the implementation of demand-rate ugens in sc3,
> especially the possibility to reset pattern generating engines.
>
> all the best
> till
>
>> On 31. Jul 2020, at 21:40, Yann Orlarey <orla...@grame.fr> wrote:
>>
>>
>> Hi,
>>
>> After these exchanges, I am quite convinced of the interest of having
>> on-demand computation in Faust!
>>
>> As I said in my previous email, it can't be the current control primitive.
>> It must actually be an operation on signal processors, not an operation on
>> signals. The challenge is to find a primitive that keeps the simple and
>> well-defined semantics of Faust.
>>
>> I started to think about this and sketched an `ondemand(P)` primitive that
>> transforms a P processor into an equivalent on-demand version with an extra
>> clock input.
>>
>> This is all very preliminary, but for those interested, my notes are here
>> https://photos.app.goo.gl/UTHpYfz5q1oe4CRV7, although I doubt it would be
>> understandable to anyone but me ;-)
>>
>> If you have specific use cases and examples to feed the reflection, it would
>> be helpful to us...
>>
>> Cheers
>>
>> Yann
>>
>> Yann Orlarey
>> Directeur scientifique/Scientific director
>>
>>
>> orla...@grame.fr T : +33 (0) 4 72 07 37 00
>> GRAME - Centre national de création musicale
>> 11 cours de Verdun Gensoul | 69002 Lyon
>> www.grame.fr | facebook | instagram | twitter
>>
>>
>> Le jeu. 30 juil. 2020 à 13:17, James Mckernon <jmcker...@gmail.com> a écrit :
>> Hi Yann,
>>
>> Thanks for clarifying your position regarding control and enable, and
>> their intended use.
>>
>> I understand that control poses certain semantic complications.
>> However, I would also respectfully suggest that a (properly-working)
>> control primitive would be a powerful addition to the language, which
>> could perhaps justify such complications. (Indeed, it would be at the
>> top of my 'wish list' for faust features.) It would make faust an
>> excellent tool for algorithmic composition. I understand that this is
>> not a primary focus of the faust project, but the possibility of being
>> able to use faust to describe not only sample-level DSP but also
>> higher-level control structures is very appealing to me.
>>
>> Given your position, I do not expect anyone to fix the above issues
>> with control's semantics. However, perhaps I can persuade you not to
>> remove it? :) I am also considering trying to write a patch myself to
>> fix those issues - if I ever finish such a patch, I would be grateful
>> if it could be considered for inclusion.
>>
>> Nonetheless, I of course respect the right of the faust developers to
>> steer faust as seems best to them, with or without whatever primitives
>> they choose.
>>
>> Many thanks,
>> James
>>
>>
>> On 7/30/20, Yann Orlarey <orla...@grame.fr> wrote:
>> > Hi James,
>> >
>> > We discourage the use of the primitive "control" that we plan to remove. As
>> > you reported, "control" poses many semantic problems. In reality, this
>> > primitive was essentially intended for internal use, in the compilation of
>> > the experimental "enable" primitive (enable(x,y) -> control(x*y, y!=0)) and
>> > it should never have been made public.
>> >
>> > The experimental enable(x,y) primitive has, approximately, the semantics of
>> > x*y. But it allows to disable the computation of x when y is 0 (and if x is
>> > not used in other circumstances). Enable therefore can save CPU in some
>> > circumstances. But this primitive must be used with great care. In
>> > particular, it is the responsibility of the programmer to ensure that his
>> > use of enable(x,y) behaves as much as possible like x*y.
>> >
>> > Cheers
>> >
>> > Yann
>> >
>> >
>> > *Yann Orlarey*
>> > Directeur scientifique/Scientific director
>> >
>> >
>> > orla...@grame.fr <x...@grame.fr> T : +33 (0) 4 72 07 37 00
>> > GRAME - Centre national de création musicale
>> > 11 cours de Verdun Gensoul | 69002 Lyon
>> > www.grame.fr | facebook <https://www.facebook.com/Gramelyon/> | instagram
>> > <https://www.instagram.com/grame_cncm/> | twitter
>> > <https://twitter.com/GRAME_LYON>
>> _______________________________________________
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
