Re: [Faudiostream-users] input signal cross-routing?

[yann orlarey]

Hi Autumn,

Here is how to cross inputs 2 and 3.
Cheers

Yann

X = _,_ <: !,_,_,!;
process = _,X,_:par(i,2,(voc(n,0.01,1,mod_bw,mod_order,car_bw,car_order))):>
_,_;

Le jeu. 28 déc. 2023 à 14:06, Autumn Cheney via Faudiostream-users <
faudiostream-users@lists.sourceforge.net> a écrit :

> hi!
>
> i'm currently building a stereo vocoder in radium's faust development
> environment, and i've run into a minor problem
>
> i have the core vocoder running, but i can't figure out how to route the
> effect input the way i want to. i'd like to have input 1 going into the
> left channel modulator input, input 2 going into the right channel carrier
> input, and inputs 3 and 4 going into their respective modulator inputs. but
> as of now inputs 1 and 2 are routed to the left channel unit and inputs 3
> and 4 are routed to the right channel input
>
> hopefully this makes sense. here's my faust code (don't mind the fact that
> some code is ripped from the libraries):
>
> import("stdfaust.lib");
>
> select4(s) = *(s==0),*(s==1),*(s==2),*(s==3):>_;
>
> n = 8;
>
> mod_order = nentry("modulator
> order[style:menu{'-12db':0;'-24db':1;'-36db':2;'-48db':3}}]",0,0,3,1);
> mod_bw = vslider("modulator bw",0.5,0.1,2,0.001);
>
> car_order = nentry("carrier
> order[style:menu{'-12db':0;'-24db':1;'-36db':2;'-48db':3}}]",0,0,3,1);
> car_bw = vslider("carrier bw",0.5,0.1,2,0.001);
>
> bp(freq,q) = fi.svf.bp(freq,q);
> multi_bp(freq,q,order) =
> _<:bp(freq,q),(bp(freq,q):bp(freq,q)),(bp(freq,q):bp(freq,q):bp(freq,q)),(bp(freq,q):bp(freq,q):bp(freq,q):bp(freq,q)):>select4(order);
>
> voc_band(band_num,bands_num,bw_ratio,order,bg,x) = x : multi_bp(band_freq,
> band_q, order) : _*bg with {
> band_freq = 25*pow(2,(band_num+1)*(9/bands_num));
> bw = (band_freq - 25*pow(2,(band_num)*(9/bands_num)))*bw_ratio;
> band_q = band_freq/bw;
> };
>
> voc(bands_num,att,rel,mod_bw,mod_order,car_bw,car_order,carrier,modulator)
> = carrier <: par(i,bands_num,voc_band(i,bands_num,mod_bw,mod_order,1) :
> an.amp_follower_ar(att,rel) : _,modulator :
> voc_band(i,bands_num,car_bw,car_order)) :>
> _*(1/(bands_num*(mod_order+1)*(car_order+1)));
>
> process =
> _,_,_,_:par(i,2,(voc(n,0.01,1,mod_bw,mod_order,car_bw,car_order))):>_,_;
>
> as you'll see from the block diagram the input  2 and 3 cables don't cross
> over. but i want them to cross over
>
> is this possible? thank you,
>
> a cheney
> ___
> 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

[Faudiostream-users] Introduction of Widget Modulation in Faust 2.69.0

[yann orlarey]

Hi,

Faust is a very modular language, and it's easy to reuse any Faust program
as a component of another, thanks to the `component()` construct. For
example: `component("freeverb.dsp")` lets you integrate a fully functional
reverb, with its user interface, inside another program.

But how to control the parameters of this reverb other than by hand via the
user interface? How to get the equivalent of a “voltage control”? How to
modulate one of the parameters with an LFO, for example? Well, if the
reverb designer didn't anticipate this from the beginning, it's simply
impossible!

The absence of such a capability in the Faust language limits the
reusability of existing code. A technique to fill this gap is to write the
code in such a way as to separate the audio algorithm itself from its user
interface. This approach makes it easy to reuse the audio algorithm in
another context or with another user interface. Such an approach is good
practice, but it's not very convenient.

The new language expression introduced in Faust 2.69.0: _widget
modulation_, addresses this very issue. It can be used on an existing
component, for example, to modulate a slider, replace one slider with
another, replace a slider with a constant, etc., without modifying the
component's source code!

Its simplest form is the following:

`["Wet" -> freeverb]`

This adds an input to the freeverb, that is used to modulate the "Wet"
slider. An LFO, for example, can be connected to this input:

`lfo(10, 0.5), _, _ : ["Wet" -> freeverb]`

The "Wet" label designates the slider to modulate. Of course, this
presupposes knowing the names of the sliders. But since the sliders appear
in the user interface, discovering their names is easy enough. If several
widgets have the same name, adding the names of the surrounding groups, for
example: `"h:group/h:subgroup/label"` can help distinguish them.

Multiple sliders can be indicated as in: `["Wet", "Damp", "RoomSize" ->
freeverb]`. In this case, three new inputs are added.

We haven't said how sliders are modulated. By default, when nothing is
specified, the modulation is a multiplication. The previous example is
equivalent to the explicit form `["Wet":*, "Damp":*, "RoomSize":* ->
freeverb]`. The multiplication can be replaced by any other circuit with
two inputs and one output.

For example, one could write `["Wet", "Damp", "RoomSize":+ -> freeverb]` to
indicate that the "RoomSize" parameter is modulated by addition.

The only constraint on the modulation circuit is that it must have only one
output and at most two inputs. We can therefore have `0->1`, `1->1`, or
`2->1` circuits. Only `2->1` circuits create additional inputs. Moreover,
`0->1` circuits lead to the elimination of the slider.

We can therefore rewrite `lfo(10, 0.5), _, _ : ["Wet" -> freeverb]` as
follows: `["Wet":*(lfo(10, 0.5)) -> freeverb]`. The latter form does not
lead to the creation of additional input, as the LFO is placed inside the
reverb. The form `["Wet":0.75 -> freeverb]` results in the deletion of the
"Wet" slider, replaced by the constant 0.75. Finally, the form
`["Wet":+(hslider("More Wet", 0, 0, 1, 0.1)) -> freeverb]` adds a second
slider to the freeverb interface.

Yann
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Find N of greatest input

[Yann Orlarey]

Hi Oleg,

Sorry for the late answer.

I think this is an excellent suggestion! Since it is a typical "reduce"
operation, I suggest having "reduce" in the name. We can imagine having
three different versions depending if we start the reduction from the top
outputs, the bottom outputs, or in parallel.

import("stdfaust.lib");


// parallel reduce: starts reductions in parallel on both halves
parReduce(op,1) = si.bus(outputs(op));
parReduce(op,2) = op;
parReduce(op,n) = parReduce(op,int(n/2)), parReduce(op,n-int(n/2)) : op;

// top reduce, starts reductions from the top outputs
topReduce(op,1) = si.bus(outputs(op));
topReduce(op,2) = op;
topReduce(op,n) = topReduce(op,n-1), si.bus(inputs(op)-outputs(op)) : op;

// bottom reduce: starts reductions from the bottom outputs
botReduce(op,1) = si.bus(outputs(op));
botReduce(op,2) = op;
botReduce(op,n) = si.bus(inputs(op)-outputs(op)), botReduce(op,n-1) : op;

// examples
pmax(n) = par(i, n, (i,_)) : parReduce(op,n) with {
op(i1,v1,i2,v2) = select2(v2>v1,i1,i2), max(v1,v2);
};

tmax(n) = par(i, n, (i,_)) : topReduce(op,n) with {
op(i1,v1,i2,v2) = select2(v2>v1,i1,i2), max(v1,v2);
};

bmax(n) = par(i, n, (i,_)) : botReduce(op,n) with {
op(i1,v1,i2,v2) = select2(v2>v1,i1,i2), max(v1,v2);
};

process = pmax(16);

Cheers,

Yann

Le jeu. 25 mai 2023 à 15:04, Oleg Nesterov  a écrit :

> Hello,
>
> I am wondering if it makes any sense to generalize ba.parallelOp,
> something like
>
> parallelOp(op,1) = si.bus(outputs(op));
> parallelOp(op,2) = op;
> parallelOp(op,n) = parallelOp(op,n-1),
> si.bus(inputs(op)-outputs(op)) : op;
>
> then we can do
>
> i_max(n) = par(i,n, (i,_)) : parallelOp(op,n) with {
> op(i1,v1,i2,v2) = select2(v2>v1,i1,i2), max(v1,v2);
> };
>
> for example
>
> process = 3,2,4,6,2 : i_max(5);
>
> outputs
>
> output0[i0] = FAUSTFLOAT(3);    // index
> output1[i0] = FAUSTFLOAT(6);// maximum
>
> probably not.
>
> Oleg.
>
> On 05/25, Yann Orlarey wrote:
> >
> > Hi Daz,
> >
> > You did nothing wrong! I could compile it with the command line compiler,
> > but I should have also tested it with the IDE.
> >
> > Here is a better and faster solution because, instead of a tree of depth
> N,
> > it creates a more balanced tree of depth log(N):
> >
> > foo(n) = f(n,n-1) with {
> > f(1,c) = c,_;
> > f(2,c) = c-1,_,c,_ : major;
> > f(n,c) = f(n1,c-n2), f(n2,c) : major with {
> > n1 = int(n/2);
> > n2 = n-n1;
> > };
> > major(c1,v1,c2,v2) = select2(v1>v2, c2, c1), max(v1,v2);
> > };
> >
> > Cheers
> >
> > Yann
> >
> >
> >
> > Le jeu. 25 mai 2023 à 02:29, Daz Man  a écrit :
> >
> > > Hi Yann,
> > >
> > > Easier for some than others...   But...
> > >
> > > That code produces errors from "too much recursion" or "stack overflow"
> > > when run in the Faust online editor or in FaustLive. Did I perhaps use
> it
> > > wrongly?
> > >
> > > I did receive another reply from Bart, pointing to this slightly
> different
> > > function that I appear to have working, after changing my input and
> output
> > > formats to suit:
> > >
> > >
> https://github.com/magnetophon/faustExperiments/blob/0d2735bc4900dc4e51da24fb8ee05e49d44eb73c/acor.dsp#L76
> > >
> > > Thanks,
> > > Daz
> > >
> > > --
> > > *From:* Yann Orlarey 
> > > *Sent:* Thursday, 25 May 2023 8:45 AM
> > > *To:* Daz Man 
> > > *Subject:* Re: [Faudiostream-users] Find N of greatest input
> > >
> > > Hi Daz,
> > >
> > > Such a function is not difficult to write:
> > >
> > > foo(1) = 0,_;
> > > foo(n) = foo(n-1), n-1,_ : major with {
> > > major(c1,v1,c2,v2) = ba.if(v1>v2, c1, c2), max(v1,v2);
> > > };
> > >
> > > Cheers
> > >
> > > Yann
> > >
> > >
> > > Le mar. 23 mai 2023 à 19:29, Daz Man  a écrit :
> > >
> > > Hi all,
> > >
> > > I need a function that compares 257 parallel inputs and returns the
> input
> > > N with the greatest positive value. (ie: which input has the biggest
> > > amplitude)
> > > What's the best way to do this?
> > > I looked at parallelMax, but it doesn't appear to return which of the N
> > > inputs was used for the max.
> > >
> > > Thanks,
> > > Daz
> > > ___
> > > 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
>
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Find N of greatest input

[Yann Orlarey]

Hi Daz,

You did nothing wrong! I could compile it with the command line compiler,
but I should have also tested it with the IDE.

Here is a better and faster solution because, instead of a tree of depth N,
it creates a more balanced tree of depth log(N):

foo(n) = f(n,n-1) with {
f(1,c) = c,_;
f(2,c) = c-1,_,c,_ : major;
f(n,c) = f(n1,c-n2), f(n2,c) : major with {
n1 = int(n/2);
n2 = n-n1;
};
major(c1,v1,c2,v2) = select2(v1>v2, c2, c1), max(v1,v2);
};

Cheers

Yann



Le jeu. 25 mai 2023 à 02:29, Daz Man  a écrit :

> Hi Yann,
>
> Easier for some than others...   But...
>
> That code produces errors from "too much recursion" or "stack overflow"
> when run in the Faust online editor or in FaustLive. Did I perhaps use it
> wrongly?
>
> I did receive another reply from Bart, pointing to this slightly different
> function that I appear to have working, after changing my input and output
> formats to suit:
>
> https://github.com/magnetophon/faustExperiments/blob/0d2735bc4900dc4e51da24fb8ee05e49d44eb73c/acor.dsp#L76
>
> Thanks,
> Daz
>
> --
> *From:* Yann Orlarey 
> *Sent:* Thursday, 25 May 2023 8:45 AM
> *To:* Daz Man 
> *Subject:* Re: [Faudiostream-users] Find N of greatest input
>
> Hi Daz,
>
> Such a function is not difficult to write:
>
> foo(1) = 0,_;
> foo(n) = foo(n-1), n-1,_ : major with {
> major(c1,v1,c2,v2) = ba.if(v1>v2, c1, c2), max(v1,v2);
> };
>
> Cheers
>
> Yann
>
>
> Le mar. 23 mai 2023 à 19:29, Daz Man  a écrit :
>
> Hi all,
>
> I need a function that compares 257 parallel inputs and returns the input
> N with the greatest positive value. (ie: which input has the biggest
> amplitude)
> What's the best way to do this?
> I looked at parallelMax, but it doesn't appear to return which of the N
> inputs was used for the max.
>
> Thanks,
> Daz
> ___
> 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

Re: [Faudiostream-users] Problems with faust2caqt

[yann orlarey]

Thank you David for undertaking this work, it is really very useful!
Yann

Le jeu. 23 mars 2023 à 22:44, David Braun  a
écrit :

> On this page: https://github.com/DBraun/faust/actions/runs/4458934421 there's
> an "artifacts" section at the bottom. It may be possible to use some of
> the libfaust or faust files there, or in more recent runs. I'm hoping to
> finish this sometime soon so that the main Faust repo can automatically
> release faust executables and libfaust on all platforms, and faustgen on
> macos/windows.
>
> On Thu, Mar 23, 2023 at 1:48 PM Henrik Frisk  wrote:
>
>>
>>
>> On Tue, Mar 21, 2023, 3:37 PM Henrik Frisk  wrote:
>>
>>>
>>>
>>> Den tis 21 mars 2023 kl 15:09 skrev Stéphane Letz :
>>>


 > Le 21 mars 2023 à 14:57, Henrik Frisk  a écrit :
 >
 > Hi,
 >
 > I have recently changed computer from Linux (where faust have always
 run like a charm) to macos and I've run into some problems. Having
 downloaded the latest 2.54.9 as a dmg and installed it. Having tested
 several fasut2* (fasut2caqt for example) yields:
 >
 > dyld[38924]: Library not loaded: '/opt/local/lib/libncurses.6.dylib'
 >
 > ncurses is installed and the particular library is in
 /opt/homebrew/opt/ncurses/lib/ (installed via brew). Regardless how I try I
 can't get the scrript to find it. I have tried
 >
 >  export PATH="/opt/homebrew/opt/ncurses/bin:$PATH"'
 >   export LDFLAGS="-L/opt/homebrew/opt/ncurses/lib"
 >   export CPPFLAGS="-I/opt/homebrew/opt/ncurses/include"
 >   export PKG_CONFIG_PATH="/opt/homebrew/opt/ncurses/lib/pkgconfig"
 >
 > I have also tried to reinstall ncurses.

 Hi Henrik,

 Yes, this is a known problem: compiled binaries are not correctly
 self-contained. David Braun is working on improving the situation using
 GitHub actions. You can possibly test the precompiled 2.58.11 version here:
 https://github.com/DBraun/faust/actions/runs/4458934421
>>>
>>>
>>> Ok, will try later!
>>>
>>
>> On a first try it didn't help unfortunately, but I realize now that I
>> just cloned Braun's repository and compiled it. I'm not familiar with
>> github actions and can't quite figure out how to get a precompiled version?
>>
>> /Henrik
>>
>>> ___
>> 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
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] New Python examples using Faust, JAX, and the Box API

[Yann Orlarey]

Hi David,

Fantastic, thanks for this great contribution! I think it would be really
interesting to organize an online presentation for the Faust community.
What do you think about it?

Cheers,

Yann

Le jeu. 20 oct. 2022 à 20:15, Stéphane Letz  a écrit :

> Hi David,
>
> Thanks for this awesome contribution !  Hopefully opening an entirely new
> world in the Machine Learning domain for the Faust ecosystem!
>
> Cheers,
>
> Stéphane
>
> > Le 20 oct. 2022 à 12:48, David Braun  a écrit
> :
> >
> > Faust now supports the machine learning framework JAX as a backend.
> DawDreamer is a python module where you can conveniently convert Faust code
> to JAX. DawDreamer has two new Colabs demonstrating this Faust to JAX
> pipeline:
> >   • Faust to JAX: Optimize parameters using gradient descent.
> >   • Faust to QDax: Optimize with Quality-Diversity algorithms.
> > There's an additional notebook covering the Box API in Python. You can
> access the intermediate representation of Faust, programmatically compose
> boxes, then render audio with DawDreamer, or transpile to a target language
> (C++, JAX, Rust, etc.).
> >
> > More information in the tweet:
> https://twitter.com/DoItRealTime/status/1583042473227452416
> >
> > Please check out the Colabs, and feel free to contact me.
> >
> > Best,
> >
> > David
> > ___
> > 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
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Fwd: [AFIM.INFO] Appel à candidatures : professeur des universités Bordeaux - recherche en informatique musicale // Call for applications : full professor Bordeaux - research in c

[Yann Orlarey]

-- Forwarded message -
De : Myriam Desainte-Catherine 
Date: ven. 14 oct. 2022 à 18:35
Subject: [AFIM.INFO] Appel à candidatures : professeur des universités
Bordeaux - recherche en informatique musicale // Call for applications :
full professor Bordeaux - research in computer music
To: afim info , labri scrime-info <
labri.scrime-i...@diff.u-bordeaux.fr>


--- À diffuser largement --- English version below

Appel à candidatures : poste de professeur des universités en informatique
vacant à Bordeaux INP :
- Recherche en informatique musicale dans le département image et son du
LaBRI (www.labri.fr) et au SCRIME (scrime.u-bordeaux.fr
)
- Enseignement à l'ENSEIRB-MATMECA (
https://enseirb-matmeca.bordeaux-inp.fr/fr) dans la filière informatique (
https://enseirb-matmeca.bordeaux-inp.fr/fr/informatique)
- Calendrier prévisionnel : candidatures février 2023, début au 1er septembre
2023.
- Plus d'info : myriam.desainte-cather...@labri.fr

Les candidat(e)s doivent proposer un projet de recherche s'intégrant dans
le département image et son du LaBRI pour travailler notamment avec le
groupe Modélisation du Son et de la Musique, et créer des liens avec
l'équipe Manao et le groupe Analyse et Indexation. Les candidat(e)s doivent
aussi proposer un projet pour la plateforme de recherche SCRIME (Studio de
Recherche et de Création en Informatique et Musiques Expérimentales) suite
au départ de la directrice actuelle. Le domaine de recherche est celui de
l'informatique musicale (calcul du son et de la musique, interaction
musicale). Les candidat(e)s doivent s'inscrire dans au moins une des
thématiques suivantes:
- traitement informatique de la musique et du son :  analyse,
transformation et génération de la musique et du son, incluant des sons de
l'environnement et bandes son de videos écologiques, par des approches
computationnelles (algorithmes, traitement du signal, apprentissage) dans
toutes les dimensions musicales et sonores (timbre, hauteur, dynamique et
spatialisation).
- interaction sonore et musicale : concevoir de nouvelles Interfaces entre
les utilisateurs et les ordinateurs pour créer de nouveaux moyens
d'expression musicale, par la conception de systèmes de réalité sonore
virtuelle/mixte/augmentée, et de nouveaux modèles de partitions musicales
et d'instruments de musique, par l'interaction avec l'image et d'autres
médias et par l'utilisation du son comme moyen d'information.
- compréhension  et modélisation du son et de la musique : Music
information retreival (extraction d'informations musicales), musicologie
computationnelle, approches computationnelles de la cognition musicale,
modèles et langages formels pour la musique (temps et espace des paramètres
sonores et musicaux).
- conception de nouveaux outils pour la création sonore et musicale, la
performance et la pédagogie : développement d'outils pour assister le sound
design et la composition musicale, la scénarisation, la sonification, la
spatialisation (inclut la composition algorithmique, notamment par
techniques d'apprentissage), inclut la recherche d'architectures
logicielles et langages combinant micro (son) et macro (forme musicale)
niveaux, frugalité des calculs et des transferts de données sonores et
musicales, minimisation du retard de transmission du son, spécifications
formelles pour la préservation des outils.

--  ENGLISH VERSION -- To be widely distributed --

Call for applications: vacancy for a university professor in computer
science at Bordeaux INP:
- Research in computer music in the image and sound department of the LaBRI
(www.labri.fr) and at SCRIME (scrime.u-bordeaux.fr)
- Teaching at ENSEIRB-MATMECA ( https://enseirb-matmeca.bordeaux-inp.fr/fr)
in the computer science department
- Schedule: applications February 2023, start September 2023
- Contact : myriam.desainte-cather...@labri.fr

Applicants must propose a research project that fits within the image and
sound department of the LaBRI to work in particular with the Sound and
Music Modeling group, and create links with the Manao team and the Analysis
and Indexing group. Candidates must also propose a project for the SCRIME
research platform (Studio de Recherche et de Création en Informatique et
Musiques Expérimentales) following the departure of the current director.
The research area is computer music (sound and music computation, musical
interaction). The candidates must be involved in at least one of the
following themes:
- computer processing of music and sound: analysis, transformation and
generation of music and sound, including environmental sounds and
soundtracks of ecological videos, by computational approaches (algorithms,
signal processing, learning) in all dimensions of music and sound (timbre,
pitch, dynamics and spatialization).
- Sound and music interaction: designing new Interfaces between users and
computers to create new means of musical expression, through the design of
virtual/mixed/augmented sound reality 

Re: [Faudiostream-users] How to place values in lists?

[Yann Orlarey]

Hi Robin,

We will never thank Albert Graef enough for the black magic of pattern
matching in Faust ;-)

Concerning "outputs()" it is not exactly the same as "ba.count()" but it
will give the same result for a usual list of numbers (*). But "outputs()"
being primitive, based on internal information already computed by the type
system, it is, therefore, faster in terms of compilation time and doesn't
require importing any library.

Cheers,

Yann

(*)  outputs((1,2,3,4) ==  ba.count((1,2,3,4)) == 4
but outputs(((1,2),3,4) == 4   !=   ba.count(((1,2),3,4)) == 3

Le ven. 19 août 2022 à 17:05, Robin Gareus  a écrit :

> On 8/19/22 08:19, Yann Orlarey wrote:
> > Hi Robin,
> >
> > Here is a generic shelfcascade with an arbitrary list of frequencies. The
> > gains are directly routed. They are in the reverse order (the first input
> > is the gain of the last stage).
> >
> >
> > shelfcascade(lf) = bus(lf), ls3(first(lf)) : sc(lf) // lf : list of
> > frequencies
> > with {
> > sc((f1, f2, lf)) = bus((f2,lf)), bs3(f1,f2) : sc((f2,lf)); // recursive
> > pattern
> > sc((f1, f2)) = _, bs3(f1,f2) : hs3(f2); // halting pattern
> > bus(l) = par(i, outputs(l), _); // a bus of the size of a list
> > first((x,xs)) = x; // first element of a list
> > };
> >
>
> Hello Yann,
>
> Wow. Now that is a brilliant solution, and I have learned a few nice new
> tricks there as well. Splicing the frequency list for the halting
> pattern is something I would never have thought to do. I was too focused
> on using an iterator.
>
> Is there a reason why you have used outputs(l) instead of ba.count(l)?
>
> Thank you!
>
> --
> robin
> ___
> 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

Re: [Faudiostream-users] How to place values in lists?

[Yann Orlarey]

Hi Robin,

Here is a generic shelfcascade with an arbitrary list of frequencies. The
gains are directly routed. They are in the reverse order (the first input
is the gain of the last stage).


shelfcascade(lf) = bus(lf), ls3(first(lf)) : sc(lf) // lf : list of
frequencies
with {
sc((f1, f2, lf)) = bus((f2,lf)), bs3(f1,f2) : sc((f2,lf)); // recursive
pattern
sc((f1, f2)) = _, bs3(f1,f2) : hs3(f2); // halting pattern
bus(l) = par(i, outputs(l), _); // a bus of the size of a list
first((x,xs)) = x; // first element of a list
};


Cheers,

Yann



Le ven. 19 août 2022 à 01:04, Robin Gareus  a écrit :

> On 8/19/22 00:24, b...@magnetophon.nl wrote:
> > Hi Robin,
> >
> > When I saw your shelving based MB compressor, I also set out to make a
> > generic N band and M channel version of it.  :)
> > I ran into the same problem, and came up with this solution:
> >
> https://github.com/magnetophon/faustExperiments/blob/shelfComp/N_band_Compressor_N_chan.dsp#L47
> >
>
> Hello Bart,
>
> For the analysis stage using HP/LP you can run the filters in parallel,
> like you do in line 68-73. However when applying the gain to each band
> using a shelving filter, like I'd like to, it has to be done in sequence.
>
> > Is your WIP also online already?
>
> It is still the same that I have linked to earlier. - I have mostly
> given up on providing a generic method, and actually believe that it is
> impossible with FAUST at this point in time. But it is trivial to use
> any number of bands by just writing it out, and you don't change the
> [max] number of bands dynamically anyway.
>
> Realistically a four band version is more than sufficient when mixing or
> mastering. For Klaus' project where there's no human operator to set the
> frequencies by ear, an eight band split may be preferable.
>
> --
> robin
> ___
> 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

Re: [Faudiostream-users] How to place values in lists?

[Yann Orlarey]

Hi Robin,

Welcome back!

As written, analyzer needs a list of frequencies as a second argument.
These frequencies can be numbers or more complex circuits, but they have to
be number-like, i.e. with no input and only one output. So you can't use
the identity function _ as a frequency (because it has an input), but you
can use sliders (or more complex expressions), like in the following
example :

import("stdfaust.lib");

process = an.analyzer(6, par(i,10, hslider("freq %i[scale:log]", 100*(i+1),
20, 2, 1)));


As I am not sure to answer your question, don't hesitate to specify in
greater detail what you want to do !

Cheers,

Yann

Le mer. 17 août 2022 à 18:30, Robin Gareus  a écrit :

> Hello Faust community,
>
> I'm brushing up my FAUST skills. It's been over a decade and it's
> amazing to see how far things have grown. Well now, I just ran into an
> issue:
>
>
> How can I place signal primitive into a list?
>
> e.g. use  _,_  as list arguments (_,_) for `an.analyzer(3, HERE)`
>
>
> If I understand correctly, lists are just parallel composition. So I
> expected an extra pair of brackets to work. Why doesn't it?
>
>
> -8<-
>
> Perhaps the deeper issue is the design-pattern that I'm aiming for. So
> let me elaborate. The specific use-case is a multiband effect[1]:
>
> The following works (implementation omitted for readability):
>
> ```
> apply(fq,g1,g2,g3,g4) = _;
>
> freqs=100,200,300;
>
> process= _ <: par(i,2,_)
>: (an.analyzer(6, (freqs)) , _)
>: apply (freqs);
>
> ```
>
> Now, I'd like to make this generic for arbitrary numbers of frequency
> bands, rather than 3 hardcoded band-splits. This is similar how
> an.analyzer() or filterbank work, except with an additional gain
> parameter for each band:
>
>
> ```
> nuapply(freqs, gain) = _
>   with {
> nb   = ba.count(freqs);
> f(n) = ba.take(n, freqs);
> g(n) = ba.take(n, gain); // bm +1 elemements
>   };
> ```
>
> So far so good. This works with explicit literal arguments.
>
> However I fails to see how the output of analysis stage can be passed as
> list.
>
> I tried another approach using `nu2apply(freqs)` and then
> selectn() the gain levels from input bus, but that quickly becomes a mess.
>
> What is the Faustian way to implement this?
>
> Thanks in advance,
> robin
>
> --
>
> [1]
>
> https://gist.github.com/x42/eeb2aa9f9cc4a9083fb2cf2d86645c9a#file-mcomp-dsp-L43-L60
> ___
> 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

Re: [Faudiostream-users] Combining the `with` and `letrec` environments in Faust

[Yann Orlarey]

Hi Dario and Oleg,

After reflection, I think it is not possible to merge with and letrec.
Indeed, since letrec is implemented with an abstraction (as Oleg rightly
pointed out), then any additional definition inside the definition of this
abstraction, will not be visible outside.

In other words, let's imagine that we have an extended letrec allowing also
regular definitions like u and v:

letrec {

'x = exp1;
'y = exp2;
'z = exp3;

u = exp4;
v = exp5;

}

it can be translated into:

with {

bodyrec = \(x,y,z).(exp1, exp2, exp3 with {u=exp4; v=exp5;});
x = bodyrec : _,!,!;
y = bodyrec : !,_,!;
z = bodyrec : !,!,_;

}

but only x, y, z can be seen from outside, not u and v. So, we will have to
find a syntax that makes these limitations very explicit, otherwise, it
will be very confusing for users who will have the same expectations as for
a with.

Yann


Le jeu. 30 juin 2022 à 01:22, Oleg Nesterov  a écrit :

> Hi Dario,
>
> On 06/29, Dario Sanfilippo wrote:
> >
> > On Tue, 28 Jun 2022 at 13:18, Oleg Nesterov  wrote:
> >
> > > Once I was greatly puzzled why letrec doesn't work as I'd expect, and
> > > I had to dig into the compiler sources to understand.
> > >
> > > For example, I think it is not immediately clear why this code
> > >
> > > process = _ : bug;
> > >
> > > bug = x,y letrec {
> > > 'x = _;
> > > 'y = 0;
> > > };
> > >
> > > doesn't even compile. IIUC, this is because buildRecursiveBodyDef()
> turns
> > > the code above into something like
> > >
> > > LETRECBODY = \(x, y).( ... ) ~ (_,_);
> > > // makeRecProjectionsList()
> > > x = LETRECBODY : _,!;
> > > y = LETRECBODY : !,_;
> > >
> >
> > Are there cases where makeRecProjectionList() isn't redundant?
>
> I don't know. Yes I think that compiler could "simply" generate a lambda
> expression, but perhaps I missed something.
>
> At least this is not that simple, I think. OK,
>
> process = x,y letrec {
> 'x = expr_x;
> 'y = expr_y;
> };
>
> can be translated to
>
> process = \(x,y).(expr_x, expr_y) ~ (_,_);
>
> But what about
>
> process = x+y letrec {
> 'x = expr_x;
> 'y = expr_y;
> };
>
> ?
>
> even this trivial case needs some modifications in the compiler, it
> should turn the lambda body into "expr_x + expr_y"...
>
> > As I was telling Yann in another conversation, I was thinking that
> > extending `with` to allow recursive definitions could be a good idea,
>
> I don't know. Personally, I do not think this is that useful, but this
> is just me.
>
> > To get back to the example in my first email, the code
> >
> > onePoleSwitching(att, rel, x) = y
> > with {
> > 'y = (1.0 - coeff) * x + coeff * y;
> > coeff = ba.if(x > y, ba.tau2pole(att), ba.tau2pole(rel));
> > };
> >
> > could be translated into
> >
> > onePoleSwitching(att, rel, x) =
> > \(y).((1.0 - coeff) * x + coeff * y
> > with {
> > coeff = ba.if(x > y, ba.tau2pole(att), ba.tau2pole(rel));
> > }
> > ) ~ _;
> >
> > Does that make sense?
>
> Not sure I understand... Do you mean the compiler can translate the
> 1st variant into the 2nd one? Probably. But you can do it yourself?
>
> I mean, I do not see why do you want "letrec" or "with { 'y = ...; }"
> in this case. I would simply write something like
>
> onePoleSwitching(att, rel) = func ~ _ with {
> func(y, x) = (1.0 - coeff) * x + coeff * y with {
> coeff = ...;
> };
> };
>
> To me it looks more clear than the 1st variant, and iiuc it is equivalent
> the 2nd one.
>
> Oleg.
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Combining the `with` and `letrec` environments in Faust

[Yann Orlarey]

Hi Dario,

I think it would be a great idea to make this unification between letrec
and with. The current implementation of letrec is extremely simple and
almost like syntactic sugar, so there is some work to do, but it should be
feasible of course...

Cheers,

Yann

Le dim. 26 juin 2022 à 13:49, Dario Sanfilippo 
a écrit :

> Hello, list.
>
> This is a topic that we've briefly discussed in past, and it has come to
> our attention again while working on some refactoring in the libraries with
> Stéphane.
>
> When implementing recursive systems, I often end up using this pattern as
> it allows me to write versatile and readable code:
>
> fun(param0, ..., paramN) = loop ~ si.bus(M)
> with {
> loop(state0, ..., stateM) = y0, ..., yM
> with {
> y0 = state0 * param0;
> ...
> };
> };
>
> Consider this function:
>
> onePoleSwitching(att, rel, x) = loop ~ _
> with {
> loop(yState) = (1.0 - coeff) * x + coeff * yState
> with {
> coeff = ba.if(x > yState, ba.tau2pole(att), ba.tau2pole(rel));
> };
> };
>
> We cannot write this using `letrec` as in this example:
>
> onePoleSwitching(att, rel, x) = y
> letrec {
> 'y = (1.0 - coeff) * x + coeff * y;
> }
> with {
> coeff = ba.if(x > y, ba.tau2pole(att), ba.tau2pole(rel));
> };
>
>
> since `y` is not visible within the `with` scope.
>
> We could write:
>
> onePoleSwitching(att, rel, x) = y
>
> letrec {
> 'coeff = ba.if(x > y, ba.tau2pole(att), ba.tau2pole(rel));
> 'y = (1.0 - coeff) * x + coeff * y;
> };
>
> but this would introduce a delay in the `coeff` signal, which would make
> the filter output not correct.
>
> What I was wondering is, since the first implementation using `with` is
> possible, could we combine `with` and `letrec` for a more concise and
> powerful environment such as the example below or is there anything that
> I'm missing in the syntax that makes it non-computable?
>
> onePoleSwitching(att, rel, x) = y
>
> with {
> 'y = (1.0 - coeff) * x + coeff * y;
> coeff = ba.if(x > y, ba.tau2pole(att), ba.tau2pole(rel));
> };
>
> Ciao,
> Dario
>
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
> ___
> 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

Re: [Faudiostream-users] [Faudiostream-devel] May 20, 2022: Two Google Summer of Code projects attributed

[Yann Orlarey]

That's a very good news !!! Also many thanks to Stephane for making that
possible.

Yann

Le sam. 21 mai 2022 à 13:46, Stéphane Letz  a écrit :

> Faust News
>
> >> May 20, 2022: Two Google Summer of Code projects attributed
>
> Two projects have finally been attributed to GRAME:
>
> • Faust Integration in HISE aims at integrating support for the
> Faust audio programming language into HISE, an extensive framework for the
> creation of sample-based virtual musical instruments. The project will be
> worked on by Roman Sommer.
>
> • Integrating Faust Into the Bespoke DAW aims at extending the
> modular Bespoke engine with Faust, allowing for both static compilation of
> modules, and potentially dynamic programming within Bespoke. The project
> will be worked on by Drew James.
>
> Welcome to both of you in the Faust community !
>
>
>
>
> ___
> Faudiostream-devel mailing list
> faudiostream-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Faust Survey 2022

[yann orlarey]

Hi,

Thank you to everyone who answered the Faust survey. We have already
received dozens of answers and it is very instructive! But we would like to
have many more ;-).

If you haven't answered the questionnaire yet, don't hesitate to do so,
it's quick and your answers will be extremely useful for us to improve
Faust and its ecosystem.

https://forms.gle/ijYpNH9mLMeTqGMV8

Yann



Le ven. 4 mars 2022 à 17:13, yann orlarey  a écrit :

> Hi,
>
> The FAUST community is growing steadily, so this year we decided to
> conduct a survey to better understand your use of FAUST and your
> expectations. Don't hesitate to fill in the questionnaire!
>
> https://forms.gle/ijYpNH9mLMeTqGMV8
>
> We will unveil the results on the occasion of the 20th anniversary of
> Faust, during the International Faust Conference, on June 7th and 8th in
> Saint-Etienne.
>
> We are counting on your presence! You can come with your hands in your
> pockets, but you can also propose a full paper or simply an abstract
> presenting in a few lines what you would like to talk about or present
> during these days.
>
> These two days are really open to our community, so don't be shy and don't
> hesitate to propose something. These days are also a pretext to meet and
> discuss!
>
> All the modalities to participate in IFC 2022 are here:
> https://smc22.grame.fr/ifc.html
>
> The deadline is, in principle, March 13, but we will probably extend it.
>
> We count on you for the questionnaire and for IFC.
>
> Thanks in anticipation!
>
> Yann
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] [IFC deadline extensions] International Faust Conference (IFC-22, June 7-8, 2022)

[Yann Orlarey]

Hi,

The submission date to IFC has been extended by 2 weeks. Here is the new
schedule:

Deadline for submitting papers: *March 27th, 2022*
Deadline for submitting reviews: *April 17th, 2022*
Notification of acceptance: *April 24th, 2022*


Don't forget that you can also submit workshops, demos, or tutorials. In
this case, the submission process is much lighter, you only need to provide
a one-page maximum abstract.

Yann

Le mar. 30 nov. 2021 à 14:47, Yann Orlarey  a écrit :

> IFC-22 Call for Papers
> ==
>
> The International Faust Conference aims at gathering researchers,
> developers, musicians, computer artists using the Faust programming
> language. The Third International Faust Conference (IFC-22) will propose
> sessions of paper presentations, as well as thematic round tables,
> demonstrations, and tutorials. Participants are encouraged to present
> current works, projects, etc., and to discuss future directions for Faust
> and its community.
>
> IFC-22 is organized by GRAME-CNCM, INRIA, and Université Jean Monnet in
> conjunction with SMC 2022. It will take place on June 7-8, 2022 at the
> Centre des Savoirs pour l’Innovation (CSI) of the Université Jean Monnet of
> Saint-Etienne (France). Interested parties can also attend the Sound and
> Music Computing Conference (SMC-22) 2022: https://smc22.grame.fr.
> Attending SMC as a free listener (i.e., without presenting a paper) is free
> of charge. Artistic events will take place during SMC 2022. Artists are
> encouraged to submit their work using the artistic call of SMC (see the
> "Artistic Track" section on https://smc22.grame.fr/calls.html).
>
> Guidelines for Submissions
> 
>
> Deadline for submitting papers: March 13th, 2022
> Deadline for submitting reviews: April 3th, 2022
> Notification of acceptance: April 10th, 2022
>
> Paper Submissions
> --
>
> We welcome submissions from academics, professionals, independent
> programmers, artists, etc. We solicit original papers centered around the
> Faust programming language in the following categories:
>
> - Original research
> - Technology tutorial
> - Demonstration
> - Artistic project report (e.g., installation, composition, etc.)
>
> Papers should be written in English, up to 14 pages in length,
> non-anonymous, and formatted according to the template provided on the
> conference website: https://smc22.grame.fr/misc/ifc22Template.zip. All
> submissions are subject to peer review. Acceptance may be conditional upon
> changes being made to the paper as directed by reviewers. Accepted papers
> will be published online. They will be presented by their author(s) at
> IFC-22.
>
> Paper submissions should be made through the SMC-22 EasyChair portal:
> https://easychair.org/conferences/?conf=smc2022 by selecting the "IFC-22
> Scientific Track."
>
> Workshop, Demo, or Tutorial Submissions
> 
>
> IFC-22 welcomes workshops, demos, and tutorials on various topics related
> to Faust. Submissions for these categories should take the form of a
> one-page pdf document (that will not be integrated to the proceedings)
> containing at least a title, an abstract, the name of presenter(s),
> equipment requirements, and the preferred duration (that should not exceed
> two hours).
>
> Workshop, demo, and tutorial proposals should be made through the SMC-22
> EasyChair portal: https://easychair.org/conferences/?conf=smc2022 by
> selecting the "IFC-22 Workshops, Demos, and Tutorials Track."
>
> Round Table Topics
> --
>
> A series of round tables on the following themes will take place:
>
> - Faust Tools (e.g., Architectures, IDE, Faust Code Generator, On-Line
> Services, etc.)
> - DSP in Faust and Faust Libraries (e.g., New Algorithms, New Libraries,
> Missing Functions, etc.)
> - Faust Compiler and Semantics
> - Other Topics / Open Session
>
> We solicit topic suggestions from the Faust community for each of these
> themes through this form: https://forms.gle/diiKHptV75rNYftM8
>
> Registration
> 
>
> IFC-22 is a completely free event (both for presenters and free auditors).
> Registration to IFC-22 will open at the end of Winter 2022. Stay tuned!
>
> Location
> ----
>
> The conference will take place room L219 at Centre des savoirs pour
> l'innovation of Saint-Étienne University: 11 Rue Dr Rémy Annino, 42000
> Saint-Étienne.
>
> Local Organization Committee
> -
>
> Stéphane Letz
> Romain Michon
> Yann Orlarey
> Laurent Pottier
>
> Steering Committee
> -

[Faudiostream-users] Faust Survey 2022

[yann orlarey]

Hi,

The FAUST community is growing steadily, so this year we decided to conduct
a survey to better understand your use of FAUST and your expectations.
Don't hesitate to fill in the questionnaire!

https://forms.gle/ijYpNH9mLMeTqGMV8

We will unveil the results on the occasion of the 20th anniversary of
Faust, during the International Faust Conference, on June 7th and 8th in
Saint-Etienne.

We are counting on your presence! You can come with your hands in your
pockets, but you can also propose a full paper or simply an abstract
presenting in a few lines what you would like to talk about or present
during these days.

These two days are really open to our community, so don't be shy and don't
hesitate to propose something. These days are also a pretext to meet and
discuss!

All the modalities to participate in IFC 2022 are here:
https://smc22.grame.fr/ifc.html

The deadline is, in principle, March 13, but we will probably extend it.

We count on you for the questionnaire and for IFC.

Thanks in anticipation!

Yann
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Open Science Award for Open Source Research Software for Faust

[Yann Orlarey]

Great birthday present for the 20th anniversary of the FAUST language!
Developed by Grame since 2002, supported by a whole community of users and
contributors, FAUST is one of the four winners of the Open Science Award
for Open Source Research Software (documentation category) awarded at the
Open Science European Conference (OSEC).

https://www.ouvrirlascience.fr/remise-des-prix-science-ouverte-du-logiciel-libre-de-la-recherche/

D. Fober, S. Letz, R. Michon, Y. Orlarey


*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 <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

Re: [Faudiostream-users] multiple simultaneous table read

[Yann Orlarey]

Hi Jean-Louis,

This is a very legitimate question. You have to use multiple rwtables. But,
as long as these tables differ only on the reading index, then the compiler
will optimize the code and share the table which will exist only in one
copy.

Yann

Le mer. 26 janv. 2022 à 15:08, Jean-Louis Paquelin 
a écrit :

> Dear Faust users,
>
> This is my second post on the list and I'm still a noob Faust programer,
> so please excuse me if the question is trivial.
>
> I'm trying to write a grain synth that processes samples stored in a
> rwtable and I'd like to play multiple grains at the same time. Should I use
> multiple tables containing the same samples or is there a way to
> parallelize the readings on a single table?
>
> Best regards,
>
> jlp
> ___
> 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

Re: [Faudiostream-users] Pattern matching question

[Yann Orlarey]

Hi Jean-Louis,

If the content is known at compile-time, an efficient approach to implement
a lookup table is to use a waveform and a read-only table. Here are two
examples.

The first one is very minimal, with no protection on the read index:

l1(i) = waveform{1,2,7,4,5,6}, i : rdtable;
process = 2 : l1 : hbargraph("value", 0, 10);

The second one makes use of a more general lut(wf) function with some
protection of the index:

lut(wf) = wf,fii : rdtable with {
n = wf : _,!; // n is the size of the waveform (first output)
fii = int,n : %; // makes sure incomming index is between 0 and n-1
};

l2 = lut(waveform{1,2,7,4,5,6});
process = hslider("index",0,0,20,1) : l2 : hbargraph("value", 0, 10);

Have a look at the corresponding block diagram, it is probably easier to
understand what's going on.

Concerning Stephane's example, the parallel composition (,) is missing
between the two expressions.

Cheers,

Yann


Le ven. 14 janv. 2022 à 11:24, Jean-Louis Paquelin 
a écrit :

> Hello Stéphane,
>
> I'm not 100% sure about what's going on when I run the line you wrote:
>
> process = _ <: (lut1 : hbargraph("B", 1, 5)) (lut2 : hbargraph("C", 1, 5));
>
> By writing _ <: you feed an audio data stream to the two lut functions
> instead of a lower rate data provided by the hslider. Am I right?
>
> And btw, I don't understand the syntax, I should have put a comma
> between the two lut calls.
>
> (I'm currently learning Faust. I'm in the 4th lesson of the Kadenze
> course. Please excuse me if it's noob question)
>
> Thanks,
>
> jlp
>
> Le jeu. 13 janv. 2022 à 19:27, Stéphane Letz  a écrit :
>
>> Note that your examples does the actual computation once per block. To
>> test the CPU, its better to have lut1/lut2 runs each sample, using
>> something like:
>>
>> process = _ <: (lut1 : hbargraph("B", 1, 5)) (lut2 : hbargraph("C", 1,
>> 5));
>>
>> Assuming you have installed faust locally, you can then use faustbench of
>> faustbench-lvm tools to measure CPU usage, see:
>>
>>
>> https://github.com/grame-cncm/faust/tree/master-dev/tools/benchmark#faustbench
>>
>>
>> https://github.com/grame-cncm/faust/tree/master-dev/tools/benchmark#faustbench-llvm
>>
>> Stéphane
>>
>> > Le 13 janv. 2022 à 19:05, Jean-Louis Paquelin 
>> a écrit :
>> >
>> > @James and @bart, thank you for your quick reply.
>> >
>> > So (if I understand you well) pattern matching should be thought of as
>> a static rewriting tool.
>> > And, btw, you're right
>> > process = 2 : lut : hbargraph("B", 1, 5);
>> > sets the bargraph to 2, while
>> > process = lut(2) : hbargraph("B", 1, 5);
>> > sets it to 3 (as expected).
>> >
>> > I came with 2 ways to write the lut() function I need:
>> >
>> > lut1(n) = 1,3,4,2,5 : ba.selectn(5, n - 1);
>> > lut2(n) = ((n == 1) | (n == 5)) * n + (n == 2) * 3 + (n == 3) * 4 + (n
>> == 4) * 2;
>> > process = hslider("A", 1, 1, 5, 1) <: (lut1 : hbargraph("B", 1, 5)),
>> (lut2 : hbargraph("C", 1, 5));
>> >
>> > Both functions seem to provide the service I'm asking for. But the
>> first one is more readable than the second.
>> > Any idea which one is the lightest for the CPU?
>> >
>> > Thanks again,
>> >
>> > jlp
>>
>> ___
> 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

[Faudiostream-users] PAW 2021

[Yann Orlarey]

*PAW 2021 : Programmable Audio Workshop, December 18, 2021 (Lyon, France)*

[PAW 2021](https://paw.grame.fr)

Programmable Audio Workshop on Procedural Audio. Instead of playing
recorded sounds in video games, Procedural Audio is about producing sounds
algorithmically through real-time synthesis methods. These models can be
controlled by various parameters, for example from the game engine in
relation to the player's actions.

The 6 talks and 4 workshops of PAW 2021, will offer a unique opportunity to
discover Procedural Audio in relation to video game engines!

*Registration*

PAW is completely free, but the number of seats is limited. Register online
at [PAW 2021 REGISTRATION](https://forms.gle/DPuoWut4PiF4FyKaA)

*Event Location*

UCLy-Université Catholique de Lyon, Campus Saint-Paul, 10 Place des
Archives, 69002 Lyon

*Program*

- 09:00-09:30: Registration

*Morning Talk*s

- 09:30-09:50: Welcome, Yann Orlarey (Scientific Director, GRAME, Lyon,
France)

- 09:50-10:10: Audio in Unreal with Faust, Ethan Geller (Audio Research
Software Engineer, Meta/Facebook, USA)

- 10:10-10:30: Video Game Engine as Media Creation Swiss Army Knife,
Michael Bolufer (Technical director at Plip! Animation and Studio Manette)
and Gabriel Malgouyard (Software Artisan, Realtime Multimedia Projects.)

- 10:30-11:00: Coffee Break

- 11:00-11:20: Physics Based Sonic Interactions, Stefania Serafin
(Professor of Sonic Interaction Design, Aalborg University)

- 11:20-11:40: Virtual Musical Instrument Design for the 21st Century, Rob
Hamilton (Head of the Department of Arts, Rensselaer Polytechnic Institute,
USA)

- 11:40-12:00: Mesh2faust: From 3D Meshes to Faust Physical Models, Romain
Michon (Faculty Researcher at INRIA (Emeraude team), Associate Researcher
at GRAME)

- 12:00-12:20: Spatial audio in Unity for an interactive immersive space,
David-Alexandre Chanel (THEORIZ / Augmenta, Lyon, France)

*Afternoon Workshops*

- 14:00-15:00: Procedural Audio with Faust (Romain Michon)
  The workshop is a practical introduction to procedural audio and Faust
programming. Different techniques of sound synthesis will be explored using
in particular the new Faust physical modeling libraries. The workshop does
not require the installation of any software except a recent web browser
like Firefox or Chrome. All examples will be programmed directly in the web
using the Faust IDE (https://faustide.grame.fr)

- 15:00-16:00: Physics Based Sonic Interactions in Practice (Stefania
Serafin)
  In the last decades, several physical modeling techniques have been
developed, such as waveguide models, mass-spring simulations, modal
synthesis and finite difference schemes, to name a few. Moreover, these
techniques have already been implemented in different software platforms
such as Max, Faust, Juce, Super Collider, as well as commercial products
such as SWAM by Audio Modelling. In this workshop we will look at recent
developments in modeling musical instruments, discussing advantages and
disadvantages of the different techniques. We will examine available tools
and choose one case study to examine in depth."

- 16:00-16:30: Coffee Break

- 16:30-17:30: Procedurally Spawned Faust Synths in Unreal (Ethan Geller)
  In this presentation, we are going to add a .dsp object as an audio
source in Unreal, procedurally spawn instances of it, and procedurally set
parameters on those instances to create a diffuse, procedurally generated
audiovisual experience. Before this presentation starts it is recommended
that you install Unreal Engine 5 and have some way to compile \`faust2api\`
on your computer."

- 17:30-18:30: Building Interactive Procedural Music Systems for Unreal
Engine 4 (Rob Hamilton)
  For artists and designers seeking to build software-based dynamic and
procedural audio and music systems, Epic Games' Unreal 4 gaming engine
offers a robust and battle-tested codebase optimized for real-time
multi-user interaction. Capable of rendering visual assets with astonishing
clarity and realism, Unreal 4 also boasts native Open Sound Control (OSC)
support, as well as a suite of native procedural audio components for
real-time audio synthesis. This workshop will explore the use of Unreal
Engine 4 for building interactive musical systems using Unreal's Blueprint
workflow programming environment, OSC, and Unreal's own synthesis
components"



*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 <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] International Faust Conference (IFC-22, June 7-8, 2022)

[Yann Orlarey]

IFC-22 Call for Papers
==

The International Faust Conference aims at gathering researchers,
developers, musicians, computer artists using the Faust programming
language. The Third International Faust Conference (IFC-22) will propose
sessions of paper presentations, as well as thematic round tables,
demonstrations, and tutorials. Participants are encouraged to present
current works, projects, etc., and to discuss future directions for Faust
and its community.

IFC-22 is organized by GRAME-CNCM, INRIA, and Université Jean Monnet in
conjunction with SMC 2022. It will take place on June 7-8, 2022 at the
Centre des Savoirs pour l’Innovation (CSI) of the Université Jean Monnet of
Saint-Etienne (France). Interested parties can also attend the Sound and
Music Computing Conference (SMC-22) 2022: https://smc22.grame.fr. Attending
SMC as a free listener (i.e., without presenting a paper) is free of
charge. Artistic events will take place during SMC 2022. Artists are
encouraged to submit their work using the artistic call of SMC (see the
"Artistic Track" section on https://smc22.grame.fr/calls.html).

Guidelines for Submissions


Deadline for submitting papers: March 13th, 2022
Deadline for submitting reviews: April 3th, 2022
Notification of acceptance: April 10th, 2022

Paper Submissions
--

We welcome submissions from academics, professionals, independent
programmers, artists, etc. We solicit original papers centered around the
Faust programming language in the following categories:

- Original research
- Technology tutorial
- Demonstration
- Artistic project report (e.g., installation, composition, etc.)

Papers should be written in English, up to 14 pages in length,
non-anonymous, and formatted according to the template provided on the
conference website: https://smc22.grame.fr/misc/ifc22Template.zip. All
submissions are subject to peer review. Acceptance may be conditional upon
changes being made to the paper as directed by reviewers. Accepted papers
will be published online. They will be presented by their author(s) at
IFC-22.

Paper submissions should be made through the SMC-22 EasyChair portal:
https://easychair.org/conferences/?conf=smc2022 by selecting the "IFC-22
Scientific Track."

Workshop, Demo, or Tutorial Submissions


IFC-22 welcomes workshops, demos, and tutorials on various topics related
to Faust. Submissions for these categories should take the form of a
one-page pdf document (that will not be integrated to the proceedings)
containing at least a title, an abstract, the name of presenter(s),
equipment requirements, and the preferred duration (that should not exceed
two hours).

Workshop, demo, and tutorial proposals should be made through the SMC-22
EasyChair portal: https://easychair.org/conferences/?conf=smc2022 by
selecting the "IFC-22 Workshops, Demos, and Tutorials Track."

Round Table Topics
--

A series of round tables on the following themes will take place:

- Faust Tools (e.g., Architectures, IDE, Faust Code Generator, On-Line
Services, etc.)
- DSP in Faust and Faust Libraries (e.g., New Algorithms, New Libraries,
Missing Functions, etc.)
- Faust Compiler and Semantics
- Other Topics / Open Session

We solicit topic suggestions from the Faust community for each of these
themes through this form: https://forms.gle/diiKHptV75rNYftM8

Registration


IFC-22 is a completely free event (both for presenters and free auditors).
Registration to IFC-22 will open at the end of Winter 2022. Stay tuned!

Location


The conference will take place room L219 at Centre des savoirs pour
l'innovation of Saint-Étienne University: 11 Rue Dr Rémy Annino, 42000
Saint-Étienne.

Local Organization Committee
-

Stéphane Letz
Romain Michon
Yann Orlarey
Laurent Pottier

Steering Committee
--

Alain Bonardi
Albert Gräf
Stéphane Letz
Romain Michon
Yann Orlarey




*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 <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

Re: [Faudiostream-users] Faust IDE scaled controls do not work the same

[Yann Orlarey]

Hi Steven,

That's right, we had to fix the behavior of the log and exp scales of the
IDE to be identical to those of other architectures. In a few words, in
most cases (for example for frequencies) you have to use the logarithmic
scale and not an exponential scale. The exponential scale is there for the
sake of symmetry, but I don't know of any application for it ;-).

To understand how it works, let's imagine a frequency slider between 20 and
2 Hz. Choosing a logarithmic scale corresponds to the fact that the
values under the slider are arranged according to a logarithmic scale (like
the keys of a keyboard, or like the values on the vertical axis of a graph
with a logarithmic scale), with more space and precision for the small
values and less and less space and precision for the big values.

Here is how the mapping is done. Let's imagine that the graphic position of
the slider is a number p between 0 and 1. 0 is the minimum value of the
slider and 1 is the maximum value of the slider. Let's also imagine that
the minimum value of the slider is LO and the maximum value HI. Then the
value delivered by the slider when it is in position p will be
exp((1-p)*log(LO)+p*log(HI)). Therefore, it is imperative that LO > 0 for
log(LO) to be defined.

I hope this explanation clarifies the semantics of the logarithmic scale...

Cheers,

Yann







Le mer. 22 sept. 2021 à 18:42, Steven Kraninger  a
écrit :

> I am not sure if this is only in the IDE, but the slider scaling has
> changed to be much more skewed and not really usable.
>
> For instance:
> modFreq(j) = hslider("t:EchoMatrix/v:[1]Delays/h:[3]ModFreq/MF
> U%j[scale:exp][style:knob]", 0.05, 0.0, 10.0, 0.001) : si.smoo ;
>
> Goes from 0 to 9 in the 1st (estimated) 1/20 of the range. This is not how
> it used to work.
> ___
> 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

Re: [Faudiostream-users] Parallel operators

[Yann Orlarey]

Hi Lucian,

A useful function, in this type of routing, is `ro.interleave(N,M)`. It has
the advantage of requiring less work for the compiler, especially when N or
M is large.


import("stdfaust.lib");

N = 10;
process = ro.interleave(N,2) : par(i,N,*);


https://faustide.grame.fr/?autorun=0=0=nbinop=aW1wb3J0KCJzdGRmYXVzdC5saWIiKTsKCk4gPSAxMDsKcHJvY2VzcyA9IHJvLmludGVybGVhdmUoTiwyKSA6IHBhcihpLE4sKik7Cgo%3D

Yann

Le mar. 7 sept. 2021 à 15:30, Lucian Boca  a écrit :

> Haha awesome, thanks James!
>
> I was just putting together a similar implementation based on your
> previous email, ended up with:
>
> ```
> bop(f, items) = par(i, N, f(ba.selector(i, N, items))) with { N =
> ba.count(items); };
> ```
>
> Super useful, thanks again!
>
> On Tue, Sep 7, 2021 at 2:26 PM James Mckernon  wrote:
>
>> On 9/7/21, James Mckernon  wrote:
>> > I haven't time to work out the details now.
>>
>> Why do I lie like this? I couldn't resist trying it. I think this
>> should be you what you want.
>>
>> ba = library("basics.lib");
>> bop(op, list) = par(i, ba.count(list), op(ba.take(i + 1,list)));
>> process = (1,2,3,4) : bop(*, (2,3,4,5));
>>
> ___
> 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

Re: [Faudiostream-users] vbargraph strange behavior

[Yann Orlarey]

Hi Klaus,

We recently made some changes to fix the logarithmic scale of the sliders
and bargraphs, but obviously, we broke the bargraphs in some conditions!

We'll try to fix that asap...

Yann


Le mar. 17 août 2021 à 12:05, Klaus Scheuermann  a écrit :

> Me again...
>
> Did something change in the behavior of vbargraph? It shows full red with
> values above 0.
>
> Video: https://cloud.4ohm.de/s/8WxPTobRKDyKXqe
>
> Code:
> import("stdfaust.lib");
> g = hslider("g",0,-50,50,1);
> process = _ <: attach(_,g : vbargraph("[2]gain",-50,50));
>
> Thanks, Klaus
>
>
>
> ___
> 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

Re: [Faudiostream-users] What's goin' on with Faust 2/3?

[Yann Orlarey]

Hi Ethan,

Thanks for asking. We are still working on a multi-rate version of Faust,
even if its development is not necessarily going as fast as we would like!
The idea is to introduce the multi-rate aspects as a new class of
primitives focusing on the signal processors themselves (rather than
operations on the signals). These new primitives allow controlling the time
base with which signal processors work.

Take a signal processor P with n inputs and m outputs, then ondemand(P) is
a new signal processor with n+1 inputs and always m outputs. The additional
input is a clock signal that controls when the computations are done.
Similarly, upsampling(P) and downsampling(P) add an input to control the
time base by a multiplying or dividing factor.

Upsampling and downsampling are essentially variants of ondemand. A
preliminary specification of ondemand is available here:
https://github.com/orlarey/faust-ondemand-spec

Cheers

Yann





Le sam. 31 juil. 2021 à 13:42, Ethan Geller  a
écrit :

> Hi folks,
>
> What's going on with Faust 2/3 stuff? A few years back there was some
> conversation around additional featuresets for multirate
> processing + frequency domain transforms. AFAIK, most of that conversation
> was happening in the sourceforge repo, but since Faust moved over to github
> I haven't seen any conversation or documentation around the Faust 2/3 work.
>
> Please don't take this as a criticism of Faust! It's a fantastic language
> as is and the work going on around the current Faust language spec is very
> cool. Just want to know if this work is still ongoing.
>
> --
> -Ethan
> ___
> 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

Re: [Faudiostream-users] par in process

[Yann Orlarey]

Hi Klaus,

Congrats, I don't know your programming background before starting this
project, but I think it is a remarkable achievement!

Yann

Le jeu. 29 juil. 2021 à 11:11, Klaus Scheuermann  a
écrit :

> Dear Yann,
>
> so here is a quick update. I managed to implement a multichannel version
> of my project master_me:
> https://github.com/trummerschlunk/master_me/blob/master/master_me_gui.dsp
>
> The noise-gate example was very helpful and by understanding par, si.bus,
> and signal routing in general, I could transfer the solution to my other
> building blocks.
>
> The only part, where I still rely on variables is the leveler's gating
> function. I guess the code is a bit dirty too, but it works...
> Feel free to optimize ;)
>
> Thanks again to you and to the whole list <3
>
> Klaus
>
>
> On 28.07.21 09:16, Klaus Scheuermann wrote:
>
> Hi Yann!
>
> Of course it works perfectly and I learned about par, si.bus and
> ro.interleave :)
>
> Thanks... will be back soon I guess ;)
>
> Klaus
>
>
> On 27.07.21 12:17, Yann Orlarey wrote:
>
> Hi Klaus,
>
> Thanks for the example. If I understand correctly, I think you can
> generalize:
>
> gate_stereo(thresh,att,hold,rel,x,y) = ggm*x, ggm*y with {
> ggm = gate_gain_mono(thresh,att,hold,rel,abs(x)+abs(y));
> };
>
> by the following definition:
>
> gate_any(N,thresh,att,hold,rel) = B <: B, (B :> ggm <: B) : ro.interleave(
> N,2) : par(i,N,*)
> with {
> B = si.bus(N);
> ggm = gate_gain_mono(thresh,att,hold,rel);
> };
> process = gate_any(4);
>
> Cheers,
>
> Yann
>
>
> Le mar. 27 juil. 2021 à 10:22, Klaus Scheuermann  a
> écrit :
>
>> Thanks Yann,
>>
>> I am learning, but still not succeeding...
>>
>> This is not my end-game, but maybe a good example that I can't solve...
>>
>> How would I make an N-channel (linked) gate out of this?
>> gate_stereo(thresh,att,hold,rel,x,y) = ggm*x, ggm*y with {
>> ggm = gate_gain_mono(thresh,att,hold,rel,abs(x)+abs(y));
>> };
>> gate_gain_mono(thresh,att,hold,rel,x) = x : extendedrawgate :
>> an.amp_follower_ar(att,rel) with {
>> extendedrawgate(x) = max(float(rawgatesig(x)),holdsig(x));
>> rawgatesig(x) = inlevel(x) > ba.db2linear(thresh);
>> minrate = min(att,rel);
>> inlevel = an.amp_follower_ar(minrate,minrate);
>> holdcounter(x) = (max(holdreset(x) * holdsamps,_) ~-(1));
>> holdsig(x) = holdcounter(x) > 0;
>> holdreset(x) = rawgatesig(x) < rawgatesig(x)'; // reset hold when raw
>> gate falls
>> holdsamps = int(hold*ma.SR);
>> };
>>
>> Thanks,
>> Klaus
>>
>>
>>
>>
>> On 26.07.21 16:27, Yann Orlarey wrote:
>>
>> Hi Klaus,
>>
>> You can give names to the input signals as in your example, but you don't
>> have to. In other words, instead of writing:
>>
>> process(x) = f(g(x));
>>
>> you can use a more idiomatic style, and write:
>>
>> process = g : f;
>>
>> Faust is inspired by Moses Schönfinkel's combinatory logic (1924) and
>> John Backus' FP (1977). The idea of Schönfinkel was to eliminate the need
>> for variables in mathematical logic. In functional programming, this style
>> is known as "point-free" or "tacit" programming.
>>
>> At first sight, it seems complicated to do without variables. But a
>> variable is just one way (among others) to move a value to its point of
>> use. In Faust, you can use the `_` and `!` primitives, as well as the five
>> operations of the block diagram algebra (or the route{} primitive) to
>> create complex routing to move signals to their point of use.
>>
>> The advantage of point-free expressions is that they are more modular and
>> often easier to generalize. Let say you want to write a
>> quadriphonic amplifier. You can write:
>>
>> amp4(v,x1,x2,x3,x4) = v*x1, v*x2, v*x3, v*x4;
>>
>> but it is better to write:
>>
>> amp4(v) = *(v), *(v), *(v), *(v);
>>
>> or even better to write:
>>
>> amp4(v) =  par(c,4,*(v));
>>
>> This is now easy to generalize to a variable number N of channels:
>>
>> anyamp(N,v) = par(c,N,*(v));
>>
>> (note: by convention, we use capital letters for parameters that need to
>> be known at compile-time, here N)
>>
>> You can now specialize this general definition, as in:
>>
>> amp4 = anyamp(4);
>> amp8 = anyamp(8);
>>
>> So much for the principle, on an extremely simple example. What you are
>> trying to do is probably more complicated. Don't hesitate to post a little
>&g

Re: [Faudiostream-users] par in process

[Yann Orlarey]

Hi Klaus,

Thanks for the example. If I understand correctly, I think you can
generalize:


gate_stereo(thresh,att,hold,rel,x,y) = ggm*x, ggm*y with {
ggm = gate_gain_mono(thresh,att,hold,rel,abs(x)+abs(y));
};


by the following definition:

gate_any(N,thresh,att,hold,rel) = B <: B, (B :> ggm <: B) : ro.interleave(N,
2) : par(i,N,*)
with {
B = si.bus(N);
ggm = gate_gain_mono(thresh,att,hold,rel);
};

process = gate_any(4);

Cheers,

Yann


Le mar. 27 juil. 2021 à 10:22, Klaus Scheuermann  a
écrit :

> Thanks Yann,
>
> I am learning, but still not succeeding...
>
> This is not my end-game, but maybe a good example that I can't solve...
>
> How would I make an N-channel (linked) gate out of this?
> gate_stereo(thresh,att,hold,rel,x,y) = ggm*x, ggm*y with {
> ggm = gate_gain_mono(thresh,att,hold,rel,abs(x)+abs(y));
> };
> gate_gain_mono(thresh,att,hold,rel,x) = x : extendedrawgate :
> an.amp_follower_ar(att,rel) with {
> extendedrawgate(x) = max(float(rawgatesig(x)),holdsig(x));
> rawgatesig(x) = inlevel(x) > ba.db2linear(thresh);
> minrate = min(att,rel);
> inlevel = an.amp_follower_ar(minrate,minrate);
> holdcounter(x) = (max(holdreset(x) * holdsamps,_) ~-(1));
> holdsig(x) = holdcounter(x) > 0;
> holdreset(x) = rawgatesig(x) < rawgatesig(x)'; // reset hold when raw
> gate falls
> holdsamps = int(hold*ma.SR);
> };
>
> Thanks,
> Klaus
>
>
>
>
> On 26.07.21 16:27, Yann Orlarey wrote:
>
> Hi Klaus,
>
> You can give names to the input signals as in your example, but you don't
> have to. In other words, instead of writing:
>
> process(x) = f(g(x));
>
> you can use a more idiomatic style, and write:
>
> process = g : f;
>
> Faust is inspired by Moses Schönfinkel's combinatory logic (1924) and John
> Backus' FP (1977). The idea of Schönfinkel was to eliminate the need for
> variables in mathematical logic. In functional programming, this style is
> known as "point-free" or "tacit" programming.
>
> At first sight, it seems complicated to do without variables. But a
> variable is just one way (among others) to move a value to its point of
> use. In Faust, you can use the `_` and `!` primitives, as well as the five
> operations of the block diagram algebra (or the route{} primitive) to
> create complex routing to move signals to their point of use.
>
> The advantage of point-free expressions is that they are more modular and
> often easier to generalize. Let say you want to write a
> quadriphonic amplifier. You can write:
>
> amp4(v,x1,x2,x3,x4) = v*x1, v*x2, v*x3, v*x4;
>
> but it is better to write:
>
> amp4(v) = *(v), *(v), *(v), *(v);
>
> or even better to write:
>
> amp4(v) =  par(c,4,*(v));
>
> This is now easy to generalize to a variable number N of channels:
>
> anyamp(N,v) = par(c,N,*(v));
>
> (note: by convention, we use capital letters for parameters that need to
> be known at compile-time, here N)
>
> You can now specialize this general definition, as in:
>
> amp4 = anyamp(4);
> amp8 = anyamp(8);
>
> So much for the principle, on an extremely simple example. What you are
> trying to do is probably more complicated. Don't hesitate to post a little
> diagram if you need help...
>
> Cheers,
>
>
> Yann
>
>
> Le lun. 26 juil. 2021 à 10:23, Klaus Scheuermann  a
> écrit :
>
>> Hi All,
>>
>> so for stereo, I have
>> process(x1,x2) = x1,x2;
>>
>> How would I use 'par' in 'process' for N-channel operation?
>>
>> (I need the inputs x1, x2, xN later in a function.)
>>
>> Maybe a list with N entries?
>>
>> Thanks, Klaus
>>
>>
>> ___
>> 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

Re: [Faudiostream-users] par in process

[Yann Orlarey]

Hi Klaus,

You can give names to the input signals as in your example, but you don't
have to. In other words, instead of writing:

process(x) = f(g(x));

you can use a more idiomatic style, and write:

process = g : f;

Faust is inspired by Moses Schönfinkel's combinatory logic (1924) and John
Backus' FP (1977). The idea of Schönfinkel was to eliminate the need for
variables in mathematical logic. In functional programming, this style is
known as "point-free" or "tacit" programming.

At first sight, it seems complicated to do without variables. But a
variable is just one way (among others) to move a value to its point of
use. In Faust, you can use the `_` and `!` primitives, as well as the five
operations of the block diagram algebra (or the route{} primitive) to
create complex routing to move signals to their point of use.

The advantage of point-free expressions is that they are more modular and
often easier to generalize. Let say you want to write a
quadriphonic amplifier. You can write:

amp4(v,x1,x2,x3,x4) = v*x1, v*x2, v*x3, v*x4;

but it is better to write:

amp4(v) = *(v), *(v), *(v), *(v);

or even better to write:

amp4(v) =  par(c,4,*(v));

This is now easy to generalize to a variable number N of channels:

anyamp(N,v) = par(c,N,*(v));

(note: by convention, we use capital letters for parameters that need to be
known at compile-time, here N)

You can now specialize this general definition, as in:

amp4 = anyamp(4);
amp8 = anyamp(8);

So much for the principle, on an extremely simple example. What you are
trying to do is probably more complicated. Don't hesitate to post a little
diagram if you need help...

Cheers,


Yann


Le lun. 26 juil. 2021 à 10:23, Klaus Scheuermann  a
écrit :

> Hi All,
>
> so for stereo, I have
> process(x1,x2) = x1,x2;
>
> How would I use 'par' in 'process' for N-channel operation?
>
> (I need the inputs x1, x2, xN later in a function.)
>
> Maybe a list with N entries?
>
> Thanks, Klaus
>
>
> ___
> 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

Re: [Faudiostream-users] limit a value

[Yann Orlarey]

Hi Klaus and Giuseppe,

A simple and efficient implementation can be done using the min and max
primitives:


limit(lo,hi) = min(hi) : max(lo);


Cheers

Yann

Le lun. 19 juil. 2021 à 11:07, Giuseppe Silvi via Faudiostream-users <
faudiostream-users@lists.sourceforge.net> a écrit :

> Hi Klaus,
>
> import("stdfaust.lib");
>
> minn = hslider("minimum", -6, -10, 0, 0.1);
> maxx = hslider("maximum", +6, 0, 10, 0.1);
>
> // limit
> limit(minn,maxx) = _ <: ba.if( _ < minn, minn , _) <: ba.if( _ > maxx,
> maxx, _);
>
> process = os.osc(1000) : limit(minn,maxx);
> //process = os.osc(1000)*5 : limit(-3,4);
>
> Ciao!
> G
>
>
> > On 19 Jul 2021, at 10:46, Klaus Scheuermann  wrote:
> >
> > this one is probably simple, but I did not find anything in the syntax
> or libraries.
> >
> > How do I limit a value or signal with a min and a max so it never
> exceeds this range?
> >
> > Something like:
> >
> > min = -3;
> > max = 4;
> > process = _ : limit(min,max) : _
> >
> > I mean, I did try to implement it, but it does not work ;) :
> >
> > // limit
> > limit(x) = ba.if( x < minimum, minimum , x) : ba.if( x > maximum,
> maximum, x) with {
> > minimum = hslider("minimum", -6, -10, 0, 1);
> > maximum = hslider("maximum", +6, 0, 10, 1);
> > };
> > ___
> > 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
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] lufs loudness analyser

[Yann Orlarey]

Hi Julius,

I didn't mention it to simplify my point, but it's absolutely right:

float2fix(n) = *(2^n) : int;
fix2float(n) = float : /(2^n);
rms3(n) = _ <: _, (^(2) : float2fix(16) <: _,@(n) : - : +~_ : fix2float(16)
: /(n) : sqrt : vbargraph("rms3", 0, 1.42)) : attach;

Cheers

Yann


Le mar. 13 juil. 2021 à 03:14, Julius Smith  a
écrit :

> Hi Yann,
>
> That looks much better!
>
> However, I think the roundoff error will still grow in the integrator,
> unless the shifted delayed value (which is subtracted) is exactly the same
> bit pattern as its undelayed counterpart.  This can be arranged by
> converting to fixed-point and leaving enough guard bits to accommodate the
> dynamic range needed.  Alternatively, of course a TIIR version can be
> implemented.
>
> Cheers,
> Julius
>
> On Mon, Jul 12, 2021 at 3:28 PM Yann Orlarey  wrote:
>
>> Hi Julius and Dario,
>>
>> Sliding sums written as:
>>
>> sliding_sum(n) = (+ ~ _) <: _, @(n) : -;
>>
>> accumulate errors (because the integral value is ever-growing, its
>> precision decrease with time).
>>
>> This is why it is better to first subtract then integrate as in :
>>
>> sliding_sum(n) = _ <: _,@(n) : - : +~_ ;
>>
>> Here is an example that shows the problem. Set the level to the maximum
>> for a while (10s), then decrease the level to 0.1 and you will see that the
>> rms2 value is wrong for this level. Do it again and the rms2 value becomes
>> wrong for slightly higher values. etc.
>>
>> import("stdfaust.lib");
>>
>> W=4410;
>>
>> rms1(n) = _ <: _, (^(2) <: _,@(n) : - : +~_ : /(n) : sqrt : vbargraph(
>> "rms1", 0, 1.42)) : attach;
>> rms2(n) = _ <: _, (^(2) <: ba.slidingSum(n) : /(n) : sqrt : vbargraph(
>> "rms2", 0, 1.42)) : attach;
>>
>> process = hgroup("Compare RMS", os.osc(440) * vslider("level", 0, 0, 2,
>> 0.001) <: rms1(W),rms2(W));
>>
>>
>> here is the equivalent link:
>>
>>
>> https://faustide.grame.fr/?autorun=1=0=rms=aW1wb3J0KCJzdGRmYXVzdC5saWIiKTsKClc9NDQxMDsKCnJtczEobikgPSBfIDw6IF8sICheKDIpIDw6IF8sQChuKSA6IC0gOiArfl8gOiAvKG4pIDogc3FydCA6IHZiYXJncmFwaCgicm1zMSIsIDAsIDEuNDIpKSA6IGF0dGFjaDsKcm1zMihuKSA9IF8gPDogXywgKF4oMikgPDogYmEuc2xpZGluZ1N1bShuKSA6IC8obikgOiBzcXJ0IDogdmJhcmdyYXBoKCJybXMyIiwgMCwgMS40MikpIDogYXR0YWNoOwoKcHJvY2VzcyA9IGhncm91cCgiQ29tcGFyZSBSTVMiLCBvcy5vc2MoNDQwKSAqIHZzbGlkZXIoImxldmVsIiwgMCwgMCwgMiwgMC4wMDEpIDw6IHJtczEoVykscm1zMihXKSk7Cg%3D%3D
>>
>> Cheers
>>
>> Yann
>>
>>
>>
>> Le dim. 11 juil. 2021 à 23:36, Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> a écrit :
>>
>>> Dear Julius,
>>>
>>> On Sun, 11 Jul 2021 at 22:26, Julius Smith 
>>> wrote:
>>>
>>>> > This appears to have two inputs, is it possible that something is
>>>> missing?
>>>>
>>>> Yes, I should have defined it with "_ <: " at the input.  Also, it's
>>>> not a solution to our puzzle - sorry for the noise.  Let me know if you
>>>> prefer that I wait until I can actually test things before emailing - I've
>>>> been including Faust code as an expression of ideas in conversation,
>>>> sometimes bad ideas! :-).
>>>>
>>>
>>> I feel privileged to be able to interact with you and I've learnt so
>>> much thanks to our exchanges during my little Faust adventure, so, by all
>>> means, please do write any ideas that you have. I'm only sorry that I can't
>>> always keep up with everything, but that's my limitation. :-)
>>>
>>>
>>>>
>>>> > Just to be sure that I understand, when you say to never round, do
>>>> you imply to never use an integrator? And that also implies using N_w - 1
>>>> sums for a sliding window of N_w samples?
>>>>
>>>> I mean that the integrator has to be exact, so that it is "reversible"
>>>> by subtracting what went into it.  However, that does not bypass the need
>>>> for an eventual reset.
>>>>
>>>> Here is a debugged and TESTED version of what I was going for:
>>>>
>>>
>>> Great, I'll look into this.
>>>
>>>
>>>>
>>>> import("stdfaust.lib");
>>>>
>>>> durSamples = 8;
>>>> DUR_SAMPLES_MAX = durSamples*2;
>>>>
>>>> sliding_sum(durSamples) = _ : (+ ~ _) <: _, @(int(durSamples)) : -;
>>>> sliding_mean(durSamples) = sliding_sum(durSamples) / dur

Re: [Faudiostream-users] lufs loudness analyser

[Yann Orlarey]

Hi Julius and Dario,

Sliding sums written as:

sliding_sum(n) = (+ ~ _) <: _, @(n) : -;

accumulate errors (because the integral value is ever-growing, its
precision decrease with time).

This is why it is better to first subtract then integrate as in :

sliding_sum(n) = _ <: _,@(n) : - : +~_ ;

Here is an example that shows the problem. Set the level to the maximum for
a while (10s), then decrease the level to 0.1 and you will see that the
rms2 value is wrong for this level. Do it again and the rms2 value becomes
wrong for slightly higher values. etc.

import("stdfaust.lib");

W=4410;

rms1(n) = _ <: _, (^(2) <: _,@(n) : - : +~_ : /(n) : sqrt : vbargraph("rms1"
, 0, 1.42)) : attach;
rms2(n) = _ <: _, (^(2) <: ba.slidingSum(n) : /(n) : sqrt : vbargraph("rms2"
, 0, 1.42)) : attach;

process = hgroup("Compare RMS", os.osc(440) * vslider("level", 0, 0, 2,
0.001) <: rms1(W),rms2(W));


here is the equivalent link:

https://faustide.grame.fr/?autorun=1=0=rms=aW1wb3J0KCJzdGRmYXVzdC5saWIiKTsKClc9NDQxMDsKCnJtczEobikgPSBfIDw6IF8sICheKDIpIDw6IF8sQChuKSA6IC0gOiArfl8gOiAvKG4pIDogc3FydCA6IHZiYXJncmFwaCgicm1zMSIsIDAsIDEuNDIpKSA6IGF0dGFjaDsKcm1zMihuKSA9IF8gPDogXywgKF4oMikgPDogYmEuc2xpZGluZ1N1bShuKSA6IC8obikgOiBzcXJ0IDogdmJhcmdyYXBoKCJybXMyIiwgMCwgMS40MikpIDogYXR0YWNoOwoKcHJvY2VzcyA9IGhncm91cCgiQ29tcGFyZSBSTVMiLCBvcy5vc2MoNDQwKSAqIHZzbGlkZXIoImxldmVsIiwgMCwgMCwgMiwgMC4wMDEpIDw6IHJtczEoVykscm1zMihXKSk7Cg%3D%3D

Cheers

Yann



Le dim. 11 juil. 2021 à 23:36, Dario Sanfilippo 
a écrit :

> Dear Julius,
>
> On Sun, 11 Jul 2021 at 22:26, Julius Smith  wrote:
>
>> > This appears to have two inputs, is it possible that something is
>> missing?
>>
>> Yes, I should have defined it with "_ <: " at the input.  Also, it's not
>> a solution to our puzzle - sorry for the noise.  Let me know if you prefer
>> that I wait until I can actually test things before emailing - I've been
>> including Faust code as an expression of ideas in conversation, sometimes
>> bad ideas! :-).
>>
>
> I feel privileged to be able to interact with you and I've learnt so much
> thanks to our exchanges during my little Faust adventure, so, by all means,
> please do write any ideas that you have. I'm only sorry that I can't always
> keep up with everything, but that's my limitation. :-)
>
>
>>
>> > Just to be sure that I understand, when you say to never round, do you
>> imply to never use an integrator? And that also implies using N_w - 1 sums
>> for a sliding window of N_w samples?
>>
>> I mean that the integrator has to be exact, so that it is "reversible" by
>> subtracting what went into it.  However, that does not bypass the need for
>> an eventual reset.
>>
>> Here is a debugged and TESTED version of what I was going for:
>>
>
> Great, I'll look into this.
>
>
>>
>> import("stdfaust.lib");
>>
>> durSamples = 8;
>> DUR_SAMPLES_MAX = durSamples*2;
>>
>> sliding_sum(durSamples) = _ : (+ ~ _) <: _, @(int(durSamples)) : -;
>> sliding_mean(durSamples) = sliding_sum(durSamples) / durSamples;
>>
>> process = 1.0 : sliding_sum(durSamples);
>>
>> However, this does not fully solve the sliding mean problem, except for
>> sufficiently short runs.
>> Here is a simple test output:
>>
>> > faust2plot tslidingmean.dsp && tslidingmean
>> tslidingmean;
>> % Usage: octave --persist thisfile.m
>>
>> faustout = [ ...
>>  1; ...
>>  2; ...
>>  3; ...
>>  4; ...
>>  5; ...
>>  6; ...
>>  7; ...
>>  8; ...
>>  8; ...
>>  8; ...
>> ...
>>
>> I'll post my TIIR solution when I have time to write AND TEST it, unless
>> of course someone beats me to it.
>>
>
> I'm really looking forward to this too. Thank you so much for your work.
> :-)
>
> Dario
>
>
>>
>> Cheers,
>> Julius
>>
>>
>>
>>
>> On Sun, Jul 11, 2021 at 2:43 AM Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> wrote:
>>
>>> Hi, Julius.
>>>
>>> Sure, I now see what you mean about delay lines, but I'd guess that the
>>> required sums would make it pretty heavy even if it compiled quickly.
>>>
>>> On Sun, 11 Jul 2021 at 09:07, Julius Smith 
>>> wrote:
>>>
 On third thought, I now see how subtraction is not exact (it depends on
 what shifts are needed at addition/subtraction time, which can differ).
 The idea is to effectively never round, only summation and the
 delayed subtraction, so that subtraction after the delay is exact, avoiding
 a TIIR requirement.
 It should be possible to accomplish this by converting to fixed-point,
 etc.  I'm back to thinking about the TIIR case...

 On Sat, Jul 10, 2021 at 12:02 PM Julius Smith 
 wrote:

> On second thought, I don't see at the moment how anything can go wrong
> with this:
>
> sliding_mean(durSamples) = (+ ~ _) - @(int(durSamples)) :
> /(durSamples);
>

>>> This appears to have two inputs, is it possible that something is
>>> missing?
>>>
>>> Just to be sure that I understand, when you say to never round, do you
>>> imply to never use an integrator? And that also implies using N_w - 1 sums
>>> for a sliding 

[Faudiostream-users] Faustservice updated

[Yann Orlarey]

Hi!

Faustservice, the remote Faust compiler (https://faustservice.grame.fr/)
has been updated to the latest version: 2.33.1.

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 <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

Re: [Faudiostream-users] [Faudiostream-devel] Moving the Faust lists on a more permissive environment, or increasing the bytes limit.

[Yann Orlarey]

And I unblocked the messages that were blocked because of the size...

Yann

Le dim. 11 juil. 2021 à 12:31, Stéphane Letz  a écrit :

> I’ve just raised the size limit to 999 KB, which the the biggest value
> that the mailman system allows.
>
> Stéphane
>
> > Le 11 juil. 2021 à 12:02, Dario Sanfilippo 
> a écrit :
> >
> > Hi, list.
> >
> > Even without images, which sometimes would be great to just be able to
> attach rather than putting them online and including a link in the email
> body, we easily hit the 100 KB size limit.
> >
> > As far as I can tell, there is no moderation so the waiting-for-approval
> messages would just get lost.
> >
> > In the era of automatic video streaming on social media apps, is that
> bytes limit reasonable?
> >
> > Personally, I'd love to be able to attach images to my emails, and
> definitely never worry about the size limit when the thread is just text.
> >
> > Ciao,
> > Dr Dario Sanfilippo
> > http://dariosanfilippo.com
> >
> >
> > -- Forwarded message -
> > From: 
> > Date: Sun, 11 Jul 2021 at 11:44
> > Subject: Your message to Faudiostream-users awaits moderator approval
> > To: 
> >
> >
> > Your mail to 'Faudiostream-users' with the subject
> >
> > Re: [Faudiostream-users] lufs loudness analyser
> >
> > Is being held until the list moderator can review it for approval.
> >
> > The reason it is being held:
> >
> > Message body is too big: 106577 bytes with a limit of 100 KB
> >
> > Either the message will get posted to the list, or you will receive
> > notification of the moderator's decision.  If you would like to cancel
> > this posting, please visit the following URL:
> >
> >
> https://lists.sourceforge.net/lists/confirm/faudiostream-users/a2e7639898133b38b6bd8a8f2db9e846dfe0ba2d
> >
> > ___
> > Faudiostream-users mailing list
> > Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
>
> ___
> Faudiostream-devel mailing list
> faudiostream-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Fwd: Open permanent position at Arturia

[Yann Orlarey]

-- Forwarded message -
De : Samuel Limier 
Date: mer. 12 mai 2021 à 13:14
Subject: Open permanent position at Arturia
To: 


* Apologies for cross-posting *

Dear list,

We're opening up a permanent position for a senior digital signal
processing PhD graduate / engineer at Arturia (the company is based in
Grenoble, France).
Here is the job advertisement:
https://jobs.arturia.com/o/digital-signal-processing-engineer

Please feel free to share with those who might be interested.

Thanks, and best wishes,
Samuel
-- 
Samuel LIMIER DSP Manager
t.+33 438 020 555 — f.+33 438 020 525


___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Fix ADSR envelope:

[Yann Orlarey]

Hi Oleg,

Thank you for these elements, you are obviously welcome to join the
discussion!

Y

Le mar. 11 mai 2021 à 15:40, Oleg Nesterov  a écrit :

> Hi,
>
> I noticed by accident your discussion in
> https://github.com/grame-cncm/faustlibraries/pull/80
>
> ===
> From @orlarey:
>
> Your ADSR uses a variable slope for the release. This induces a
> different
> behavior when the gate is shorter than the AD part. That can make
> sense,
> but replacing the ADSR function with yours would potentially break
> the
> users' code that relies on the actual behavior.
>
> Yann, please note that (afaics) the current behaviour was introduced
> by a70abf508322 ("New faster ADSR envelop generator."), the fix from
> Andrey seems to restore the old behaviour before that commit.
>
> Please see the test-case below, the last 2 outputs are the same.
>
> IIR I too tried to report that after a70abf508322 adsr() reacts
> to gate=0 differently... probably
> https://sourceforge.net/p/faudiostream/mailman/message/36643370/
>
> Oleg.
>
>
> ---
> import("stdfaust.lib");
>
> // adsr before a70abf508322 ("New faster ADSR envelop generator.")
> old(a,d,s,r,t) = on*(ads) : ba.sAndH(on) : rel
> with{
> on = t>0;
> off = t==0;
> attTime = ma.SR*a;
> decTime = ma.SR*d;
> relTime = ma.SR*r : max(0.001);
> sustainGain = t*s;
> ads = ba.countup(attTime+decTime,off) : ba.bpf.start(0,0) :
> ba.bpf.point(attTime,1) :
> ba.bpf.end(attTime+decTime,sustainGain);
> rel = _,ba.countup(relTime,on) : ba.bpf.start(0) :
> ba.bpf.end(relTime,0);
> };
>
> // adsr with Andrey Bundin's fix applied
> new(at,dt,sl,rt,gate) = ADS : *(1-R) : max(0)
> with {
>
> // Durations in samples
> an = max(1, at*ma.SR);
> dn = max(1, dt*ma.SR);
> rn = max(1, rt*ma.SR);
>
> // Deltas per samples
> adelta = 1/an;
> ddelta = (1-sl)/dn;
>
>
> // Attack time (starts when gate changes and raises until gate == 0)
> atime = +(gate) ~ *(gate' >= gate);
>
> // Attack curve
> A = atime * adelta;
>
> // Decay curve
> D0 = 1 + an * ddelta;
> D = D0 - atime * ddelta;
>
> // ADS part
> ADS = min(A, max(D, sl));
>
> // Release time starts when gate is 0
> rtime = (+(1) : *(gate == 0)) ~ _;
>
> // Release curve starts when gate is 0 with the current value of the
> envelope
> R = rtime/rn;
> };
>
> process = ba.pulsen(ba.sec2samp(.09), ba.sec2samp(1/2)) : @(1000)
> <: _, en.adsr(0.1,0.1,0.1, 1), old(0.1,0.1,0.1, 1),
> new(0.1,0.1,0.1, 1);
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Inputs as arguments

[Yann Orlarey]

Hi,

Strings are not first-class citizens in Faust. For this reason you can't
write: `"test", -1, 1, x : vbargraph`. Therefore `vbargraph` alone, is not
a valid signal processor and only the form `vbargraph("test",-1,1)` is a
valid one (compiler/parser/faustparser.y:700). It's the same for all UI
elements.

But you can still write:

process(x) = vbargraph("test", -1, 1)(x);


Cheers

Yann

Le dim. 2 mai 2021 à 01:19, Julius Smith  a écrit :

> I am no expert on the compiler, but it looks to me like there is a missing
> signature for vbargraph defining the four-argument case.  There is a
> similar restriction with button, checkbox, etc., but vgroup and hgroup have
> explicit block-diagram arguments that cannot be "curried out", so to speak.
>
> Maybe the right way to think about it is that "User Interface Elements"
> are not Faust functions in the usual sense,  but something else?  It seems
> like it shouldn't be hard to integrate them more completely, but again,
> I've not looked at the details. Maybe they're parsed separately somehow...
>
> - Julius
>
> On Sat, May 1, 2021 at 9:56 AM Dario Sanfilippo <
> sanfilippo.da...@gmail.com> wrote:
>
>> Thank you for your answers, Oleg and Stéphane.
>>
>> I was wrong assuming that, at least for run-time cases, inputs could
>> always be provided as arguments. If I'm not wrong, that is always possible
>> with Faust-implemented functions (non-primitives).
>>
>> Ciao,
>> Dario
>>
>> On Sat, 1 May 2021 at 18:41, Stéphane Letz  wrote:
>>
>>>
>>>
>>> > Le 1 mai 2021 à 18:37, Oleg Nesterov  a écrit :
>>> >
>>> > Hi Dario,
>>> >
>>> > I can't answer authoritatively, but nobody else bothered to reply and
>>> > I hate the fact this list has a lot of unanswered technical questions.
>>> >
>>> > Add Stephane.
>>> >
>>> > On 04/25, Dario Sanfilippo wrote:
>>> >>
>>> >> Hello, list.
>>> >>
>>> >> I may be missing something obvious but would you know why
>>> >>
>>> >> process(x) = x : vbargraph("test", -1, 1);compiles
>>> >>
>>> >> while
>>> >>
>>> >> process(x) = vbargraph("test", -1, 1, x);
>>> >>
>>> >> doesn't?
>>> >
>>> > Because I think this is literally syntax error.
>>> >
>>> > See compiler/parser/faustparser.y:701
>>> >
>>> >   vbargraph   : VBARGRAPH LPAR uqstring PAR argument
>>> PAR argument RPAR
>>> >
>>> > This means that faust simply can't parse, for example,
>>> >
>>> >   process = 0;
>>> >   unused = vbargraph("test", 0,0,0);
>>> >
>>> > Oleg.
>>>
>>> Yes it it a syntax error, bargraph expects 3 arguments.
>>>
>>> Stéphane
>>>
>>> >
>>>
>>> ___
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>
>
> --
> "Anybody who knows all about nothing knows everything" -- Leonard Susskind
> ___
> 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

[Faudiostream-users] Call for applications / appel à candidatures du SCRIME

[Yann Orlarey]

The Computer Science and Experimental Music Creation and Research Studio
(SCRIME, https://scrime.u-bordeaux.fr/) is recruiting:

   - a software platform engineer on a renewable 1-year fixed-term
   contract.

Located on the Peixotto campus (Sciences and technologies) of the
University of Bordeaux and relying on a community of researchers and
artists, SCRIME provides the scientific and cultural community with a range
of R services in science, techniques and arts of sound and music.
The SCRIME was set up by the Bordeaux Computer Science Research Laboratory
(LaBRI). Its aim is to provide researchers and artists with an integrated
set of complex hardware and software tools for scientific and artistic
experimentation.

*Engineer's missions*
Within the SCRIME and in relation with the LaBRI, the software platform
engineer ensures the management, development, maintenance in operational
condition, operation and support to users of the platform software

*Main activities* :
- Check the relevance and functional performance of the platform's software
- Propose application evolutions (functional or technical)
- Participate in the software development of the platform
- Participate in the definition and enforce service level agreements
- Pool best practices in the use of platform software
- Resolve or report incidents and optimize performance
- Effectively control and plan changes to applications and / or software
- Participate in the development of consultation, control and management
tools (scripts, procedures, requests, reporting)
- Anticipate changes and their impacts on the platform's productions
- Write functional and technical documentation
- Participate in the training of users and contributors to the platform

*Knowledge*
Architecture and technical environment of the information system
Project management methodology
Composition process and music production
Information systems (in-depth knowledge)
Security of information and communication systems
Digital audio studio applications: sequencers (audacity, OSSIA-score,
reaper, Abbleton Live)
Programming language: C ++, javascript, C, java, lisp
Music processing languages: supercollider, MAX, puredata, FAUST
Spatialization techniques and systems (ambisonics, vbap, HOA, MOSCA)
Digital audio processing techniques for sound and music (analysis,
synthesis, treatments)
Image processing tools (OpenFrameWorks)
Change management techniques (general knowledge)
Repository of good practices (general knowledge)
Environment and professional networks
Technical English (general knowledge)
Music (knowledge and practice)

*Operational skills*
Team working
Dialogue with artists and researchers
Explain the needs and prioritize them
Anticipate functional and technical developments
Support changes (mastery)
Play an advisory or decision-making role
Communicate and demonstrate pedagogy
Facilitate training workshops on creative tools
Supervise / Lead a team
Write reports

*Behavioral skills*
Prospective ability
Affinity for experimentation
Reactivity Sense of confidentiality

*Application form:* CV and a cover letter to send to Myriam
Desainte-Catherine (myriam.desainte-cather...@labri.fr)
*Deadline for sending the file*: June 30, 2021.
*Start of CDD:* possible start from September 2021
*Position:* IE or IR
For more information on the position, contact Myriam Desainte-Catherine,
SCRIME director.
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Fwd: [ubimus] [CFP] Extended deadline (April 25): Eleventh Workshop on Ubiquitous Music (UbiMus 2021)

[Yann Orlarey]

-- Forwarded message -
De : Gilberto Bernardes Almeida 
Date: ven. 16 avr. 2021 à 11:46
Subject: [ubimus] [CFP] Extended deadline (April 25): Eleventh Workshop on
Ubiquitous Music (UbiMus 2021)
To: ubiquitousmu...@googlegroups.com 


*++  Eleventh Workshop on Ubiquitous Music (UbiMus 2021)*
*++  6-8 September 2021 *
*++  *https://dei.fe.up.pt/ubimus/

++  Please distribute
++ Apologies for cross-posting

*++  Paper and Music EXTENDED submissions* *deadline: April 25, 2021*

*Ubiquitous Music is an interdisciplinary research area that combines
methodologies from music, computer science, education, creativity studies,
human sciences and engineering. **The Eleventh Workshop on Ubiquitous Music
will be held on 6-8 September at CARA, Matosinhos, Portugal as a hybrid
(online and on-site) format.** Researchers working on ubiquitous music
topics are invited to submit proposals, initial results and complete
research projects. The workshop will adopt Portuguese, Spanish and English
as working languages.*

*++  Suggested topics (not exclusive):*

   - Ecologically grounded creative practice
   - Ubimus approaches to web and mobile audio
   - Everyday musical creativity
   - Ubimus improvisation and comprovisation
   - Ubiquitous, embedded and mobile computing in ubimus
   - The Internet of Musical Things (IoMusT), musical robotics and dew
   computing
   - Collaborative and dialogic music practices in educational settings
   - Lay-musician interaction
   - Sonification, musication and auditory display in Ubimus
   - Timbre interaction in ubimus contexts
   - Domestic ubimus
   - Computational creativity in ubimus endeavours


*++  Call for Papers*
Please submit your research as full papers or short papers
(work-in-progress), with a maximum of 12 and 4 pages, respectively,
including references and acknowledgements. Papers may be written in
English, Portuguese, or Spanish; should adhere strictly to the Ubimus
template and submitted as a PDF. All submissions will be thoroughly
peer-reviewed in a double-blind process. Accepted papers will be published
in the workshop proceedings and under consideration for special issues of
the Claves Journal and the Handbook of Ubiquitous Music.

*++  Call for Music*
Please submit artistic proposals to be presented in the workshop venue and
in the online programme. Works must feature a strong connection with the
workshop topics. Extended abstracts of no more than 2 pages detailing the
artistic submission should be written in either English, Portuguese or
Spanish and submitted as PDF in Easychair using the Ubimus templates.
Please clearly specify all requirements and setup time for the performance
on a detailed technical rider. There are no a priori restrictions to the
setup if the authors guarantee the necessary equipment (the venue will be
equipped with a stereo sound system). Sonic materials and artistic media
should be made available for download through a link to a cloud service.
The artistic submissions are not anonymous.

*++  Keynotes*
Elaine Chew, CNRS, IRCAM, King’s College London
Daniela Coimbra, ESMAE-IPP


best wishes,
Gilberto Bernardes
ubimus2...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups
"Ubiquitous Music" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ubiquitousmusic+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ubiquitousmusic/FE10E43C-0FC3-4CA6-9D0E-60238B0B2859%40inesctec.pt

.
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Fwd: [ubimus] Final call for contributions: Audio Mostly Conference, 1-3 September 2021

[Yann Orlarey]

-- Forwarded message -
De : Luca Turchet 
Date: jeu. 1 avr. 2021 à 13:04
Subject: [ubimus] Final call for contributions: Audio Mostly Conference,
1-3 September 2021
To:


*Audio Mostly - virtual conference*

*1-3 September 2021*

https://audiomostly.com/

*** Apologies for cross-posting, please distribute ***

Audio Mostly 2021 calls for Papers, Demos, Workshops, and Music
& Installations on the topic of *“Sonic experiences in the era of the
Internet of Sounds”*.

Audio Mostly is an audio-focused interdisciplinary conference on design,
technology, and interaction with sound that embraces applied theory and
practice-oriented research. Its annual gatherings bring together thinkers
and doers from academia and industry that share an interest in sonic
interaction
and the use of audio for interface design. This remit covers product design,
auditory display, computer games and virtual environments, new musical
instruments,
as well as education and workplace tools. It further includes fields such
as the
psychology of sound and music, cultural studies, system engineering, and
everything in between in which sonic interaction plays a role.

As in previous years, the conference is planned to be in-cooperation with
ACM/SIGCHI.
There will be a special issue of the Journal of Personal and Ubiquitous
Computing relating to the conference.
Authors are invited to significantly extend their accepted contributions
(at least 30% of new material)
to an article of the special issue on "Sonic Experiences: Interaction,
Connectivity, and Multi-Sensory Technologies".

The conference will be held in virtual form on 1-3 September 2021.

*# Important Dates*
Submission deadline: May 1, 2021
Notification of acceptance: June 15, 2021
Camera-ready submissions: July 15, 2021
Early registration deadline: July 1, 2021
Conference: September 1-3, 2021

*# Call for Papers*
Please submit your research as full papers (5-8 pages) or short papers
(4 pages). Both will be fully peer-reviewed in a double blind process.
Accepted papers are planned to be published in the ACM Digital Library.
https://audiomostly.com/2021/call/cfp/

*# Call for Demos*
We encourage authors to contribute demonstrations to be displayed at the
conference. Demos require a paper submission.
https://audiomostly.com/2021/call/cfd/

*# Call for Workshops*
We invite proposals for workshops to be held at AM'21. We encourage
hands-on/interactive workshops and regular workshops
that last from 2 hours to a full day. Workshops are proposed in the form of
a submitted paper.
https://audiomostly.com/2021/call/cfw/

*# Call for Music & Installations*
We invite submissions of short music pieces with a maximum length of 7
minutes and sound-based installations
around the conference theme *“Sonic experiences in the era of the Internet
of Sounds”*.
We especially encourage submissions of networked music performances and any
musical work dealing with local or remote networks.
https://audiomostly.com/2021/call/cfm/

*# Awards*
The Organizing Committee will assign the Best paper award, Best poster
award, Best student paper award,
Best music award, and Best demo/installation award.

*# Keynote speakers*
- Prof. Bob Sturm (KTH Royal Institute of Technology)
- Prof. Marianna Obrist (University College London)
- Prof. Paola Cesari (University of Verona)
*# Sponsors*
- ELK (www.elk.audio)
- Orastron (www.orastron.com)

*# Registration*
Virtual participation to AM'21 is free for everybody with the exception of
at least one of the presenting authors. For presenting authors the fee is
50 euro.
Thanks to the contribution of our sponsors, a number of fees (at least 4)
will be waived for first-authored contributions of master and PhD students
of economically developing countries or anybody in financial problems.
https://audiomostly.com/2021/info/registration/

For any question about the conference you can contact the organization by
sending an email to a...@unitn.it



-

Luca Turchet
Assistant Professor
Head of the Creative, Intelligent & Multisensory Interactions Laboratory

Department of Information Engineering and Computer Science
University of Trento
Via Sommarive 9 - 38123 Trento - Italy

E-mail: luca.turc...@unitn.it
Tel: +39 0461 283792

-- 
You received this message because you are subscribed to the Google Groups
"Ubiquitous Music" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ubiquitousmusic+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ubiquitousmusic/CAPj5b_GZU384ciw58A8NzjhoPbj9LGxEf77fMBhTMFmiJP7Ctg%40mail.gmail.com

.
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net

[Faudiostream-users] Julius FFT

[Yann Orlarey]

Hi,

During the workshop today I mentioned on the chat Julius FFT, a super
elegant piece of code that generates very impressive block-diagrams. Here
is the link:

https://faustide.grame.fr/?autorun=0=0=fft=aW1wb3J0KCJzdGRmYXVzdC5saWIiKTsKCnByb2Nlc3MgPSBhbi5mZnQoMTYpOw%3D%3D

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 <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

Re: [Faudiostream-users] Complex oscillators based on Lotka-Volterra equations

[Yann Orlarey]

Hi Dario,

Thanks for sharing, that's very interesting!

I take this opportunity to remind that URLs can be used directly in Faust
expressions.

For example:
process = component("
https://raw.githubusercontent.com/dariosanfilippo/lotka-volterra_osc_A/main/lotka-volterra_A.dsp
");


Using the share button is also possible to create a link that open directly
the faustide with the code:

https://faustide.grame.fr/?autorun=0=0=lotkavolterra_A=cHJvY2VzcyA9IGNvbXBvbmVudCgiaHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL2Rhcmlvc2FuZmlsaXBwby9sb3RrYS12b2x0ZXJyYV9vc2NfQS9tYWluL2xvdGthLXZvbHRlcnJhX0EuZHNwIik7

Cheers

Yann

Le dim. 31 janv. 2021 à 18:05, Dario Sanfilippo 
a écrit :

> Dear all,
>
> I've just pushed two repositories, they are two complex double oscillators
> based on two discrete models of the Lotka-Volterra equations.
>
> https://github.com/dariosanfilippo/lotka-volterra_osc_A
> https://github.com/dariosanfilippo/lotka-volterra_osc_B
>
> The main difference is that parameters can be explored in unstable regions
> as the equations are bounded through tanh() saturators (with adjustable
> saturating thresholds), and that DC-blockers are deployed within the loops
> to counterbalance tendencies towards fixed-point attractors.
>
> Despite the simplicity of the algorithms, I find the results surprisingly
> good.
>
> I am aware that there is no guard against division by zero in the
> oscillator B. However, considering that the tanh() function will prevent
> INF from being generated, aren't the odds of ending up with a NaN due to a
> 0/0 negligible?
>
> Please give it a try and let me know if you like them.
>
> Ciao.
>
> --
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
> ___
> 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

Re: [Faudiostream-users] WaveShaping using multiple functions

[Yann Orlarey]

Hi Yoann,

As James pointed out, Faust has strict semantics. This means that all
signals are always computed (https://en.wikipedia.org/wiki/Strict_function)
and that there is no non-strict 'if' in Faust.

It turns out that due to a bug in the compiler, the code generated for
select2 and select3 is not really strict! Moreover, our interval
calculation system, which is supposed to detect this kind of error, is
quite imperfect and doesn't do it.

The solution in these cases is to use min and max to force the arguments to
be in the right range of values. For example, to avoid division by 0, you
can write 1/max(epsilon, x).

Yann

Le mar. 24 nov. 2020 à 00:00, yoann.le.bor...@gmail.com <
yoann.le.bor...@gmail.com> a écrit :

> Hi Florian!
>
> Le 22/11/2020 à 13:03, Florian Hülsmann a écrit :
> > Hi Yoann,
> >
> > You can simply multiply the functions with their conditions:
> >
> > f(x) = (x < LowerThreshold) * LowerSignal(x) + ((x >= LowerThreshold)
> > & (x <= UpperThreshold)) * LinearSignal(x) + (x > UpperThreshold) *
> > UpperSignal(x)
> > process = f
> >
> > Hope this works for you!
> >
> > Flo
>
> Unfortunately, this does not work as whatever the signal is, there is
> always an attemp to compute log(0) which set the DSP out of order (at
> least in FaustIDE).
>
>
> Hi James!
>
> Le 22/11/2020 à 13:04, James Mckernon a écrit :
> > On 11/22/20,yoann.le.bor...@gmail.com  
> wrote:
> >> In a non functional language, I would have used a classic if/then/else
> >> but, as specified in the faust manual:
> >> "WARNING: since select2 is strict (always evaluating both branches), the
> >> resulting if does not have the usual "lazy" semantic of the C if form,
> >> and thus cannot be used to protect against forbidden computations like
> >> division-by-zero for instance."
> > I'm actually not sure this is correct; perhaps it's out of date?
> > select2 compiles to the ternary operator in C (?:), which I believe is
> > lazy in the sense of only evaluating the relevant branch.
> >
> > The only complication is that faust is 'eager' in evaluating
> > expressions at compile-time, where it can, which makes this tricky to
> > test. For this reason, select2 seems eager (i.e. it seems to eval both
> > branches) when you test it with constant expressions.
> >
> > process = select2(0, 1/0, 1); // divide by zero error at compile time
> > process = select2(1, 1/0, 1); // the same
> > process = select2(0, 1/_, 1); // NaN at runtime
> > process = select2(1, 1/_, 1); // fine; 1 at runtime
> >
> > The latter two evaluate a function on faust's input. When testing in
> > faust2plot, this is set to an impulse of 1 for the first sample and
> > zeroes thereafter. But doing it this way means that faust won't try to
> > precompute the value and get the divide by zero at compile-time.
> >
> > So I believe your waveshaping should just work. I say go ahead and try
> it.
> >
> > Hope that helps,
> > James
>
> I've tested with a select3 and got it working. While, as with Florian
> suggestion, log(0) seems to be computed it is handled transparently and
> for my personal curiosity I'll also try to use ba.selectoutn and look
> under the hood how both are implemented in C.
>
> Thanks a lot to both of you!
> Yoann
>
>
>
>
>
>
> ___
> 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

[Faudiostream-users] Programmable Audio Workshop (PAW) 2020

[Yann Orlarey]

PAW 2020, November 21, Online,

9:00 -- 17:00 Paris Time (UTC+1)



Programmable Audio Workshop (PAW) 2020:

A FULL day devoted to modular audio synthesis and programming!

   -

   Discover various interactive solutions for modular environments with Max
   Bruckert
   -

   Build a simple prototype Poly Synth with Making Sound Machines
   -

   Learn how to build and program the Gramophone with Romain Michon
   -

   Design Faust DSPs using a Web-based Graph Editor with Shihong Ren
   -

   Program you own VCV Rack modules using Faust with Stéphane Letz
   -

   Create embedded programs for the Daisy Patch Eurorack module with Andrew
   Ikenberry

The full program is available here: https://paw.grame.fr



Registration

PAW is completely free, but the number of participants is limited to 90
persons. Register as soon as possible at PAW 2020 REGISTRATION (
https://forms.gle/vQwB1bzQwkyzEFLB9)

You will receive all connexion instructions on Friday, November 20th.

Interested in PAW? Don’t forget also:

   -

   Nov 25-27, The Linux Audio Conference LAC 2020,
   https://lac2020.sciencesconf.org/
   -

   Dec 01-02, The International Faust Conference IFC 2020,
   https://ifc20.sciencesconf.org/


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 <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] (no subject)

[Yann Orlarey]

PAW 2020, November 21, Online,

9:00 -- 17:00 Paris Time (UTC+1)



Programmable Audio Workshop (PAW) 2020:

A FULL day devoted to modular audio synthesis and programming!

   -

   Discover various interactive solutions for modular environments with Max
   Bruckert
   -

   Build a simple prototype Poly Synth with Making Sound Machines
   -

   Learn how to build and program the Gramophone with Romain Michon
   -

   Design Faust DSPs using a Web-based Graph Editor with Shihong Ren
   -

   Program you own VCV Rack modules using Faust with Stéphane Letz
   -

   Create embedded programs for the Daisy Patch Eurorack module with Andrew
   Ikenberry

The full program is available here: https://paw.grame.fr



Registration

PAW is completely free, but the number of participants is limited to 90
persons. Register as soon as possible at PAW 2020 REGISTRATION (
https://forms.gle/vQwB1bzQwkyzEFLB9)

You will receive all connexion instructions on Friday, November 20th.

Interested in PAW? Don’t forget also:

   -

   Nov 25-27, The Linux Audio Conference LAC 2020,
   https://lac2020.sciencesconf.org/
   -

   Dec 01-02, The International Faust Conference IFC 2020,
   https://ifc20.sciencesconf.org/



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 <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

Re: [Faudiostream-users] Problem with FaustLive under MacOS Catalina

[Yann Orlarey]

Hi Alain,

The library is indeed missing (but when faust is also installed we don't
realize it). Here is the file 'platform.lib' to add in
.FaustLive-CurrentSession-2.0/Libs.
Cheers.

Yann

// platform.lib

// A library to handle platform specific code in Faust. Its official prefix
is `pl`.
//
// It can be reimplemented to globally change the SR and the tablesize
definitions


/

FAUST library file
Copyright (C) 2020 GRAME, Centre National de Creation Musicale
--
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation; either version 2.1 of the
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA.

EXCEPTION TO THE LGPL LICENSE : As a special exception, you may create a
larger FAUST program which directly or indirectly imports this library
file and still distribute the compiled code generated by the FAUST
compiler, or a modified version of this compiled code, under your own
copyright and license. This EXCEPTION TO THE LGPL LICENSE explicitly
grants you the right to freely choose the license for the resulting
compiled code. In particular the resulting compiled code has no obligation
to be LGPL or GPL. For example you are free to choose a commercial or
closed source license or any other license if you decide so.

/

declare name "Generic Platform Library";
declare version "0.1";

//-`(pl.)SR`---
// Current sampling rate (between 1Hz and 192000Hz). Constant during
// program execution.
//-
SR = min(192000.0, max(1.0, fconstant(int fSamplingFreq, )));

//-`(pl.)tablesize`
// Oscillator table size
//-
tablesize = 1 << 16;


Le mer. 14 oct. 2020 à 09:03, bonardi  a écrit :

> Dear List,
>
> We just resumed our courses of Faust at Paris 8 University.
> One of my students gets the following problem when running FaustLive
> 2.5.4. on MacOS Catalina 10.15.5.
> When running FaustLive, she gets an error message: *ERROR : unable to
> open file platform.lib*
>
> Thank you very much for your help.
>
> Best,
>
> Alain
> ___
> 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

Re: [Faudiostream-users] demand-rate in faust?

[Yann Orlarey]

Hi Till,

This is what the compiler does for pure generators like 1:+~_ or noise. It
inserts information about the clock into the code, so as to differentiate
between the internal states of ondemand(1:+~_) and 1:+~_. But for an
external function, we don't have access to its internal state. And this one
evolves at each call. So, it is up to the user to provide separate
versions. But of course, the compiler should at least be able to report the
problem...

Cheers

Yann


Le sam. 22 août 2020 à 17:35, Till Bovermann  a écrit :

> Hello,
>
>
> this looks awesome!
>
> regarding the below example by Oleg/Yann; wouldn't it make sense that, if
> such a case is detected, to split the computation intop two seprate paths,
> i.e.
>
>
> sig = x0, x1, x2, ... .
> clk = 1,0,1,0,1,0,1,0,
>
> (clk : ondemand(sig)) => (clk : ondemand(sig_demand_1)) -> x0, x0, x1, x1,
> x2, x2, ...
>  sig ->  x0, x1, x2, x3
>
>
> ?
>
> --
> Till Bovermann
>
> https://tai-studio.org | http://lfsaw.de |
> https://www.instagram.com/_lfsaw/
>
>
>
>
>
>
>
>
>
>
>
> > On 21. Aug 2020, at 22:31, Yann Orlarey  wrote:
> >
> > Hi Oleg,
> >
> > Thank you for your example. It is very interesting because it shows that
> it is now possible to write pathological Faust programs that cannot be
> executed (without infinite memory)!
> >
> > Sig, having no input, therefore represents a signal, for example: x0,
> x1, x2, ... . Similarly clk, say: 1,0,1,0,1,0,1,0,
> >
> > Therefore, to produce simultaneously:
> > (clk : ondemand(sig))-> x0, x0, x1, x1, x2, x2, ...
> >  sig -> x0, x1, x2, x3
> > we need to store an infinite amount of sig values!
> >
> > Clearly, the Faust compiler has to detect this kind of case and report
> an error...
> >
> > Cheers
> >
> > Yann
> >
> > Le ven. 21 août 2020 à 18:13, Oleg Nesterov  a écrit :
> > Hi Yann,
> >
> > On 08/21, Yann Orlarey wrote:
> > >
> > > A *very* experimental implementation of the ondemand primitive is
> available
> > > here :
> > >
> > > https://github.com/grame-cncm/faust/tree/experimental-ondemand
> > >
> > > The implementation is currently only available for -lang ocpp in scalar
> > > mode. Here are some simple examples :
> >
> > Am I understand correctly? Currently
> >
> > process = (clk : ondemand(sig));
> >
> > acts the same as
> >
> > process = control(sig,clk);
> >
> > right?
> >
> >
> ---
> > and it seems it has the same problem:
> >
> > clk = ffunction(int clk(), "","");
> > sig = ffunction(float sig(), "","");
> >
> > process = (clk : ondemand(sig));
> >
> > compiles to
> >
> > virtual void compute (int count, FAUSTFLOAT** input,
> FAUSTFLOAT** output) {
> > //zone1
> > //zone2
> > float   fTemp0 = fTempPerm0;
> > //zone2b
> > //zone3
> > FAUSTFLOAT* output0 = output[0];
> > //LoopGraphScalar
> > for (int i=0; i > if (clk()) {
> > fTemp0 = sig();
> > }
> > output0[i] = (FAUSTFLOAT)fTemp0;
> > }
> > fTempPerm0 = fTemp0;
> > }
> >
> > and this looks correct. However,
> >
> > process = (clk : ondemand(sig)), sig;
> >
> > results in
> >
> > virtual void compute (int count, FAUSTFLOAT** input,
> FAUSTFLOAT** output) {
> > //zone1
> > //zone2
> > //zone2b
> > //zone3
> > FAUSTFLOAT* output0 = output[0];
> > FAUSTFLOAT* output1 = output[1];
> > //LoopGraphScalar
> > for (int i=0; i > float   fTemp0 = sig();
> > output0[i] = (FAUSTFLOAT)fTemp0;
> > output1[i] = (FAUSTFLOAT)fTemp0;
> > }
> > }
> >
> > and this doesn't look right...
> >
> > Thanks!
> >
> > Oleg.
> >
> > ___
> > 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

Re: [Faudiostream-users] demand-rate in faust?

[Yann Orlarey]

Hi Oleg,

Thank you for your example. It is very interesting because it shows that it
is now possible to write pathological Faust programs that cannot be
executed (without infinite memory)!

Sig, having no input, therefore represents a signal, for example: x0, x1,
x2, ... . Similarly clk, say: 1,0,1,0,1,0,1,0,

Therefore, to produce simultaneously:

(clk : ondemand(sig))-> x0, x0, x1, x1, x2, x2, ...
 sig -> x0, x1, x2, x3

we need to store an infinite amount of sig values!

Clearly, the Faust compiler has to detect this kind of case and report an
error...

Cheers

Yann

Le ven. 21 août 2020 à 18:13, Oleg Nesterov  a écrit :

> Hi Yann,
>
> On 08/21, Yann Orlarey wrote:
> >
> > A *very* experimental implementation of the ondemand primitive is
> available
> > here :
> >
> > https://github.com/grame-cncm/faust/tree/experimental-ondemand
> >
> > The implementation is currently only available for -lang ocpp in scalar
> > mode. Here are some simple examples :
>
> Am I understand correctly? Currently
>
> process = (clk : ondemand(sig));
>
> acts the same as
>
> process = control(sig,clk);
>
> right?
>
>
> ---
> and it seems it has the same problem:
>
> clk = ffunction(int clk(), "","");
> sig = ffunction(float sig(), "","");
>
> process = (clk : ondemand(sig));
>
> compiles to
>
> virtual void compute (int count, FAUSTFLOAT** input, FAUSTFLOAT**
> output) {
> //zone1
> //zone2
> float   fTemp0 = fTempPerm0;
> //zone2b
> //zone3
> FAUSTFLOAT* output0 = output[0];
> //LoopGraphScalar
> for (int i=0; i if (clk()) {
> fTemp0 = sig();
> }
> output0[i] = (FAUSTFLOAT)fTemp0;
> }
> fTempPerm0 = fTemp0;
> }
>
> and this looks correct. However,
>
> process = (clk : ondemand(sig)), sig;
>
> results in
>
> virtual void compute (int count, FAUSTFLOAT** input, FAUSTFLOAT**
> output) {
> //zone1
> //zone2
> //zone2b
> //zone3
> FAUSTFLOAT* output0 = output[0];
> FAUSTFLOAT* output1 = output[1];
> //LoopGraphScalar
> for (int i=0; i float   fTemp0 = sig();
> output0[i] = (FAUSTFLOAT)fTemp0;
> output1[i] = (FAUSTFLOAT)fTemp0;
> }
> }
>
> and this doesn't look right...
>
> Thanks!
>
> Oleg.
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] demand-rate in faust?

[Yann Orlarey]

Hi,

A *very* experimental implementation of the ondemand primitive is available
here :

https://github.com/grame-cncm/faust/tree/experimental-ondemand

The implementation is currently only available for -lang ocpp in scalar
mode. Here are some simple examples :

Once the branch installed here are some command you can use to test:

faust2csvplot -lang ocpp test.dsp
faust -svg -lang ocpp test.dsp
./test -n 20


t01 = 1 : ondemand(1:+~_); // 1 2 3 4 5 ...

t02 = clock(2) : ondemand(1:+~_); // 1 1 2 2 3 3 ...

t03 = clock(2) : ondemand(t01); // 1 1 2 2 3 3 ...

t04 = clock(2) : ondemand(no.noise); // 5.74858859e-06 5.74858859e-06
-0.344845951 -0.344845951

t05 = no.noise, (clock(2) : ondemand(no.noise)); // same noise but at
different rates

t06 = no.noise, (clock(2), no.noise : ondemand(_)); // ondemand(_) is
Sample and Hold!

t07 = clock(2) : ondemand(t06); // cascading ondemands

Have a look at the generated block-diagram to see how P is transformed in
ondemand(P).

In a future version, the clock signal values could be higher than 1, for
upsampling. We should then have a fairly general multi-rate system...

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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le jeu. 13 août 2020 à 23:08, Yann Orlarey  a écrit :

> Hi James,
>
> Thanks for your suggestions. I need to read this more carefully, but can
> you elaborate on "The proposed ondemand helps somewhat with 1, and not at
> all with 2 or 3."?
>
> From my side, a more complete description of ondemand:
> https://drive.google.com/file/d/1LkT8KviWocnzt6hqRsLlSri5uwVDWI5p/view?usp=sharing
> with a new section on combining on-demands.
>
> 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 <https://www.facebook.com/Gramelyon/> | instagram
> <https://www.instagram.com/grame_cncm/> | twitter
> <https://twitter.com/GRAME_LYON>
>
>
> Le mer. 12 août 2020 à 14:20, James Mckernon  a
> écrit :
>
>> ondemand looks cool, Yann; thanks for writing that up.
>>
>> I guess it's worth breaking down what makes demand ugens in SC nice to
>> work with. I can think of three properties worth discussing:
>>
>> 1. As already discussed, they respond with a new value when their
>> trigger input is nonzero and reset their state when their trigger
>> input is nonzero.
>> 2. They embed child demand elements in their stream. (Actually, it's
>> been a long time since I worked with them, and I'm just going from
>> memory, so I'm not sure about this point. Perhaps Til can correct me
>> if I'm wrong.) That is, DSeq([DSeq([1, 2]), DSeq([3, 4])]) will yield
>> 1, 2, 3, 4 - i.e. all elements are requested from the first child DSeq
>> before requesting one from the second.
>> 3. They propagate values sent to their trigger/reset inputs. i.e.,
>> when triggered, a demand ugen will trigger its active child demand
>> ugen; when reset, it will reset all of its children.
>>
>> So 1 relates to how they behave in isolation, and 2/3 are about how
>> they behave when nested. (I'm not sure, but I don't think 3 is useful
>> without 2.) 2 and 3 are cool, but to get them working in faust seems
>> complex, maybe too complex (though I have been thinking of ways to
>> achieve it). Nonetheless, 1 is useful enough on its own that I believe
>> it would be worthwhile even without 2/3. The proposed ondemand helps
>> somewhat with 1, and not at all with 2 or 3.
>>
>> Although a general-purpose ondemand signal transformer (as in the
>> proposed primitive) would make things easier in some respects, it
>> seems to me (I wonder whether others will agree) that it is best to do
>> this with the simplest tools available. (I suppose I am thinking of
>> the 'rule of least power':
>> https://en.wikipedia.org/wiki/Rule_of_least_power .) In other words,
>> if it is possible to implement most of what one would want from a
>> demand-rate processor with existing language constructs, it is
>> probably better to do so than to implement a new language construct
>> for this case.
>>
>> I have been sketching out some code implementing a couple of
>> demand-rate ugens which I intend to post this weekend. (Not including
>> the embedding behaviour, i.e. 2/3 above.) The specifi

Re: [Faudiostream-users] demand-rate in faust?

[Yann Orlarey]

Hi James,

Thanks for your suggestions. I need to read this more carefully, but can
you elaborate on "The proposed ondemand helps somewhat with 1, and not at
all with 2 or 3."?

>From my side, a more complete description of ondemand:
https://drive.google.com/file/d/1LkT8KviWocnzt6hqRsLlSri5uwVDWI5p/view?usp=sharing
with a new section on combining on-demands.

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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le mer. 12 août 2020 à 14:20, James Mckernon  a écrit :

> ondemand looks cool, Yann; thanks for writing that up.
>
> I guess it's worth breaking down what makes demand ugens in SC nice to
> work with. I can think of three properties worth discussing:
>
> 1. As already discussed, they respond with a new value when their
> trigger input is nonzero and reset their state when their trigger
> input is nonzero.
> 2. They embed child demand elements in their stream. (Actually, it's
> been a long time since I worked with them, and I'm just going from
> memory, so I'm not sure about this point. Perhaps Til can correct me
> if I'm wrong.) That is, DSeq([DSeq([1, 2]), DSeq([3, 4])]) will yield
> 1, 2, 3, 4 - i.e. all elements are requested from the first child DSeq
> before requesting one from the second.
> 3. They propagate values sent to their trigger/reset inputs. i.e.,
> when triggered, a demand ugen will trigger its active child demand
> ugen; when reset, it will reset all of its children.
>
> So 1 relates to how they behave in isolation, and 2/3 are about how
> they behave when nested. (I'm not sure, but I don't think 3 is useful
> without 2.) 2 and 3 are cool, but to get them working in faust seems
> complex, maybe too complex (though I have been thinking of ways to
> achieve it). Nonetheless, 1 is useful enough on its own that I believe
> it would be worthwhile even without 2/3. The proposed ondemand helps
> somewhat with 1, and not at all with 2 or 3.
>
> Although a general-purpose ondemand signal transformer (as in the
> proposed primitive) would make things easier in some respects, it
> seems to me (I wonder whether others will agree) that it is best to do
> this with the simplest tools available. (I suppose I am thinking of
> the 'rule of least power':
> https://en.wikipedia.org/wiki/Rule_of_least_power .) In other words,
> if it is possible to implement most of what one would want from a
> demand-rate processor with existing language constructs, it is
> probably better to do so than to implement a new language construct
> for this case.
>
> I have been sketching out some code implementing a couple of
> demand-rate ugens which I intend to post this weekend. (Not including
> the embedding behaviour, i.e. 2/3 above.) The specific ugens from SC
> that seem to me most useful and practical to implement are DSeq,
> DSeries, DRand, DWhite, and DWRand. (Til, if you (or anyone else) have
> any suggestions for other particular demand-rate ugens from SC which
> would be good to have in faust then let me know.)
>
> I would be interested to hear anyone's thoughts on the above.
>
> Cheers,
> James
>
>
> On 8/7/20, Yann Orlarey  wrote:
> > Hi Till,
> >
> > Thank you very much for your detailed answer. It's very helpful. On my
> > side, I tried to formalize my ideas for an on-demand primitive. A
> > description is available here:
> >
> https://drive.google.com/file/d/1mEKkW3fKl9Ik8zsClxMzlMWKBjGl-teK/view?usp=sharing
> .
> > This is still very partial and many aspects remain to be detailed...
> >
> > 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 <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

Re: [Faudiostream-users] demand-rate in faust?

[Yann Orlarey]

Hi Till,

Thank you very much for your detailed answer. It's very helpful. On my
side, I tried to formalize my ideas for an on-demand primitive. A
description is available here:
https://drive.google.com/file/d/1mEKkW3fKl9Ik8zsClxMzlMWKBjGl-teK/view?usp=sharing.
This is still very partial and many aspects remain to be detailed...

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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le mer. 5 août 2020 à 14:06, Till Bovermann  a écrit :

> 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  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  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  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

Re: [Faudiostream-users] demand-rate in faust?

[Yann Orlarey]

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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le sam. 1 août 2020 à 18:29, Till Bovermann  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  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 <https://www.facebook.com/Gramelyon/> | instagram
> <https://www.instagram.com/grame_cncm/> | twitter
> <https://twitter.com/GRAME_LYON>
>
>
> Le jeu. 30 juil. 2020 à 13:17, James Mckernon  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  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 en

Re: [Faudiostream-users] demand-rate in faust?

[Yann Orlarey]

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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le jeu. 30 juil. 2020 à 13:17, James Mckernon  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  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  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

Re: [Faudiostream-users] demand-rate in faust?

[Yann Orlarey]

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  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>


Le sam. 25 juil. 2020 à 19:27, James Mckernon  a
écrit :

> Hi all,
>
> Just wanted to post some findings in relation to control, as discussed
> above.
>
> I tested today the latest version I could get hold of from the faust
> git repo (e11a0156a, looks like version 2.28), and I found that...
> control does indeed work in the way I described earlier in this
> thread! That is, it only evaluates its contents (in particular, their
> side effects) when its trigger is nonzero. I'm not sure if this is a
> change since that discussion, or if I just wasn't testing then on a
> recent enough version, or if I was hitting a bug (see below), but this
> did not appear to be the case when I tested it before.
>
> To demonstrate this behaviour, here is a a counter which we enable
> with control every second sample. It really is only evaluated when
> it's triggered, so the side effect (decrementing its internal
> variable) only happens then. As a result, each value is output for two
> samples, as desired:
>
> import("stdfaust.lib");
> process = control(-(1)~_, ba.time : %(2) : ==(0)); // -1, -1, -2, -2,
> -3, -3, ...
>
> But there is a bug here, I guess the same one that Oleg points out. I
> believe this is probably what confused me before:
>
> import("stdfaust.lib");
> process = control(+(1)~_, ba.time : %(2) : ==(0)); // 1, 2, 3, 4, ...
>
> In this case the counter is incremented every sample because the
> compiler detects +(1)~_ as a duplicate of the same expression inside
> ba.time, and optimises the process by letting them share the same
> calculation, even though one of them should always be calculated and
> the other should not. It seems that expressions inside a
> control/enable should not be eligible for this optimisation. I will
> probably file a bug report for this on github.
>
> I haven't yet really tested how this works with vectorisation and the
> various architectures. (Personally, I am most interested in using it
> with faust2faustvst and faust-live.)
>
> But Til, I believe this means you could use control to build something
> analogous to demand-rate structures in SC. Let me know if you would
> like a hand converting a simple example.
>
> Cheers,
> James
>
>
> ___
> 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

Re: [Faudiostream-users] arbitrary channels to recursive definition?

[Yann Orlarey]

Hi Oleg,

Here is an implementation of apply. It's the closest I've found ;-). The
idea is to pass to the op function a list of selectors that simulate the
formal parameters but that can be created in arbitrary numbers.

tsum((x, xs)) = sin(x)/cos(x) + tsum(xs);
tsum(x) = sin(x)/cos(x);

apply(N,op) = par(i,N,_) <: op(selectors(N))
with {
selectors(N) = par(i,N,selector(N,i));
selector(N,i) = route(N,1,i+1,1);
};

//process = \(x1,x2,x3,x4).(tsum((x1,x2,x3,x4)));
process = apply(4,tsum);


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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le sam. 18 juil. 2020 à 11:28, Oleg Nesterov  a écrit :

> Hi Yann,
>
> On 07/17, Yann Orlarey wrote:
> >
> > I'm not sure that answers your question,
>
> No it doesn't ;) probably I wasn't clear, please see below.
>
> > but you can do that, for instance:
>
> of course, you can always rewrite dsBus2int or anything else, but what
> if you do not want to change the "wants-the-list" function?
>
> Let me provide a stupid/artificial but simple example. Suppose you have
>
> tsum((x, xs)) = tan(x) + tsum(xs);
> tsum(x) = tan(x);
>
> Now,
> process = si.bus(4) : tsum;
>
> obviously won't work.
>
> process = tsum(si.bus(4));
>
> works, but only because "tsum" is simple enough. Lets complicate it:
>
> tsum((x, xs)) = sin(x)/cos(x) + tsum(xs);
> tsum(x) = sin(x)/cos(x);
>
> after this change
>
> process = tsum(si.bus(4));
>
> no longer works as expected, it has 4*2 inputs. You have to do
>
> process(x1,x2,x3,x4) = tsum((x1,x2,x3,x4));
> or
> process = \(x1,x2,x3,x4).(tsum((x1,x2,x3,x4)));
>
> but this is very inconvenient and doesn't allow to specify the number
> of inputs.
>
> The best solution I was able to find is something like this:
>
> apply(1, op) = \(x1).   (op((x1)));
> apply(2, op) = \(x1,x2).(op((x1,x2)));
> apply(3, op) = \(x1,x2,x3). (op((x1,x2,x3)));
> apply(4, op) = \(x1,x2,x3,x4).  (op((x1,x2,x3,x4)));
> apply(5, op) = \(x1,x2,x3,x4,x5).   (op((x1,x2,x3,x4,x5)));
> ...
> apply(32,op) = ...;
>
> this allows to do
>
> process = apply(N, tsum);
>
> as long as N is constant and <= 32. But this is not nice, and I do not
> know how can I define apply(n, op) for any "n".
>
> Oleg.
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] arbitrary channels to recursive definition?

[Yann Orlarey]

Hi Oleg,

I'm not sure that answers your question, but you can do that, for instance:

dsBus2int(1) = >(0);
dsBus2int(N) = dsBus2int(N-1) << 1, dsBus2int(1) :> _;

encode2int(P) = P : dsBus2int(outputs(P));

process = encode2int((1,0,1,0));

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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le ven. 17 juil. 2020 à 20:23, Oleg Nesterov  a écrit :

> Hi Yann,
>
> On 07/17, Yann Orlarey wrote:
> >
> > Hi Till,
> >
> > What about :
>
> but is there a generic solution?
>
> IOW. Suppose you have a wants_list() function and a constant N. How can you
> turn N inputs into the N-ary list and pass it to wants_a_list ?
>
> wants_list(sig.bus(N)) won't work.
>
> Oleg.
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] arbitrary channels to recursive definition?

[Yann Orlarey]

Hi Till,

What about :

dsBus2int(1) = _;
dsBus2int(N) = dsBus2int(N-1) << 1, dsBus2int(1) :> _;

Where N is the number of binary signals that you want to combine.

Or, if  you want to keep the comparison :

dsBus2int(1) = >(0);
dsBus2int(N) = dsBus2int(N-1) << 1, dsBus2int(1) :> _;

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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le jeu. 16 juil. 2020 à 18:27, Till Bovermann  a écrit :

> Hello,
>
> I'd like to write a custom "inject" function that works on parallel input
> streams and turns them into a 1-dim signal (a bit like `sum` or `prod` but
> with a custom concatenation function).
>
> As an example, I made "dsBus2int", which, assuming a parallel
> binary-stream (e.g. `(1, 0, 0, 1)`, assembles an integer via a left-shift
> operation.
>
> The current version assumes a fixed input dimensionality (6, in this case):
>
> ```
> import("stdfaust.lib");
> dsBus2int_6 = si.bus(6) : \(x0, x1, x2, x3, x4, x5).(left_shift((x0, x1,
> x2, x3, x4, x5))) with {
> left_shift((x, xs)) = left_shift(xs) & ((x > 0) << 1) ;
> left_shift(x) = x > 0;
> };
>
> process = (1, 0, 0, 1, 1, 1) : dsBus2int_6;
> ```
>
> Now I'd like to write a version that takes an N-dimensional stream (N <
> 32) with the interface
>
> ```
> process = insignal : dsBus2int(N) with {
> N = 12;
> insignal = si.nus(N); // or something else...
> };
> ```
>
> What I need to do, is to turn the parallel composed items of `si.bus(N)`
> into a list that can be processed by the `left_shift` recursive expression
> without the step of explicitly declaring the parameter-list `x0, x1, ...`
> in the lambda expression...
>
> anyone has an idea on how to do that?
>
> all the best and thanks in advance!
>
> Till
>
>
> --
> Till Bovermann
>
> https://tai-studio.org | http://lfsaw.de |
> https://www.instagram.com/_lfsaw/
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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

Re: [Faudiostream-users] Upcoming Faust Online Workshops

[Yann Orlarey]

Hi Francesco,

Welcome to the mailing list!

If we are very committed to open-source for Faust, nothing prevents using
Faust for closed-source software. I am thinking in particular of GeoShred
by Moforte, or Noisy a synthesizer by ExpressiveE. So if you have
Closed-Sources projects to present, they will be welcome too.

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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le lun. 1 juin 2020 à 01:23, francesco mulassano <
francesco.mulass...@gmail.com> a écrit :

> what characteristics must the projects have to be presented?
> Do they have to be open source, do they have to be ready or can they be
> prototypes?
>
> Thanks
> this is my first message!
> Francesco
>
> Il giorno lun 1 giu 2020 alle ore 01:17 Sam Pluta  ha
> scritto:
>
>> As a newer user, seeing some larger structured projects would be nice. I
>> am mostly using this language as a way to make plugins in SC. My brain is
>> wired to use oop structure in larger projects. Seeing some larger
>> functional projects would be really helpful for me.
>>
>> Sam
>>
>> On May 31, 2020 at 12:27:56 PM, Gary Worsham (gary.wors...@gmail.com)
>> wrote:
>>
>> Here are some thoughts.  I started by taking the Kadenze Faust online
>> course.  I've made VST plugins for Windows, jaqt for Linux, Android apps,
>> Bela and ESP32.  Still I feel like a beginner because the syntax is
>> occasionally baffling, especially if you are using recursion.
>>
>> a) I usually start with a block diagram of an algorithm in mind and then
>> struggle to represent it in Faust.  What I'd like to see is a step by step
>> strategy for decomposing an arbitrary block diagram into Faust, especially
>> with recursion and routing complications.
>>
>> b) There's sometimes a gigantic gap between the basic examples and some
>> of the more elaborate ones, e.g. JOS's recursion example immediately jumps
>> to some ridiculously complex FFT structure.  Way over my head.  Maybe
>> that's not a separate concern from point (a).
>>
>> c) When writing code for the ESP32 for example, figuring out how much
>> code would run without triggering watchdog timer errors is trial and
>> error.  I got pointed at some of the code profiling tools but I could not
>> figure out how to use them.  When targeting smaller embedded systems
>> there's going to be a limit on algorithm complexity and figuring out what
>> will or won't fit is frustrating.  For example, one ESP32 algo I worked
>> with would not allow even a single pole filter to be added but I could add
>> another flanger and LFO.  So, I'd like a bit of a session devoted to
>> showing how to use the profiling tools.
>>
>> Thanks,
>>
>> Gary W.
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
>>  Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
>> <#m_-4647718005420343869_m_-8713102643393980965_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Sun, May 31, 2020 at 7:09 AM Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> wrote:
>>
>>> Hello, Yann.
>>>
>>> On Fri, 29 May 2020 at 10:51, Yann Orlarey  wrote:
>>>
>>>> We plan to organize new Faust online workshops in the coming weeks.
>>>> Among the themes we have thought of, two of them involve contributions from
>>>> the community. And we'd love to hear what you think about them.
>>>>
>>>> 1/ Workshop Q
>>>> The idea would be to collect in advance questions and problems that you
>>>> may have about Faust and for which we will try to find answers. Then we
>>>> will organize a workshop where the most representative questions will be
>>>> presented as well as the answers we can give them.
>>>>
>>>
>>> This perhaps depends on the direction that Faust is taking for its
>>> future developments.
>>>
>>> Personally, I've found that Faust is an environment where aspects of
>>> algorithmic composition and audio engineering can coexist beautifully. I
>>> can also see that the interest of electronic musicians for Faust is growing
>>> a lot recently: I've already asked on the list and o

[Faudiostream-users] Upcoming Faust Online Workshops

[Yann Orlarey]

We plan to organize new Faust online workshops in the coming weeks. Among
the themes we have thought of, two of them involve contributions from the
community. And we'd love to hear what you think about them.

1/ Workshop Q
The idea would be to collect in advance questions and problems that you may
have about Faust and for which we will try to find answers. Then we will
organize a workshop where the most representative questions will be
presented as well as the answers we can give them.

2/ Workshop Faust based projects
There are now many projects that use Faust to varying degrees. The idea
would be to have the developers of these projects do a 10mn informal
presentation/demo of their project. We could imagine having a dozen or so
projects present

The two other workshops we have thought of are:

3/ a workshop dedicated to architecture files and how to design them.

4/ a workshop for the general public on writing VST plugins with Faust.

Tell us what you think. If the first two seem interesting to you, we'll
start collecting questions and projects very quickly.

Thanks

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 <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

Re: [Faudiostream-users] Pattern matching and lists in Faust

[Yann Orlarey]

Hi Oleg,

I agree with you, we should probably think more seriously about introducing
a real NIL in Faust!

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 <https://www.facebook.com/Gramelyon/> | instagram
<https://www.instagram.com/grame_cncm/> | twitter
<https://twitter.com/GRAME_LYON>


Le mar. 26 mai 2020 à 13:40, Oleg Nesterov  a écrit :

> On 05/25, Yann Orlarey wrote:
> >
> > For example the expression
> > `()` or `NIL` in Lisp, which indicates an empty list, does not exist in
> > Faust.
>
> Yes. it's a pity ;)
>
> Well, to some degree
>
> nil = 0:!;
>
> resembles the empty list. Say, output(nil) == 0 and
>
> process = sin(nil);
>
> works "as expected", same as
>
> process = sin;
>
>
> Yann, Stephane, I am curious if it is possible to change the compiler to
> make par(i, 0, expr) work?
>
> Some time ago I had to do something like
>
> mypar(0) = 0:!;
> mypar(n) = par(i, n, expr(i));
>
> and it was a bit annoying.
>
> Oleg.
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Pattern matching and lists in Faust

[Yann Orlarey]

Following the recent exchanges, I would like to bring some clarifications
on pattern matching and lists in Faust.

Strictly speaking, there are no lists in Faust. For example the expression
`()` or `NIL` in Lisp, which indicates an empty list, does not exist in
Faust. Similarly, the distinction in Lisp between the number `3` and the
list with only one element `(3)` does not exist in Faust.

However, list operations can be simulated (in part) using the parallel
binary composition operation `,` and pattern matching. The parallel
composition operation is right-associative. This means that the expression
`(1,2,3,4)` is just a simplified form of the fully parenthesized expression
`(1,(2,(3,4)))`. The same is true for `(1,2,(3,4))` which is also a
simplified form of the same fully parenthesized expression `(1,(2,(3,4)))`.

You can think of pattern-matching as always being done on fully
parenthesized expressions. Therefore no Faust function can ever distinguish
`(1,2,3,4)` from `(1,2,(3,4))`, because they represent the same fully
parenthesized expression `(1,(2,(3,4)))`.

This is why `ba.count( ((1,2), (3,4), (5,6)) )` is not 3 but 4, and also
why `ba.count( ( (1,2), ((3,4),5,6) ) )` is not 2 but 4.

# Explanation:

In both cases the fully parenthesized expression is
`((1,2),((3,4),(5,6)))`. The definition of ba.count being:

count( (x,y) ) = 1 + count(y);  // rule R1
count(   x   ) = 1; // rule R2

we have:

ba.count( ((1,2),((3,4),(5,6))) )
-R1->   1 + ba.count( ((3,4),(5,6)) )
-R1->   1 + 1 +  ba.count( (5,6) )
-R1->   1 + 1 + 1 + ba.count( 6 )
-R2->   1 + 1 + 1 + 1

Please note that pattern matching is not limited to parallel composition,
the other composition operators (<:  : :> ~) can be used too.

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 <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] PAW 2019

[Yann Orlarey]

*PAW 2019, December 14, Lyon*
With 9 talks and 7 workshops, PAW is an intensive day devoted to electronic
sounds and programmable audio technologies!

- discover innovative audio and music programming languages: Arrp, Faust,
SOUL, TidalCycles
- learn about exciting audio hardware platforms: Bela, but also FPGAs,
Teensy, ESP32
- write audio plugins for the web
- experiment and code ambisonics sound spatialization
- enjoy and practice live-coding music performance

The full program is available here: https://faust.grame.fr/PAW

PAW is completely free, but the number of seats is limited.
Register as soon as possible at https://forms.gle/f6pSMEwUg8mtH3Ko9


*Date*:  December 14, 2019, 8:30 - 18:00
*Location*: UCLy, Campus Saint-Paul, 10 Place des Archives, 69002 Lyon



*Yann Orlarey*
Directeur scientifique/Scientific director


orla...@grame.fr  T : +33 (0) 4 72 07 43 10
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] New `-fc ` option to control the generation of diagram blocks (was Re: Forcing faust2svg not to unfold function content)

[Yann Orlarey]

Hi,

The `-svg` option generates a graphical representation of the audio circuit
denoted by a Faust program.  This audio circuit can potentially be
extremely large, so there is a folding mechanism that divides the circuit
into parts when the size of the circuit exceeds a threshold. This threshold
can be controlled by using the `-f ` option.

The folding mechanism is performed on an evaluated audio circuit (flat). In
order to recreate a kind of structure and find folding points, the
evaluator keeps a record of the `DefNameProperty`, a string that represents
how certain expressions of the circuit were obtained during the evaluation
process. Only expressions with a DefNameProperty are candidates for
folding, provided they are of sufficient complexity. This second complexity
threshold has been hardcoded at 2. It can now be controlled using the new
`-fc ` option in Faust 2.18.0.

A block diagram with maximum folding can be obtained by combining the two
options `-f 0 -fc 0`. But it should be kept in mind that it is just a
representation of what a Faust program denotes, not a precise
representation of the Faust program itself that would require a completely
different representation system.

Cheers

Yann


-

Yann Orlarey
Directeur scientifique / Scientific Director

<http://www.grame.fr>


Le mar. 18 juin 2019 à 12:37, Dario Sanfilippo 
a écrit :

> Personally, I'd love that too.
>
> Currently, what is the condition that determines whether a function is
> expanded or not in the diagrams?
>
> Best,
> Dario
>
> On Tue, 18 Jun 2019 at 02:29, Julius Smith  wrote:
>
>> I think it would be great if there were NO function expansion when
>> drawing block diagrams.  Then we would have complete control by means
>> of naming expressions.  For convenience, there could be a source-code
>> pragma indicating to expand a particular function, or a Faust compiler
>> option such as -svgx functionName.
>>
>> - Julius
>>
>> On Sun, Jun 16, 2019 at 12:10 PM Dario Sanfilippo
>>  wrote:
>> >
>> > Hello, list.
>> >
>> > Say that I have the following code:
>> >
>> > system = +;
>> > process = system ~ _;
>> >
>> > Is there a way to force the generation of the SVG diagram to represent
>> "system" as a unit (the clickable blue box, so to speak) rather than having
>> the "+" on the diagram surrounded by the dashed square and the "system"
>> label?
>> >
>> > Thanks,
>> > Dario
>> > ___
>> > Faudiostream-users mailing list
>> > Faudiostream-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>>
>>
>> --
>>
>> Julius O. Smith III 
>> Professor of Music and, by courtesy, Electrical Engineering
>> CCRMA, Stanford University
>> http://ccrma.stanford.edu/~jos/
>>
> ___
> 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

Re: [Faudiostream-users] bonjour and a question about duplicating signals

[Yann Orlarey]

Hi Matt,

Welcome to Faust!

In your example you can use :

gate = button("../basshit-gate");



Cheers

Yann



-----

Yann Orlarey
Directeur scientifique / Scientific Director

<http://www.grame.fr>


Le mar. 11 juin 2019 à 19:56, interrupt  a
écrit :

> Bonjour, FAUST users!
> My name is Matt Howell, Nice to meet all of you. I have just started
> learning the language so I have a few questions.  I have a long experience
> as a programmer, artist, and sound design, so I'm excited to be using
> FAUST for a percussion synth that I am building on the Teensy3.6.
>
> I am currently trying to understand at least two things:
> 1. how to make a button trigger two envelopes
> 2. how to make the button show up in a higher level group, instead of
> twice in the two envelope ui groups
>
> source >>>
>
> import("stdfaust.lib");
>
> gate = button("basshit-gate");
>
> carrierAmpEnv(trig) = hgroup("[0]Carrier-Amp-Envelope",
>   en.dx7envelope(
> vslider("[0]amp-rate1",0,0,2,0.001): si.smoo,
> vslider("[2]amp-rate2",0.02,0,2,0.001): si.smoo,
> vslider("[4]amp-rate3",0.04,0,2,0.001): si.smoo,
> vslider("[6]amp-rate4",0.25,0,2,0.001): si.smoo,
> vslider("[1]amp-level1",1,0,1,0.01): si.smoo,
> vslider("[3]amp-level2",1,0,1,0.01): si.smoo,
> vslider("[5]amp-level3",0.5,0,1,0.01): si.smoo,
> vslider("[7]amp-level4",0,0,1,0.01): si.smoo,
> trig
>   )
> );
> modulationEnv(trig) = hgroup("[1]Modulation-Envelope",
>   en.dx7envelope(
> vslider("[0]mod-rate1",0.00,0,2,0.001): si.smoo,
> vslider("[2]mod-rate2",0.02,0,2,0.001): si.smoo,
> vslider("[4]mod-rate3",0.04,0,2,0.001): si.smoo,
> vslider("[6]mod-rate4",0.25,0,2,0.001): si.smoo,
> vslider("[1]mod-level1",1,0,1,0.01): si.smoo,
> vslider("[3]mod-level2",1,0,1,0.01): si.smoo,
> vslider("[5]mod-level3",0.5,0,1,0.01): si.smoo,
> vslider("[7]mod-level4",0,0,1,0.01): si.smoo,
> trig
>   )
> );
> modulatorFreq = hslider("modulator-freq", 110, 20, 15000, 10) : si.smoo;
> carrierFreq = hslider("carrier-freq", 90, 20, 15000, 10) : si.smoo;
> modIndex = hslider("modulator-index", 1, 0, 15000, 10) : si.smoo;
> modGain = hslider("modulator-gain", 0.5, 0, 1, 0.01) : si.smoo;
> carrierGain = hslider("carrier-gain", 0.5, 0, 1, 0.01) : si.smoo;
>
> dualOpFm(trig, carFreq, modFreq, ampEnv, modEnv) = (out)
> with {
>   modulator = os.osc(modulatorFreq);
>   carrier =  os.osc(carrierFreq + modulator * (modIndex *
> modulationEnv(trig)));
>   out = ((modulator * modGain) , (carrier * (carrierGain *
> carrierAmpEnv(trig;
> };
>
> process = dualOpFm(gate) <: _,_;
>
> <<< end source
>
> Any thoughts?
>
> Cheers,
> Matt
> ___
> 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

Re: [Faudiostream-users] Today Faust@ Chaos Computer Club Freiburg

[Yann Orlarey]

Nice! Do you know if the presentation will be streamed?

Yann

Le mer. 12 juin 2019 à 08:29, azvinz via Faudiostream-users <
faudiostream-users@lists.sourceforge.net> a écrit :

> Dear list,
>
> just to inform you, I will have a talk and a small workshop today at the
> Chaos Computer Club Freiburg, Germany.
>
> If you are around, come over!
>
> We are meeting at 7 p.m.
>
> https://cccfr.de/calendar/2019-06-12_faust_audio.html
>
> all the best
>
> vince
>
>
>
>
> ___
> 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

Re: [Faudiostream-users] Syntax in vgroup names

[Yann Orlarey]

Hi Jonatan,

You can do the following:

process = hgroup("proc", def);
def = vgroup("innerbox", hslider("../slider",0, 0, 1, 0.01));


instead of

process = hgroup("proc", def);
def = vgroup("innerbox", hslider("slider",0, 0, 1, 0.01));


or you can code full pathname directly:

process = hslider("h:proc/v:innerbox/slider",0, 0, 1, 0.01);

or mix the two approaches:

process = hgroup("proc", def);
def = vgroup("innerbox", hslider("../v:foobox/slider",0, 0, 1, 0.01));


(see https://faust.grame.fr/doc/manual/index.html#labels-as-pathnames)

Cheers

Yann


Le mar. 6 nov. 2018 à 21:50, Jonatan Midtgaard 
a écrit :

> Is it correct that the syntax for the names are different between hsliders
> and e.g. vgroups?
>
> Something like
>
> process = hgroup("proc", def)
> def = hslider("/slider",...)
>
> will compile to a HorizontalSlider in the outermost box. But with
>
> process = hgroup("proc", def)
> def = vgroup("innerbox", hslider("/slider",...))
>
> It compiles to a slider in the "innerbox" box.
> Is this the intended behaviour? And if it is, is there any way to 'escape'
> the innerbox such that the slider is defined in the outermost box?
> I ask because in our project, we have a large number of Faust files
> linking to the surrounding C++ program so changing the hierarchy in some
> other way is quite difficult.
>
>
> ___
> 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

Re: [Faudiostream-users] Status of control/enable primitives and the -es compiler option

[Yann Orlarey]

Hi Jonatan,

I am not sure to understand what the problem is?

import("stdfaust.lib");
process = control(os.osc(440), choice==0), control(os.osc(660), choice==1)
:> _;
choice  = button("choice");


In the above code, only one of the two branches will be computed and the
choice will be done at runtime. The semantics of `control` is
(approximatively) the following:

control(x,y) = x@D(y) with { D(y) = y==0 : +~_; };

Cheers

Yann


Le mer. 24 oct. 2018 à 16:56, Stéphane Letz  a écrit :

> A bit occupied these days, we’ll look at the issue not before next week.
>
> Stéphane
>
>
> > Le 24 oct. 2018 à 13:19, Jonatan Midtgaard 
> a écrit :
> >
> > Just bumping this thread in case no one saw it.
> >
> > Should it possible to be change the branch at runtime? Because that
> seems broken at the moment.
> >
> > - Jonatan
> >
> >> On 17 Oct 2018, at 12.26, Jonatan Midtgaard <
> jonatan.midtga...@gmail.com> wrote:
> >>
> >> Tested and it works!
> >>
> >> Follow-up question:
> >> Is it possible to change the 'branch' that is calculated at runtime?
> Doing this naively with an hslider or button
> >>
> >> var(0) = 5;
> >> var(1) = 9;
> >> choice = button("choice");
> >> process = control(var(0),choice==0), control(var(1),choice==1) :> _;
> >>
> >> Still fails when compiled with
> >> faust -scal -es 1 -lang ocpp
> >>
> >> - Jonatan
> >>
> >> Den lør. 13. okt. 2018 kl. 09.32 skrev :
> >> Fixed on GIT master-dev branch (compiler version 2.11.10)
> >>
> >> Stéphane
> >>
> >>
> >> > Le 12 oct. 2018 à 11:05, Jonatan Midtgaard <
> jonatan.midtga...@gmail.com> a écrit :
> >> >
> >> > Thanks for the quick response. Looking forward to hearing about the
> developments.
> >> >
> >> > - Jonatan
> >> >
> >> > fre. 12. okt. 2018 17.02 skrev Stéphane Letz :
> >> > >
> >> > > ASSERT : please report this message, the stack trace, and the
> failing DSP file to Faust developers (file: mterm.cpp, line: 511, version:
> 2.11.9, options: ocpp, -scal -ftz 0)
> >> >
> >> > The reported message is indeed correct ! This reveal an issue in the
> compiler, we are working on it.
> >> >
> >> > Thanks.
> >> >
> >> > Stéphane
> >>
> >
>
>
>
> ___
> 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

Re: [Faudiostream-users] kSamp delays: (x@n)@m = x@(n+m) is wrong

[Yann Orlarey]

Hi,

Two consecutive delay lines `@(n):@(m)` are now only merged if `n` is
constant.

Yann


Le lun. 8 oct. 2018 à 13:43, Yann Orlarey  a écrit :

> Hi Oleg,
>
> You are right, `@(n):@(m)` is equivalent to `@(n+m)` only if `n` is
> constant. We must test this condition before merging the delay lines.
> Thanks (again) for discovering the problem...
>
> Yann
>
>
> -----
>
> Yann Orlarey
> Directeur scientifique
> www.grame.fr
>
>
>
>
> Le dim. 7 oct. 2018 à 16:02, Oleg Nesterov  a écrit :
>
>> normalizeFixedDelayTerm() does
>>
>> if (isSigFixDelay(s, x, y)
>> return normalizeFixedDelayTerm(x, simplify(sigAdd(d, y)));
>>
>> but this is only correct if both d and y have computability() < kExec.
>>
>> IOW, the (x@n)@m = x@(n+m) comment is wrong otherwise, in general
>> (x@n)@m is equivalent to x@( n@m + m ), so I think that faust should
>> actually create another delay line for @m if n or m is not constant,
>>
>> OK, I'm afraid my explanation is confusing and not convincing, let me
>> provide a test-case.
>>
>> z1 = ro.cross(2) ~ _ : !,_;
>>
>> simply reimplements the mem() primitive but always creates xRec line.
>> Now,
>> any_signal <: mem : z1 :> -;
>>
>> should always output 0, no matter what "any_signal" actually does.
>> However,
>>
>> z1 = ro.cross(2) ~ _ : !,_;
>> delay = sin(no.noise) + 1 : *(10) : int;
>> process = ba.time : @(delay) <: mem, z1;
>>
>> doesn't output the same value in output0/output1, and this is not
>> actually right, I think.
>>
>> Not that I think this is really bad, this case is exotic and perhaps
>> can be ignored, but still.
>>
>> Oleg.
>>
>>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] kSamp delays: (x@n)@m = x@(n+m) is wrong

[Yann Orlarey]

Hi Oleg,

You are right, `@(n):@(m)` is equivalent to `@(n+m)` only if `n` is
constant. We must test this condition before merging the delay lines.
Thanks (again) for discovering the problem...

Yann


-

Yann Orlarey
Directeur scientifique
www.grame.fr




Le dim. 7 oct. 2018 à 16:02, Oleg Nesterov  a écrit :

> normalizeFixedDelayTerm() does
>
> if (isSigFixDelay(s, x, y)
> return normalizeFixedDelayTerm(x, simplify(sigAdd(d, y)));
>
> but this is only correct if both d and y have computability() < kExec.
>
> IOW, the (x@n)@m = x@(n+m) comment is wrong otherwise, in general
> (x@n)@m is equivalent to x@( n@m + m ), so I think that faust should
> actually create another delay line for @m if n or m is not constant,
>
> OK, I'm afraid my explanation is confusing and not convincing, let me
> provide a test-case.
>
> z1 = ro.cross(2) ~ _ : !,_;
>
> simply reimplements the mem() primitive but always creates xRec line.
> Now,
> any_signal <: mem : z1 :> -;
>
> should always output 0, no matter what "any_signal" actually does.
> However,
>
> z1 = ro.cross(2) ~ _ : !,_;
> delay = sin(no.noise) + 1 : *(10) : int;
> process = ba.time : @(delay) <: mem, z1;
>
> doesn't output the same value in output0/output1, and this is not
> actually right, I think.
>
> Not that I think this is really bad, this case is exotic and perhaps
> can be ignored, but still.
>
> Oleg.
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] soundfile length

[Yann Orlarey]

As an approximation, you could use a bargraph, between 0 and 100 for
example, and scale the value to display with the length of the file.
Yann


Le mar. 25 sept. 2018 à 23:31, azvinz via Faudiostream-users <
faudiostream-users@lists.sourceforge.net> a écrit :

> okay, it is like it is ;)
>
> thank you!
>
>
> On 09/25/2018 11:22 PM, Stéphane Letz wrote:
> > The error message "ERROR : the parameter must be a constant value known
> at compile time (the node of the tree is not a float nor an int) » is (this
> time ((-;) quite explicit. It has to be known at compilation time, but the
> sound length is discovered only when the program actually starts and the
> file is loaded... so at runtime.
> >
> > I don’t see an easy to do what you want for now.
> >
> > Stéphane
> >
> >
> >> Le 25 sept. 2018 à 23:08, azvinz  a écrit :
> >>
> >> import("stdfaust.lib");
> >>
> >>
> >> // this triggers bass sample on each (very slow) pulse
> >> process =  bass, progressbargui : attach;
> >>
> >> trigger = ba.beat(120/32)  : 1-_ ;
> >>
> >> playhead = (1:+~_*trigger: _*1);
> >>
> >>
> >> sound =
> soundfile("label[url:/media/sda7/Programming/Faust/Vinz4/bass.wav]",1) ;
> >> bass =  0, playhead : sound : !,!,_;
> >>
> >> progressbar = 0,0 : sound : _,!,!; // get only the length of soundfile
> in sample
> >>
> >> progressbargui = hbargraph("progress bar",0, progressbar); // put
> length of soundfile as max value. Put an int instead of "progressbar" and
> it should work
> >>
> >>
> >>
> >>
> >> On 09/25/2018 10:17 PM, Stéphane Letz wrote:
> >>> show me the code….
> >>>
>  Le 25 sept. 2018 à 22:14, azvinz via Faudiostream-users <
> faudiostream-users@lists.sourceforge.net> a écrit :
> 
>  Hello Stéphane,
> 
>  I tried to put the sample length of a soundfile object into the
> maximum value of a bargraph, but I get a compilation error. If there is a
> way to make it work? this would be great, so one can use bargraphs as
> progress bar for soundfiles.
> 
>  All the best
> 
>  Vince
> 
> 
> 
>  ___
>  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
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] mterm normalization bug, integer overflow

[Yann Orlarey]

Hi Oleg,

I find all these arguments convincing. I have also discussed this issue
with colleagues. We should not consider local non-causal computations (i.
e. @(-1)) to be incorrect.
We will modify the different steps to move in this direction:

type_inference : cast : normalization : intervals


Cheers

Yann


-

Yann Orlarey
Directeur scientifique
www.grame.fr




Le lun. 10 sept. 2018 à 09:53, Oleg Nesterov  a écrit :

> On 09/09, yann orlarey wrote:
> >
> > Hi Oleg,
> >
> > `process = @(2) : @(-1);` is incorrect because `@(-1)` is incorrect.
>
> '@(-1)' is incorrect per se, but '@(2) : @(-1)' used to work and imo it was
> useful. Say,
>
> tkeoN(n) = @(n) <: ^(2) - @(0+n)*@(0-n);
>
> > The
> > optimisations made by the compiler should not change the correctness of
> the
> > compiled program.
>
> Well, optimisations is very important part of faust ;)
>
> this code
>
> process = @(ba.time - ba.time);
>
> or this
>
> process = @(ba.time * 0);
>
> is correct. Now it can't be compiled too, by the same reason.
>
> Again, I do not pretend I understand faust internals, but it seems that we
> can simply remove the interval checks in infereSigType(); if interval is
> not
> valid or lo < 0 checkDelayInterval() should notice the problem later?
>
> > Therefore I think the current behavior of the compiler is
> > the right one.
>
> I can't argue, but to me this looks as unfortunate pessimization.
>
> Oleg.
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] mterm normalization bug, integer overflow

[yann orlarey]

Hi Oleg,

`process = @(2) : @(-1);` is incorrect because `@(-1)` is incorrect. The
optimisations made by the compiler should not change the correctness of the
compiled program. Therefore I think the current behavior of the compiler is
the right one.

Cheers

Yann

Le dim. 9 sept. 2018 à 18:30, Oleg Nesterov  a écrit :

> Hi Yann,
>
> On 09/08, Yann Orlarey wrote:
> >
> > Hi,
> >
> > In principle, the problem should be solved in version 2.8.6. We have now
> a
> > pass of explicit casting before any optimization.
>
> and before simplify() ... FYI, the commit
> 95666e5028134f1d28aaf5976d26e386efeeba28
> ("Fix optimisation bug by adding explicit int or float cast when needed
> ...")
> adds another regression, this code
>
> process = @(2) : @(-1);
>
> no longer compiles:
>
> ERROR : possible negative values of : -1
> used in delay expression : IN[0]@2@-1
> interval(-1, -1)
>
> because (iiuc) infereSigType() is called before simplification.
>
>
> > This should prevent the
> > inadvertent mixing of integer and floating expressions during the
> > optimization phase. But more tests are welcome...
>
> Yes, that problem looks fixed.
>
> Oleg.
>
>
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] mterm normalization bug, integer overflow

[Yann Orlarey]

Hi,

In principle, the problem should be solved in version 2.8.6. We have now a
pass of explicit casting before any optimization. This should prevent the
inadvertent mixing of integer and floating expressions during the
optimization phase. But more tests are welcome...

Cheers

Yann


-

Yann Orlarey
Directeur scientifique
www.grame.fr




Le sam. 25 août 2018 à 01:16, yann orlarey  a écrit :

> Hi,
>
> That's clearly a bug. Thanks Oleg for discovering the problem. I will have
> a look asap...
>
> Yann
>
> Le ven. 24 août 2018 à 16:30, Oleg Nesterov  a écrit :
>
>> On 08/24, Julius Smith wrote:
>> >
>> > I think this one may have been fixed. I cannot reproduce it in the
>> > latest git master-dev branch:
>>
>> I am on master-dev too,
>>
>> > faust -v
>> > FAUST : DSP to C, C++, Java, JavaScript, old C++, asm.js, WebAssembly
>> > (wast/wasm) compiler, Version 2.8.1
>>
>>
>> FAUST : DSP to C, C++, Java, JavaScript, old C++, asm.js, WebAssembly
>> (wast/wasm) compiler, Version 2.8.3
>> > noise = random / RANDMAX
>> > with{
>> > mask = 4294967295; // 2^32-1
>> > random = +(12345) ~ *(1103515245) & mask; // "linear congruential"
>> > RANDMAX = 2147483647.0; // = 2^31-1 = MAX_SIGNED_INT in 32 bits
>> > };
>>
>> $ cat /tmp/bug.dsp
>>
>> noise = random / RANDMAX
>> with{
>> mask = 4294967295; // 2^32-1
>> random = +(12345) ~ *(1103515245) & mask; // "linear congruential"
>> RANDMAX = 2147483647.0; // = 2^31-1 = MAX_SIGNED_INT in 32 bits
>> };
>>
>> process = noise <: *;
>>
>> $ faust -a plot.cpp /tmp/bug.dsp
>>
>> virtual void compute(int count, FAUSTFLOAT** inputs, FAUSTFLOAT**
>> outputs) {
>> FAUSTFLOAT* output0 = outputs[0];
>> for (int i = 0; (i < count); i = (i + 1)) {
>> iRec0[0] = ((1103515245 * iRec0[1]) + 12345);
>> output0[i] = FAUSTFLOAT((2.16840434e-19f *
>> float(mydsp_faustpower2_i(iRec0[0];
>> iRec0[1] = iRec0[0];
>>
>> }
>>
>> }
>>
>> mydsp_faustpower2_i(iRec0[0]) is wrong.
>>
>> $ /tmp/bug-plot
>>
>> 0.00
>> 0.00
>> 0.00
>> -0.00
>> -0.00
>> 0.00
>> -0.00
>> 0.00
>> -0.00
>> -0.00
>> -0.00
>> -0.00
>> 0.00
>> -0.00
>> 0.00
>> -0.00
>>
>>
>> > Maybe the ".0" at the end of RANDMAX is new?
>>
>> I don't think it should make any difference... just note the comment
>>
>> // special handling for division, we always want a float division
>>
>> in generateBinOp().
>>
>> Oleg.
>>
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> 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

Re: [Faudiostream-users] mterm normalization bug, integer overflow

[yann orlarey]

Hi,

That's clearly a bug. Thanks Oleg for discovering the problem. I will have
a look asap...

Yann

Le ven. 24 août 2018 à 16:30, Oleg Nesterov  a écrit :

> On 08/24, Julius Smith wrote:
> >
> > I think this one may have been fixed. I cannot reproduce it in the
> > latest git master-dev branch:
>
> I am on master-dev too,
>
> > faust -v
> > FAUST : DSP to C, C++, Java, JavaScript, old C++, asm.js, WebAssembly
> > (wast/wasm) compiler, Version 2.8.1
>
>
> FAUST : DSP to C, C++, Java, JavaScript, old C++, asm.js, WebAssembly
> (wast/wasm) compiler, Version 2.8.3
> > noise = random / RANDMAX
> > with{
> > mask = 4294967295; // 2^32-1
> > random = +(12345) ~ *(1103515245) & mask; // "linear congruential"
> > RANDMAX = 2147483647.0; // = 2^31-1 = MAX_SIGNED_INT in 32 bits
> > };
>
> $ cat /tmp/bug.dsp
>
> noise = random / RANDMAX
> with{
> mask = 4294967295; // 2^32-1
> random = +(12345) ~ *(1103515245) & mask; // "linear congruential"
> RANDMAX = 2147483647.0; // = 2^31-1 = MAX_SIGNED_INT in 32 bits
> };
>
> process = noise <: *;
>
> $ faust -a plot.cpp /tmp/bug.dsp
>
> virtual void compute(int count, FAUSTFLOAT** inputs, FAUSTFLOAT**
> outputs) {
> FAUSTFLOAT* output0 = outputs[0];
> for (int i = 0; (i < count); i = (i + 1)) {
> iRec0[0] = ((1103515245 * iRec0[1]) + 12345);
> output0[i] = FAUSTFLOAT((2.16840434e-19f *
> float(mydsp_faustpower2_i(iRec0[0];
> iRec0[1] = iRec0[0];
>
> }
>
> }
>
> mydsp_faustpower2_i(iRec0[0]) is wrong.
>
> $ /tmp/bug-plot
>
> 0.00
> 0.00
> 0.00
> -0.00
> -0.00
> 0.00
> -0.00
> 0.00
> -0.00
> -0.00
> -0.00
> -0.00
> 0.00
> -0.00
> 0.00
> -0.00
>
>
> > Maybe the ".0" at the end of RANDMAX is new?
>
> I don't think it should make any difference... just note the comment
>
> // special handling for division, we always want a float division
>
> in generateBinOp().
>
> Oleg.
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Faust Awards 2018 (Deadline extended to Jun 7, 2018)

[Yann Orlarey]

Hello,

If you were in a hurry to complete your project, the submission deadline
has been extended to June 7, 2018.

We look forward to receiving your submissions!


Yann Orlarey






2018-02-18 22:52 GMT+01:00 Yann Orlarey :

> [Sorry for cross-posting, please distribute.]
>
> Faust Open Source Software Competition
> ===
>  (Submission Deadline: June 1, 2018)
>
> Overview
> -
> The Faust Open-Source Software Competition is intended to promote
> innovative high-quality free audio software developed with the Faust
> programming language, as well as development tools built around the Faust
> compiler itself. The Faust Open-Source Software award will be attributed to
> the best submission by an international committee of leading experts in the
> field. The competition is sponsored by Grame, centre national de création
> musicale. The winning software will receive a 2000€ price to encourage its
> authors. The results will be announced July 17, 2018 during the
> International Faust Conference [IFC18](http://www.ifc18.uni-mainz.de/) in
> Mainz.
>
> To participate, the software must be provided with source code and
> licensed with a Free/Open Source license. A substantial part of the
> software must be written in Faust and the Faust source code must be
> provided. As part of the review process, the software will be built from
> the sources. All source code, license, video demonstration, installation
> instructions, and any other documentation must be available on a public web
> page. License compatibility with other open source software is encouraged.
> Dependencies on non-open source third-party software are discouraged, with
> the exception of operating systems and freely available commercial packages.
>
> Authors are required to prepare a video demonstrating the software. This
> video must be done carefully, and should convincingly present the qualities
> of the software. The submission must also contain any useful documentation,
> including examples of how the provided software might be used, existing
> prototypes that use the software, download statistics or other public usage
> information. The criteria for judging submissions includes broad
> applicability and potential impact, novelty, technical depth, reusability,
> etc.
>
> Junior Competition
> --
> In parallel to the Faust Open-Source Software Competition, we have a
> junior competition, the Faust Student Software Competition, with a 200€
> prize for the winner. The Faust Student Software Competition is intended to
> promote interesting audio processing and synthesis applications written in
> Faust in a single file in less than 1000 words. The word count is done
> after removing the comments from the code:
>
> cat foo.dsp | stripcmt | wc -w.
>
> The use of the standard Faust libraries is strongly encouraged. They don't
> take part in the word count.
>
> Important dates
> ---
> - Start of the competition: February 18, 2018
> - Software Submission Deadline: June 1, 2018
> - Results of the competition: July 17, 2018
>
> Submission Guidelines
> -
> Authors interested in participating in the Faust Open Source Software
> Competition or the Faust Student Software Competition should send a
> submission email to  with a PDF file attached
> containing the following information:
>
> - Title of submission,
> - Category of submission (*Faust Open Source Software Competition* or
> *Faust Student Software Competition*),
> - Name, email and affiliation of the main author,
> - Names, emails and affiliations of other authors,
> - A permanent link for the open source software (e.g., Sourceforge,
> GitHub, Google Code, etc.),
> - A permanent link for the video demonstration (e.g., YouTube, Vimeo,
> etc.),
> - A link to a compressed archive file that contains the software (source
> code, documentation, build/install instructions, and licenses).
> Comprehensive and clear build/install instructions will be a crucial
> component of any submission. The committee will make a reasonable effort to
> build the software for the top contributions, but if they are unable to
> make the software run, it will be excluded from the competition.
>
> International Committee
> ---
> - Jean-Louis Giavitto (IRCAM, Paris, France),
> - Albert Gräf (Johannes Gutenberg U., Mainz, Germany),
> - Pierre Jouvelot (Ecole des Mines, Paris, France),
> - Victor Lazzarini (Maynooth U., Maynooth, Ireland),
> - Romain Michon (CCRMA, Stanford , USA)
> - Yann Orlarey (Grame, Lyon, France),
> - Laurent Pottier (U. Jean Monnet, Saint Etienne, France),
> - Julius Smith (CCRMA, Stanford , USA)
>
> Previous Winners
> 

Re: [Faudiostream-users] Help Compiling Max External

[Yann Orlarey]

Hi Patrick,

windows -> max-msp-64b generates plugins for windows 32 bits. Here the 64b
suffix indicates that the samples are in 64 bits double format (Max6).

I added an experimental windows64 -> max-msp target based on the script
faust2w64max6. This script is supposed to cross-compile Windows 64 bits
code for Max6. But it was never really tested, and from your tests, I
understand that it is not working correctly. Do you have more details?

Yann



-

Yann Orlarey
Directeur scientifique
www.grame.fr



2018-04-09 1:58 GMT+02:00 Patrik Lechner <ptrk.lech...@gmail.com>:

> Hi everyone,
>
> I fail to compile useable a Max/MSP external using the online compiler.
> I was just about to file an issue report but I guuessed I might be
> overlooking something. Is anyone of you able to help me out?
>
> I use the preloaded example on the online compiler (process = +;), I
> compile using both of these: - windows -> max-msp-64b
> - windows64 -> max-msp
>
> Both produce binaries but max always says 'no such object'.
> I do know how to add stuff to Max's search path.
>
> I tried this a couple of months ago already and it wasn't working. No I
> thought I'd give it a try again but still, no luck.
>
> Using Max 7.3.4 64 bit
> Windows 10 Pro 64 bit
>
>
> Thanks for any advice,
> all the best
>
>
>
> --
> ---[ə]
> --Patrik Lechner--
> ptrk.lech...@gmail.com
> http://patriklechner.tumblr.com/
>  Kendlerstrasse 12 a-1140 Wien +43(0)660
> 214 08 93
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Implementing high order FIRs

[Yann Orlarey]

We can overload functions provided that the argument's signatures are
different. Otherwise, the generated C++ code won't compile:

error: functions that differ only in their return type cannot be overloaded

But obviously, we should report an error ("foreign functions that differ
only in their return type cannot be overloaded" ?) instead of triggering an
exception when that's not the case.

-----

Yann Orlarey
Directeur scientifique
www.grame.fr



2018-03-26 11:16 GMT-07:00 Stéphane Letz <l...@grame.fr>:

>
> > Le 26 mars 2018 à 14:48, Oleg Nesterov <o...@redhat.com> a écrit :
> >
> > On 03/24, Yann Orlarey wrote:
> >>
> >> Hi,
> >>
> >> The problem has been fixed in version 2.5.26. The compiler now reports
> >> an error instead of an exception.
> >
> > and the fix is much better than I tried to suggest, thanks.
> >
> > OK, let me report another minor/trivial problem. Again, I'm not sure I
> understand
> > this code correctly, but I think that InstructionsCompiler::generateFFun()
> should
> > check 'fun_type' before it calls genDeclareFunInst(). This code
> >
> >   process = ffunction(int   func(), "",""),
> > ffunction(float func(), "","");
> >
> > obviously crashes faust (triggers assert in DeclareFunInst::
> DeclareFunInst()).
> >
> > OTOH, faust happily translates this code
> >
> >   process = ffunction(int func(),  "",""),
> > ffunction(int func(float), "","");
> >
> > into
> >
> >   output0[i] = FAUSTFLOAT(int(func()));
> >   output1[i] = FAUSTFLOAT(int(func(float(float(input0[i]);
> >
> > probably because nerateFFun() generates the new args_types/args_value
> every time
> > without any check. This is not that bad, but perhaps not right anyway.
> >
> > Oleg.
>
>
> The DeclareFunInst causes this assert if functions with the same name but
> different prototypes are used. This is probably not correct !?
>
> Yann are we supposed to be able to use several « foreign functions with
> the same name but different prototypes » ? Or at least coming from
> different header files? If not then I guess this could/should be checked
> before the FIR generation step and the use of DeclareFunInst.
>
> Stéphane
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Implementing high order FIRs

[Yann Orlarey]

Hi,

The problem has been fixed in version 2.5.26. The compiler now reports
an error instead of an exception.

Yann

-

Yann Orlarey
Directeur scientifique
www.grame.fr



2018-03-21 8:16 GMT-07:00 Yann Orlarey <orla...@grame.fr>:

> Hi Oleg,
>
> Thanks for pointing these problems. Obviously, the compiler should report
> errors, not crash!
>
> Interestingly:
>
> process = 0,0,0 : +;
>
> crashes, while:
>
> process = _,0,0 : +;
>
> correctly reports a sequential composition error.
>
> We will have look...
>
> Cheers
>
> Yann
>
>
> -
>
> Yann Orlarey
> Directeur scientifique
> www.grame.fr
>
>
>
> 2018-03-21 5:04 GMT-07:00 Oleg Nesterov <o...@redhat.com>:
>
>> On 03/21, Oleg Nesterov wrote:
>> >
>> > Ah, no, sorry, this is faustassert(lsig.size()==2) in realPropagate(),
>> >
>> >339  else if (isBoxPrim2(box, ))  {
>> >340  //  printf("prim2 recoit : "); print(lsig); printf("\n");
>> >341  faustassert(lsig.size()==2);
>>
>> and thus it is clear that
>>
>> process = (0,0) + 0;
>>
>> should crash the faust too; it does.
>>
>> Oleg.
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Implementing high order FIRs

[Yann Orlarey]

Hi Oleg,

Thanks for pointing these problems. Obviously, the compiler should report
errors, not crash!

Interestingly:

process = 0,0,0 : +;

crashes, while:

process = _,0,0 : +;

correctly reports a sequential composition error.

We will have look...

Cheers

Yann


-

Yann Orlarey
Directeur scientifique
www.grame.fr



2018-03-21 5:04 GMT-07:00 Oleg Nesterov <o...@redhat.com>:

> On 03/21, Oleg Nesterov wrote:
> >
> > Ah, no, sorry, this is faustassert(lsig.size()==2) in realPropagate(),
> >
> >339  else if (isBoxPrim2(box, ))  {
> >340  //  printf("prim2 recoit : "); print(lsig); printf("\n");
> >341  faustassert(lsig.size()==2);
>
> and thus it is clear that
>
> process = (0,0) + 0;
>
> should crash the faust too; it does.
>
> Oleg.
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Implementing high order FIRs

[Yann Orlarey]

Right. Internally the faust compiler uses doubles anyway and these doubles
are parsed using a very standard atof function.  It would be useful if you
could send me a sample code because it's really weird.

Yann

-

Yann Orlarey
Directeur scientifique
www.grame.fr



2018-03-20 17:29 GMT-07:00 Julius Smith <j...@ccrma.stanford.edu>:

> I would not expect that big of a difference in the amount of time to
> process 64-bit versus 32-bit input data.  Something else may be afoot
> here. - Julius
>
> On Tue, Mar 20, 2018 at 3:42 PM, CrocoDuck o'Ducks
> <crocoduck.odu...@gmail.com> wrote:
> > Hi guys,
> >
> > I think I probably found what was wrong.
> >
> > So, I used the -t 0 option and it worked, but it took a really huge time
> to
> > compile (almost a hour I think).
> >
> > I did some tests and I don't see any problem with fi.fir(), it supports
> very
> > large lists.
> >
> >
> > The fact that your times are as so much smaller than mine made me think.
> I
> > upgraded to 2.5.23 (that's the latest on Arch repos), but same issue. I
> was
> > about to try to build the last version but then I realised that my Julia
> > code was dumping Float64 literals into the Faust source code. However, I
> got
> > the impression that Faust wants C++ float literals, which should be kinda
> > equivalent to Julia's Float32, while C++ double should be sort of like
> > Julia's Float64. What suggested that to me is that I could see the
> numbers
> > notated with f in few (not related) compiler errors.
> >
> > So, I modified my Julia code to convert the FIR taps to Float32 before
> > writing them down in the .dsp files. Now it compiles quite fast, a bunch
> of
> > seconds.
> >
> > So, I guess that I was dropping numbers with too high precision into the
> > Faust source code, and then the compiler was spending a ton of time to
> > convert them. Is it plausible?
> >
> >
> > On Tue, 20 Mar, 2018 at 7:28 PM, Julius Smith <j...@ccrma.stanford.edu>
> > wrote:
> >
> > I think [complexity] info should be added in the library documentation.
> >
> > +1 - Julius On Tue, Mar 20, 2018 at 5:26 AM, Stéphane Letz <
> l...@grame.fr>
> > wrote:
> >
> > ba.take ==> complexity O(n^2) I think that this kind of info should be
> added
> > in the library documentation. And also as a general rule in the «
> > Contributing » section of
> > https://github.com/grame-cncm/faustlibraries/blob/master/README.md, to
> push
> > library writers to document this kind of things. Stéphane
> >
> > Le 20 mars 2018 à 04:32, Yann Orlarey <orla...@grame.fr> a écrit : HI,
> I did
> > some tests and I don't see any problem with fi.fir(), it supports very
> large
> > lists. Here is the test file I used: // --- fir500.dsp --
> > import("stdfaust.lib"); process = fi.fir(( 1,2,3,4,5,6,7,8,9,10, ...48
> > copies... 1,2,3,4,5,6,7,8,9,10)); //-
> time
> > faust fir500.dsp -o /dev/null real 0m0.446s user 0m0.375s sys 0m0.030s If
> > instead, I use the second code you mentioned // --- fur500.dsp --
> > import("stdfaust.lib"); fur(coeffs) = _ <: par(i, 500, @(i) * ba.take(i
> + 1,
> > coeffs)) :> _; process = fur(( 1,2,3,4,5,6,7,8,9,10, ...48 copies...
> > 1,2,3,4,5,6,7,8,9,10)); //- The
> compilation
> > will take a very long time because ba.take() is really not the way to go
> in
> > this case (complexity O(n^2)). Here are the results I get: time faust
> > fur500.dsp -o /dev/null real 1m18.270s user 1m16.947s sys 0m0.900s The
> > difference is enormous (x170)! If in your case you don't see any
> difference
> > of performances between the two, then there is a problem with the fi.fir
> > implementation you are using. Can you try with the latest version of
> Faust
> > (version 2.5.25)? Cheers Yann 2018-03-19 15:01 GMT-07:00 Oliver Larkin
> via
> > Faudiostream-users <faudiostream-users@lists.sourceforge.net>:
> depending on
> > what faust version you are using, a foreign function might help. I had
> to do
> > this to do a convolution in my tambura synthesiser for exactly the same
> > reason https://github.com/olilarkin/Tambura/blob/master/bridgeIR.dsp
> > https://github.com/olilarkin/Tambura/blob/master/bridgeIR.h it would be
> > great if faust’s FIR didn’t bork like this oli
> >
> > On 19 Mar 2018, at 21:32, CrocoDuck o'Ducks <crocoduck.odu...@gmail.com>
> > wrote: Hi again! Thank you for all your tips!
> >
&g

Re: [Faudiostream-users] Implementing high order FIRs

[Yann Orlarey]

HI,

I did some tests and I don't see any problem with fi.fir(), it supports
very large lists. Here is the test file I used:

// --- fir500.dsp --

import("stdfaust.lib");

process = fi.fir((
1,2,3,4,5,6,7,8,9,10,
...48 copies...
1,2,3,4,5,6,7,8,9,10));

//-

time faust fir500.dsp -o /dev/null


real 0m0.446s

user 0m0.375s

sys 0m0.030s


If instead, I use the second code you mentioned

// --- fur500.dsp --

import("stdfaust.lib");

fur(coeffs) = _ <: par(i, 500, @(i) * ba.take(i + 1, coeffs)) :> _;

process = fur((
1,2,3,4,5,6,7,8,9,10,
...48 copies...
1,2,3,4,5,6,7,8,9,10));

//-

The compilation will take a very long time because ba.take() is really not
the way to go in this case (complexity O(n^2)). Here are the results I get:


time faust fur500.dsp -o /dev/null


real 1m18.270s

user 1m16.947s

sys 0m0.900s

The difference is enormous (x170)!

If in your case you don't see any difference of performances between the
two, then there is a problem with the fi.fir implementation you are using.

Can you try with the latest version of Faust (version 2.5.25)?

Cheers

Yann





2018-03-19 15:01 GMT-07:00 Oliver Larkin via Faudiostream-users <
faudiostream-users@lists.sourceforge.net>:

> depending on what faust version you are using, a foreign function might
> help. I had to do this to do a convolution in my tambura synthesiser for
> exactly the same reason
>
> https://github.com/olilarkin/Tambura/blob/master/bridgeIR.dsp
>
> https://github.com/olilarkin/Tambura/blob/master/bridgeIR.h
>
>
> it would be great if faust’s FIR didn’t bork like this
>
> oli
>
>
> On 19 Mar 2018, at 21:32, CrocoDuck o'Ducks 
> wrote:
>
> Hi again!
>
> Thank you for all your tips!
>
> I suggest placing all of your coefficients into a large parallel signal
> bank:
>
> coeffs = (b0, b1, b2, ..., b511); // FIR filter coefficients for length 512
>
> and then use par() etc.
>
>
> I tried both of these:
>
> process = fi.fir(coeffs);
>
> process = _ <: par(i, 512, @(i) * ba.take(i + 1, coeffs)) :> _;
>
> Which, unfortunately, both suffer from the same problem. Did I got the
> suggestion right?
>
> You can set unlimited time by adding
> -t 0
> to your compile command.
>
>
> I am currently trying this.
>
> Interesting ! Do you have some code to show? Is is part of an official
> JULIA ==> Faust project?
>
>
> No, it isn't an official project. I just design some filters using DSP.jl
> then I try to generate Faust code that implements them. I just open a file
> for writing and I fill it with Faust code. I guess I can cook a few minimal
> examples to share, I cannot share my code right away as it is sort of
> confidential.
>
> On Mon, 19 Mar, 2018 at 8:20 AM, Stéphane Letz  wrote:
>
> Le 18 mars 2018 à 23:06, CrocoDuck o'Ducks  a
> écrit : Hi there! I currently have some Julia code producing 512 taps for
> an FIR filter.
>
> Interesting ! Do you have some code to show? Is is part of an official
> JULIA ==> Faust project? Stéphane
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot__
> _
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Faudiostream-users Digest, Vol 87, Issue 12

[Yann Orlarey]

Right, everything seems to be fine now :-). The problem was due to a data
center migration: https://sourceforge.net/blog/datacenter-migration-update/

-

Yann Orlarey
Directeur scientifique
www.grame.fr



2018-02-19 19:02 GMT-08:00 Mykle Hansen <my...@mykle.com>:

>
> > On Feb 19, 2018, at 5:06 PM, faudiostream-users-request@
> lists.sourceforge.net wrote:
> >
> > Hi everybody,
> >
> > We seem to have had some "delay" problems with this mailing list.
> Because of these delays, we all felt like no one was answering Mykle's
> question and so we all answered; -)
> >
> > Yann
> >
> > PS: Let's see how long it takes for this message to reach the ML. It is
> now 5:02 p. m. Pacific time.
>
> I am super-appreciative of all your answers, even if they’re all the same.
> (In fact, that’s way better than if the answers were all different!  =)
>
> FWIW I got this four minutes later at 5:06PST — and that was the digest
> version.
>
> Thanks,
> -m-
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] organization of UI elements in Faust ..

[Yann Orlarey]

Hi Mykle,

You can start labels with a metadata number "[1]myslider..." to change the
lexicographical order.
Cheers

Yann

-----

Yann Orlarey
Directeur scientifique
www.grame.fr



2018-02-16 11:48 GMT-08:00 Mykle Hansen <my...@mykle.com>:

> Hi,
>
> A quick question I can’t find in the docs: when several
> UI elements (like vslider(), for instance) exist in the
> same level of the Faust UI hierarchy, they seem to be
> ordered by alphabetizing their labels.  Is there any
> metadata I can add to change that ordering?
>
> (Trying to clean up the UI of my filter, which includes
> some blank-labeled hgroups/vgroups I want to sort.)
>
> Thanks,
> -mykle-
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] link to a program in the online editor?

[Yann Orlarey]

A more evolved version allowing to control the other parameters of the
editor (warning: midi support only in chrome)

https://faust.grame.fr/editor/?buffer=256=on=4=https://raw.githubusercontent.com/grame-cncm/faust/master-dev/tests/architecture-tests/organ.dsp


-

Yann Orlarey
Directeur scientifique
www.grame.fr



2018-02-09 17:33 GMT-08:00 Yann Orlarey <orla...@grame.fr>:

> Hi Mykle,
>
> Here is a preliminary version:
>
> https://faust.grame.fr/editor/?code=https://gist.
> githubusercontent.com/orlarey/b928543f68d6ba281c12b0b220562947/raw/
> 900829987bca513daa98ba84ee2a8de653797c0a/djembe.dsp
>
> https://faust.grame.fr/editor/?code=https://faust.grame.fr/
> modules/Kisana.dsp
>
> Yann
>
>
> -
>
> Yann Orlarey
> Directeur scientifique
> www.grame.fr
>
>
>
> 2018-02-09 0:01 GMT-08:00 Stéphane Letz <l...@grame.fr>:
>
>> Not yet !
>>
>> Stéphane
>>
>> > Le 9 févr. 2018 à 07:46, Mykle Hansen <my...@mykle.com> a écrit :
>> >
>> > Hi,
>> >
>> > Question about the online Faust editor: is it possible to
>> > craft a link to the editor that also contains the Faust
>> > code you’d like to see there?  So that I could mail
>> > someone the link & when it opened in a browser, my code would
>> > be present in the editor?  (I’m trying to show off a program
>> > I wrote to a friend who doesn’t have Faust installed.)
>> >
>> > -m-
>> > 
>> --
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > ___
>> > Faudiostream-users mailing list
>> > Faudiostream-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] JUCE award

[Yann Orlarey]

Congratulations Oli!

Yann

-

Yann Orlarey
Directeur scientifique
www.grame.fr



2017-11-20 10:31 GMT-08:00 Oliver Larkin via Faudiostream-users <
faudiostream-users@lists.sourceforge.net>:

> Came 3rd in the end. So very happy at least to be featured in Roli’s mail
> out, sadly they didn’t mention Faust. Got a few more stars on github!
>
> http://mailchi.mp/juce/juce-award-winner
>
> thanks to all who voted for pMix!
>
> oli
>
>
> On 17 Oct 2017, at 16:23, Albert Graef <aggr...@gmail.com> wrote:
>
> Hmmph, *facepalm*. Well, keeping my fingers crossed!
>
> On Tue, Oct 17, 2017 at 5:20 PM, Oliver Larkin <olilar...@googlemail.com>
> wrote:
>
>> thanks but a little premature! voting ends on 13th November 2017. There
>> are some excellent open source projects that will also join, so we will see
>> what happens!
>>
>> if you have a juce project to submit…
>>
>> https://www.juce.com/award#submit
>>
>>
>> oli
>>
>>
>>
>>
>>
>>
>> On 17 Oct 2017, at 16:09, Albert Graef <aggr...@gmail.com> wrote:
>>
>> Hi Oliver,
>>
>> congrats for winning the prize, you really deserve it! :)
>>
>> Best,
>> Albert
>>
>> On Mon, Oct 16, 2017 at 1:04 AM, Oliver Larkin via Faudiostream-users <
>> faudiostream-users@lists.sourceforge.net> wrote:
>>
>>> after failing to win the Faust award twice I've now submitted pMix to
>>> the JUCE award, since, well why not.
>>>
>>> … https://www.juce.com/award
>>>
>>> some new features coming soon including windows and linux support
>>>
>>> oli
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>>> http://sdm.link/slashdot
>>> ___
>>> Faudiostream-users mailing list
>>> Faudiostream-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>
>>
>>
>>
>> --
>> Dr. Albert Gr"af
>> Computer Music Research Group, JGU Mainz, Germany
>> Email:  aggr...@gmail.com
>> WWW:https://plus.google.com/+AlbertGraef
>>
>>
>>
>
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email:  aggr...@gmail.com
> WWW:https://plus.google.com/+AlbertGraef
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] An introduction article (in French) is cooking

[Yann Orlarey]

It worked. Thanks
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Online Faust Editor

[Yann Orlarey]

We have published a new online Faust Editor at http://faust.grame.fr/editor
.

It is still experimental, but it can be used to edit, compile and run Faust
code from any recent Web Browser with webassembly support. This editor
works completely on the client side and it is therefore very convenient for
situations with many simultaneous users (workshops, classrooms, etc.). It
embeds the latest version of the Faust compiler with an efficient
webassembly backend and offers polyphonic MIDI support.

For more information:
http://faust.grame.fr/news/2017/10/20/faust-online-editor.html

As usual, feedback is welcome.

Cheers

Yann
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] [Faudiostream-devel] any windows testers?

[Yann Orlarey]

Many thanks Oli!

-

Yann Orlarey
Directeur scientifique
www.grame.fr



2017-10-22 15:51 GMT+02:00 Oliver Larkin via Faudiostream-devel <
faudiostream-de...@lists.sourceforge.net>:

> if any windows users are interested in having a play with faust2, here are
> some binaries for faust.exe and libfaust.dll
>
> i haven't had much time to test them. WASM and ASMJS not supported with
> these builds
>
>
> https://www.dropbox.com/s/gu3259ewk4ioyx1/faust2win_x64.zip?dl=0
> https://www.dropbox.com/s/5pwv3f1zuh5d5q2/faust2win_x86.zip?dl=0
>
>
> you may need to install the runtime, if you don't have visual studio
> 2015/2017 installed
>
> https://www.microsoft.com/en-gb/download/details.aspx?id=48145
>
>
> oli
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-devel mailing list
> faudiostream-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] simple sequencer logic

[Yann Orlarey]

Hi Sergey,

Thanks for your kind words!

One solution is to play the djembe using the ba.pulsen() function. For
example:

dje = pm.djembe (f,0,2,1, ba.pulsen(200, 4800));


You can also combine pulses using | and & operators:

dje = pm.djembe (f,0,2,1, ba.pulsen(100, 4800) | ba.pulsen(400, 4800*3) |
ba.pulsen(800, 4800*7));


etc.

Cheers

Yann






-----

Yann Orlarey
Directeur scientifique
www.grame.fr



2017-07-05 19:03 GMT+02:00 Beach Dispatcher <bdd...@gmail.com>:

> Hi Everybody!
>
> First of all - great thanks to Faust developers! - it is a piece of art
> that you made=) I appreciate
> your work very much! it is really greatest thing - Faust language.
>
> Im a very beginner newbuy, and my question will seem very foolish, but if
> somebody
> could help to explain me - I will be very glad=)
>
> I want to use simple sequencer to drive djembe module for example.
>
> here is the code:
>
> import("stdfaust.lib");
>
> f = hslider("freq",440,0,1000,1);
> play = button ("play");
>
> dje = pm.djembe (f,0,2,1,play);
>
> process = dje;
>
> So, how is possible to change "play" parameter from 0 to 1 with the temp
> regulator?
> I tried to use:
> tempo = hslider("tempo",0,0,4,0.01);
> play = os.lf_pulsetrainpos(tempo,0.5);
>
> but to not work
>
>
> Could you please explain how is better to make simple sequencer logic to
> drive the triggers of instruments like djembe? Where the trigger
> is the variable in function of instrument.
>
> Thanks in advance for any help to expand my understanding of this logic
>
> Sergey Vasilyev
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] documentation in Faust, translating it to SuperCollider

[Yann Orlarey]

Hi Florian,

Extending the automatic documentation system is certainly possible, but
would require some extra work. Two other (easier) possibilities could be:
- use the same markdown convention that we use for the standard faust
libraries (see documentation/library.pdf/contributing page 15),
- declare your own metadata in the source code and process the json file
"foo.dsp.json" resulting from "faust -json foo.dsp".

Can you give an example of how you would like ideally to document your code?

Cheers

Yann


---------

Yann Orlarey
Directeur scientifique
www.grame.fr



2017-06-14 16:41 GMT+02:00 Florian Grond <floriangr...@gmail.com>:

> Hello,
>
> A group of SuperCollider devs started discussing what a best practice for
> integrating Faust-based SuperCollider plugins should look like. One idea
> that came up was to automate SuperCollider helpfile generation inspired by
> the faust2mathdoc script.
>
> In a SuperCollider helpfile we would need to be able to document all the
> input arguments and also what the UGen returns. Now thinking outside the
> needs of SuperCollider, this would conform with documenting the inlets and
> outlets of MaxMSP or PureData and possibly similar needs on other platforms
> too.
>
> The documentation in chapter 11
> http://faust.grame.fr/images/faust-quick-reference.pdf
> lists 6 specific tags:
> mdoc, equation, diagram, metadata, notice, listing.
>
> None of them seems specifically dedicated to the arguments of the UGen or
> to what the UGen would return e.g. how many audio channels etc.
>
> Questions A) What tag do you suggest? Should a new specific tag be
> introduced? How can documentation be best autogenerated based on the Faust
> code, the wires and what process returns?
>
> Also, we think that the Faust code might possibly contain data structures
> that would be worth translating into Class variables of the SuperCollider
> language side representation the UGen.
> To give an example, I've used many times the Ambisonics decoder toolbox
> which generates Ambisonics decoders as dsp files based on MATLAB code.
> Here it would be fantastic if there was a way to document speaker
> positions in the .dsp file and to translate them into a class variable in
> SuperCollider. I imagine that there are other cases where similar needs
> exist.
>
> Question B) What would be the best way to achieve that? how could these
> types of data best be handled/documented so that it can be passed on to the
> documentation in other platforms?
>
> Florian
>
>
>
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] faust2unity parameter name length

[Yann Orlarey]

Hi,

The names are limited to 16 bytes by Unity:
struct UnityAudioParameterDefinition
{
char name[16];   // Display name on the
GUI
char unit[16];   // Scientific unit of
parameter to be appended after the value in textboxes
const char*  description;// Description of
parameter (displayed in tool tips, automatically generated documentation,
etc.)
floatmin;// Minimum value of
the parameter
floatmax;// Maximum value of
the parameter
floatdefaultval; // Default and initial
value of the parameter
floatdisplayscale;   // Scale factor used
only for the display of parameters (i.e. 100 for a percentage value ranging
from 0 to 1)
floatdisplayexponent;// Exponent for
mapping parameters to sliders
};

What you can do is to use a tooltip to give additional information:

hslider("vol[tooltip:the main volume control]",...)

Cheers

Yann

-----

Yann Orlarey
Directeur scientifique
www.grame.fr



2017-05-03 19:45 GMT+02:00 Juan Cristóbal Cerrillo <jccerri...@gmail.com>:

> Hello,
>
> I’ve created a unity plugin with the faust2unity script.  Everything works
> fine.  Nevertheless, parameter names appear  truncated at the 15 string
> character in Unity.
> One can always use shorter parameter names, but it would be nice if they
> could be longer (especially for complicated graphs).
>
> all best,
>
> jc
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Update of Faust server (macOS targets)

[Yann Orlarey]

Hi,

We are updating the Faust server (macOS machine). During the
update, macOS targets will be unavailable. Sorry for the inconvenience.

Yann
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] language-faust atom package

[Yann Orlarey]

You are welcome!
There is also another useful package: quickdoc.  You can access the Faust
libraries documentation by clicking on a function name and pressing
ctrl-shift-d

Cheers

Yann

-

Yann Orlarey
Directeur scientifique
www.grame.fr



2017-03-03 9:43 GMT+01:00 alfonso santimone <alfonso.santim...@gmail.com>:

> great!
> thanks
> a.
>
> www.elgallorojorecords.com
> soundcloud.com/alfonsosantimone
> www.facebook.com/alfonsosantimone
>
> On Thu, Mar 2, 2017 at 11:18 PM, Yann Orlarey <orla...@grame.fr> wrote:
>
>> If you are an Atom user, there is now a language-faust package with
>> syntax highlighting and snippets for each function of the standard
>> libraries.
>>
>> To install the package: from the Atom menu, select preferences...
>> /+install and enter language-faust.
>>
>> To contribute to the package: https://github.com/grame-cncm/
>> faust-atom-package
>>
>> The snippets for the standard libraries functions are computed
>> automatically by running faust/tools/faust2appls/faust2atomsnippets
>> *.lib in the faust/libraries folder.
>>
>> Cheers
>>
>> Yann
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Faust and Atom Text Editor

[Yann Orlarey]

Hi Oli,

Thanks, that's interesting! I am also happy to discover the snippets and
commands of Vince. We should probably include something like that in the
Faust distribution...

Cheers

Yann

​
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] Any ideas to merge definitions from library files into single dsp file?

[Yann Orlarey]

Hi,

There is currently no such possibility, but that would be certainly nice to
have !
Cheers

Yann

-

Yann Orlarey
Directeur scientifique
www.grame.fr



2016-12-06 17:23 GMT+01:00 松浦知也 <matsuura.nonym...@gmail.com>:

> HI all.
>
> I’m now trying to put all definition of functions/expressions together
> into single dsp source file to archive data which were used in my own
> artwork.
> I wrote my own library file but finally I used not all definitions because
> they include functions for debugging or used in some  experiment.
>
> So,simply I wanna do like below:
>
> in stdfaust.lib
>
> fi = library("filter.lib”);
>
> if my test code.dsp is like
>
> import(“stdfaust.lib”);
>
> process = _<:(fi.lowpass(2,1000),fi.highpass(2,1000));
>
> // I wanna make merged.dsp like
>
> fi  = environment{
> lowpass(N,fc) = lowpass0_highpass1(0,N,fc);
> highpass(N,fc) = lowpass0_highpass1(1,N,fc);
> lowpass0_highpass1(s,N,fc) = lphpr(s,N,N,fc)
> with { lphpr(s,0,N,fc) = _;
>  lphpr(s,1,N,fc) = tf1s(s,1-s,1,2*ma.PI*fc);
>  lphpr(s,O,N,fc) = lphpr(s,(O-2),N,fc) : tf2s(s,0,1-s,a1s,1,w1)
> with { parity = N % 2;
>  S = (O-parity)/2; // current section number
>  a1s = -2*cos((ma.PI)*-1 + (1-parity)*ma.PI/(2*N) + (S-1+parity)*ma.PI/N);
>  w1 = 2*ma.PI*fc;
>   };
>   };
> tf1s=….;
> tf2s=….;
> iir = …;
> ...
> };
>
> process = _<:(fi.lowpass(2,1000),fi.highpass(2,1000));
>
> I already know -e compile option, but it has problem we can’t see what
> functions were used from seeing expanded source from it…
>
> Any ideas to implement this using some shell scripting? Or need to develop
> new compiler option…?
>
> Best regards.
>
>
> Tokyo University of the Arts
> Tomoya Matsuura
>
> matsuura.nonym...@gmail.com
> s2113...@ms.geidai.ac.jp
>
>
>
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] FaucK!!

[Yann Orlarey]

Fantastic, many thanks Romain !

-

Yann Orlarey
Directeur scientifique
www.grame.fr



2016-11-05 0:37 GMT+01:00 Romain Michon <rmnmic...@gmail.com>:

> Hi folks,
>
> We're happy to "officially" announce FaucK!!: a tool allowing to write
> Faust code within Chuck (http://chuck.cs.princeton.edu/). FaucK is
> essentially a Chugin embedding the Faust LLVM compiler. The installation
> instructions and the documentation of FaucK can be found here:
> https://ccrma.stanford.edu/~rmichon/fauck/
>
> FaucK is still being beta tested, so we didn't make a new official chuck
> package for it yet. Feel free to try FaucK and report any bug.
>
> Have fun!
>
> Romain
>
> --
>
> Romain Michon
> PhD Candidate
> Center for Computer Research in Music and Acoustics
> Stanford Universityhttp://ccrma.stanford.edu/~rmichon
>
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Faust Awards 2016

[Yann Orlarey]

*The Faust Open Source Software Competition aims at promoting innovative
high-quality free audio software developed with Faust, a functional
programming language for realtime signal processing and sound synthesis.
The competition is sponsored by GRAME <http://www.grame.fr>, Centre
National de Création Musicale*
Faust Award 2016 to *Ambitools*

The *Faust Award 2016* was attributed by an international committee
composed of :

   - Jean-Louis Giavitto (IRCAM, Paris, France),
   - Albert Graef (Johannes Gutenberg U., Mainz, Germany),
   - Pierre Jouvelot (Ecole des Mines, Paris, France),
   - Victor Lazzarini (Maynooth U., Maynooth, Ireland),
   - Romain Michon (Stanford U., Palo Alto, USA)
   - Yann Orlarey (GRAME, Lyon, France),
   - Dave Phillips (musician, journalist, and educator, USA)
   - Laurent Pottier (U. Jean Monnet, Saint-Etienne, France),
   - Julius Smith (Stanford U., Palo Alto, USA)

to Ambitools <http://www.sekisushai.net/ambitools/>, a set of tools for
real-time 3D sound field synthesis using higher order ambisonics (HOA).

Ambitools is developed by Pierre Lecomte, a PhD candidate at Conservatoire
National des Arts et M etiers and Sherbrooke Universit y. The core of the
sound processing is written in Faust. The tools contain HOA encoders,
decoders, binaural-filters, HOA signals transformations, spherical
VU-Meter, etc. and can be compiled in various plug-ins format under
Windows, Mac OSX, and Linux.

The jury praised the quality and the usefulness of Ambitools: a *really
useful and technically advanced Faust app* and *an impressive technical
achievement* ! Check the demo
<http://www.sekisushai.net/ambitools/wp-content/uploads/2016/05/Demo_ambitools.mp4>
.

The committee was also very impressed by the quality of two other projects :

   - Voice of Faust <https://github.com/magnetophon/VoiceOfFaust>, a voice
   synthesizer/effects machine by Bart Brouns (demo
   <https://magnetophon.github.io/VoiceOfFaust/images/VoiceOfFaust.mp4>).
   - PMix <https://github.com/olilarkin/pMix2>, a graphical patcher, preset
   interpolator and JIT compiler for FAUST by Oliver Larkin (demo
   <https://vimeo.com/122268573>).

Faust Student Software Competition to *TouchVoices*

In parallel to the main competition, we introduced this year a junior
competition: the *Faust Student Software Competition*, intended to promote
small but interesting Faust applications, typically written as student
projects.

The *student prize* was awarded to TouchVoices
<https://patheo.github.io/TouchVoices/> (by Pierre-Adrien Théo, RIM Master
student at University Jean Monnet) a real-time web application allowing to
capture, playback and transform sound loops. Here is a video
<https://www.youtube.com/watch?v=EljDv-mwKW4> of Pierre-Adrien Théo during
a performance with TouchVoices <https://patheo.github.io/TouchVoices/>.

A very close competitor was SuperBeatRepeater
<https://github.com/sonejostudios/SuperBeatRepeater> (by Vincent Rateau, of
*SuperDirt* fame), a sample accurate beat repeater. Don't miss the demo
<https://www.youtube.com/watch?v=C38gep4vkm8=youtu.be=6m17s>!

Yann


-

Yann Orlarey
Directeur scientifique
www.grame.fr
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] FAUST AWARDS 2016

[Yann Orlarey]

FAUST AWARDS 2016

*The Faust Open Source Software Competition aims at promoting innovative
high-quality free audio software developed with Faust, a functional
programming language for realtime signal processing and sound synthesis.
The competition is sponsored by GRAME <http://www.grame.fr>, Centre
National de Création Musicale*
Faust Award 2016 to *Ambitools*

The *Faust Award 2016* was attributed by an international committee
composed of :

   - Jean-Louis Giavitto (IRCAM, Paris, France),
   - Albert Graef (Johannes Gutenberg U., Mainz, Germany),
   - Pierre Jouvelot (Ecole des Mines, Paris, France),
   - Victor Lazzarini (Maynooth U., Maynooth, Ireland),
   - Romain Michon (Stanford U., Palo Alto, USA)
   - Yann Orlarey (GRAME, Lyon, France),
   - Dave Phillips (musician, journalist, and educator, USA)
   - Laurent Pottier (U. Jean Monnet, Saint-Etienne, France),
   - Julius Smith (Stanford U., Palo Alto, USA)

to Ambitools <http://www.sekisushai.net/ambitools/>, a set of tools for
real-time 3D sound field synthesis using higher order ambisonics (HOA).

Ambitools is developed by Pierre Lecomte, a PhD candidate at Conservatoire
National des Arts et M etiers and Sherbrooke Universit y. The core of the
sound processing is written in Faust. The tools contain HOA encoders,
decoders, binaural-filters, HOA signals transformations, spherical
VU-Meter, etc. and can be compiled in various plug-ins format under
Windows, Mac OSX, and Linux.

The jury praised the quality and the usefulness of Ambitools: a *really
useful and technically advanced Faust app*and *an impressive technical
achievement* ! Check the demo
<http://www.sekisushai.net/ambitools/wp-content/uploads/2016/05/Demo_ambitools.mp4>
.

The committee was also very impressed by the quality of two other projects :

   - Voice of Faust <https://github.com/magnetophon/VoiceOfFaust>, a voice
   synthesizer/effects machine by Bart Brouns (demo
   <https://magnetophon.github.io/VoiceOfFaust/images/VoiceOfFaust.mp4>).
   - PMix <https://github.com/olilarkin/pMix2>, a graphical patcher, preset
   interpolator and JIT compiler for FAUST by Oliver Larkin (demo
   <https://vimeo.com/122268573>).

Faust Student Software Competition to *TouchVoices*

In parallel to the main competition, we introduced this year a junior
competition: the *Faust Student Software Competition*, intended to promote
small but interesting Faust applications, typically written as student
projects.

The *student prize* was awarded to TouchVoices
<https://patheo.github.io/TouchVoices/> (by Pierre-Adrien Théo, RIM Master
student at University Jean Monnet) a real-time web application allowing to
capture, playback and transform sound loops. Here is a video
<https://www.youtube.com/watch?v=EljDv-mwKW4> of Pierre-Adrien Théo during
a performance with TouchVoices <https://patheo.github.io/TouchVoices/>.

A very close competitor was SuperBeatRepeater
<https://github.com/sonejostudios/SuperBeatRepeater> (by Vincent Rateau, of
*SuperDirt* fame), a sample accurate beat repeater. Don't miss the demo
<https://www.youtube.com/watch?v=C38gep4vkm8=youtu.be=6m17s>!


-

Yann Orlarey
Directeur scientifique
www.grame.fr
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] Faust.grame.fr server is down

[Yann Orlarey]

Hi

Due to problems with Orange fibre network in Lyon, the Faust server is
down. Orange claims that the problem should be fixed by Saturday 6 pm Paris
time (and hopefully before).

If you are using faustplayground, there is a backup version on github (
http://grame-cncm.github.io/faustplayground/). It will work as the regular
one, but you will not be able to export your code.

Sorry for the inconvenience !

Yann

-

Yann Orlarey
Directeur scientifique
www.grame.fr
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] 'inf' was not declared in this scope

[Yann Orlarey]

Hi,

Right, the compiler try to factorize a multiplication by 0 ! Another way to
see the problem it to compare :

process= (_*cos(1/2*ma.PI)^3,_,_*cos(-1/2*ma.PI)^3);


and

process= (_*cos(1/2*ma.PI)^3,_,_*cos(-1/2*ma.PI)^3) :> _;


in simple and double precision.

Clearly, the factorization rule needs to be fixed

Thanks for discovering the problem !

Yann

Yann Orlarey

Directeur scientifique
www.grame.fr


2016-09-24 18:33 GMT+02:00 Julius Smith <j...@ccrma.stanford.edu>:

> This looks like numerical failure in the optimization by the Faust
> compiler.  You can see it approaching this situation in the following
> simplified case:
>
> process=(_*cos(ma.PI/2),_,_*cos(0-ma.PI/2)):>_;
>
> which compiles to
>
> output0[i] = (FAUSTFLOAT)(6.123234e-17f * (((1.633124e+16f *
> (float)input1[i]) + (float)input0[i]) + (float)input2[i]));
>
> Since cos(PI/2) = 0, the input coefficients are approximately 0,1,0,
> which become (numerically) eps,1,eps, where eps = 6.123234e-17f in
> this particular case.  Factoring out eps gives 1/eps for the
> coefficient of input1, which became infinity in the previous example
> (numerical bug... 1/eps should possibly go to MAX_FLOAT, but not inf).
> If there were a third signal multiplied by eps, then this factoring
> would save a multiply, but in this case there are two multiplies
> either way.
>
> I would personally like to be able to set a magnitude threshold below
> which numbers are flushed to zero.  Then the compiler would see
> coefficients (0,1,0) in this case and not try to factor out the 0.
>
> - Julius
>
> On Fri, Sep 23, 2016 at 7:26 AM, Stéphane Letz <l...@grame.fr> wrote:
> > The generated C++ code is incorrect (see this "(inf.0f *
> (float)input1[i]))) » subexpression), so probably a bug in the compiler.
> >
> > Stéphane
> >
> >
> >> Le 23 sept. 2016 à 13:28, Pierre Lecomte <pierre.leco...@gadz.org> a
> écrit :
> >>
> >> import("stdfaust.lib");
> >> process=(_*cos(1/2*ma.PI)^3,_,_*cos(-1/2*ma.PI)^3):>_;
> >
> >
> > 
> --
> > ___
> > Faudiostream-users mailing list
> > Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> >
> >
>
>
>
> --
> Julius O. Smith III <j...@ccrma.stanford.edu>
> Professor of Music and, by courtesy, Electrical Engineering
> CCRMA, Stanford University
> http://ccrma.stanford.edu/~jos/
>
> 
> --
> ___
> 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

Re: [Faudiostream-users] Ann: Develop Faust programs inside the Radium music editor

[Yann Orlarey]

Hi Michael,

Congratulations : neat and elegant !

Yann

Yann Orlarey

Directeur scientifique
www.grame.fr



On Tue, Jun 28, 2016 at 12:48 PM, Michael Bylstra <mbyls...@gmail.com>
wrote:

> Hi,
>
> This looks great. I've been working on something kind of similar for the
> web. Well, just the editor functionality is similar -  it's not a full
> featured DAW. It's very much a work in progress but you can see a version
> here: http://michaelbylstra.com/faust-instant/
>
> I also considered making Faust programs compile as you type, but
> compilation in a browser is a bit too slow for that. I opted for making
> compile respond to the CTRL-ENTER key combination, like SuperCollider. I
> also find it annoying to have to click a compile button to hear results as
> you type.
>
> "Faust Instant" doesn't offer anything you can't already do with the
> online compiler or the Faust Playground, and it's missing most of their
> functionality. My motivation was that I wanted something super simple
> that's really easy for new users (like myself) to get up and running with.
> It also happens to be written in the Elm programming language - so it was a
> good excuse to write some Elm. I'm hoping it will evolve into an equivalent
> of ShaderToy (of https://www.shadertoy.com/) so people can share Faust
> instruments and demos.
>
> cheers!
>
>
>
> On Fri, Jun 24, 2016 at 4:00 AM, Kjetil Matheussen <
> k.s.matheus...@gmail.com> wrote:
>
>> Hello all,
>>
>> With the help of libfaust, you can now develop programs within
>> the Radium music editor. This has several advantages:
>>
>> * Hear (and see) immediately the changes while writing.
>>   I.e. realtime compilation. No "compile" button.
>>
>> (Hmm, I guess "several advantages" was a bit exaggerated,
>> considering it's only one, but it's a quite big one though,
>> I think.)
>>
>> Here's a video:
>> https://www.youtube.com/watch?v=LJm9Lox1WFA
>>
>> Radium is available here:
>> http://users.notam02.no/~kjetism/radium/
>>
>> This feature is available in the latest version of Radium (V3.9.4)
>> for Linux, Mac OS X, and Windows 64 bit.
>>
>>
>>
>> --
>> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> ___
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>
>>
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users