Hi, Till.
I'll try to be more clear.
I'm referring to a control-rate stepped stream as shown in Oleg's example,
where the actual work is performed only if the condition is true, as
opposed to a control-rate stepped stream of the kind that we sometimes
implement using, for example, sample-and-hold
On 07/14, Dario Sanfilippo wrote:
>
> I would find the second case useful as it would always require maximum
> computation and the control rate could be changed on-the-fly without
> worrying about clicks, provided that no clicks occurred at audio-rate
> calculations.
Sure. and in fact I think that
Dear Dario,
I do not really understand the difference of the two, or why the second
("computed but not used") makes sense... since the computation in between state
changes (to my understanding) should (by definition) not change, there would
not be any difference to the first case... of course,
I'll look into it ASAP, at the moment it is still a little cloudy to me shat it
actually does... but yes, from what I understand this seems to be useful in
establishing demand-rate capabilities :)
Till
--
Till Bovermann
https://tai-studio.org | http://lfsaw.de | https://www.instagram.c
Hello, list.
I having a few thoughts about this and I wanted to share them with you.
Some time ago, I remember a discussion where Yann considered on removing
the *letrec* environment altogether and to being able to define a system of
equations within the *with* environment itself with the same sy
Hello, dear Oleg and Till.
>From the perspective of a composer/performer who works with live audio, and
considering that Faust is intrinsically real-time, would it make sense to
have two control primitives, one where computation is skipped when it is
not requested, and one where it is computed but
On 07/14, Till Bovermann wrote:
>
> Thanks also to you, Oleg; is there somewhere an example for the control
> primitive,
Sorry, I do not know. But see below.
However, I did "git pull" and it seems that "control/enable" are already
supported in FIR scalar mode. Probably the commit 32846af52e92498
Thanks for the answers, James, I'd be interested in helping out with
this/discussing your idea for a lazy-type select2 implementation. My example is
really just a proof of concept for a state-driven synthesis engine, I think
actually, this kind of synthesis technique (in the sense of variable
d
On 07/14, James Mckernon wrote:
>
> I have some more thoughts on this that are perhaps worth discussing in
> a separate thread. Briefly, I feel like a 'dumb' select2, which only
> ever evaluates one of its branches,
You probably want the "control" primitive. Currently it is only supported by
"-lan
On 07/14, Till Bovermann wrote:
> Dear list,
>
> I am confused about this.
> I have the following function taking a list of arguments (note the inner
> brackets;
>
> ((( input args as list:
> reason being that this function will later be encapsulated into a recursion
> operator that applies the f
On 7/14/20, Till Bovermann wrote:
> Dear James, all,
>
> your hint helped a lot, thanks, James!
I'm glad.
> However, after reading this paper
> https://hal.archives-ouvertes.fr/hal-02159011/document
>
> (thanks for the pointer, sletz!)
>
> I think that computation still happens for every s
11 matches
Mail list logo
