Re: [PD] [PD-announce] faustgen~ - the FAUST compiler embedded in a Pure Data external

[Esteban Viveros]

Wowww.. Thanks for that!! Some possibity to have an ARM compilation (for
RPi) in deken for it?
Em sáb, 28 de jul de 2018 às 09:31, Max 
escreveu:

> Very cool.
>
> I wish I could just (double)click on the object to see and edit the
> faust code in an editor (of my choice).
>
> What is the recommended workflow for faustgen~?
>
>
>
> On 28.07.2018 11:52, Pierre Guillot wrote:
> > Hi,
> >
> > The CICM and the GRAME are pleased to announce the faustgen~ object for
> > Pure Data.
> >
> > Faustgen~ is an external object with the FAUST just-in-time (JIT)
> > compiler embedded that allows to load, compile and play FAUST files
> > within the audio programming environment Pure Data. FAUST (Functional
> > Audio Stream) is a functional programming language specifically designed
> > for real-time signal processing and synthesis developed by the GRAME.
> > The FAUST JIT compiler - built with LLVM - brings together the
> > convenience of a standalone interpreted language with the efficiency of
> > a compiled language. The faustgen~ object for Pure Data is a very first
> > version with elementary features, help and contributions are more than
> > welcome. The faustgen~ object is available for Linux, Mac and Windows
> > (64-bit) via Deken (v0.4.1) or via the github repository:
> > https://github.com/CICM/pd-faustgen/releases.
> >
> > We hope that you'll enjoy this project!
> >
> > FAUST: http://faust.grame.fr 
> > GRAME: http://www.grame.fr 
> > CICM:http://cicm.mshparisnord.org 
> >
> >
> >
> >
> >
> > ___
> > Pd-announce mailing list
> > pd-annou...@lists.iem.at
> > https://lists.puredata.info/listinfo/pd-announce
> >
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> >
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-- 

www.estebanviveros.com
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] faustgen~ - the FAUST compiler embedded in a Pure Data external

[Max]

Very cool.

I wish I could just (double)click on the object to see and edit the 
faust code in an editor (of my choice).


What is the recommended workflow for faustgen~?



On 28.07.2018 11:52, Pierre Guillot wrote:

Hi,

The CICM and the GRAME are pleased to announce the faustgen~ object for 
Pure Data.


Faustgen~ is an external object with the FAUST just-in-time (JIT) 
compiler embedded that allows to load, compile and play FAUST files 
within the audio programming environment Pure Data. FAUST (Functional 
Audio Stream) is a functional programming language specifically designed 
for real-time signal processing and synthesis developed by the GRAME. 
The FAUST JIT compiler - built with LLVM - brings together the 
convenience of a standalone interpreted language with the efficiency of 
a compiled language. The faustgen~ object for Pure Data is a very first 
version with elementary features, help and contributions are more than 
welcome. The faustgen~ object is available for Linux, Mac and Windows 
(64-bit) via Deken (v0.4.1) or via the github repository: 
https://github.com/CICM/pd-faustgen/releases.


We hope that you'll enjoy this project!

FAUST: http://faust.grame.fr 
GRAME: http://www.grame.fr 
CICM:http://cicm.mshparisnord.org 





___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] triggering [print~] faster than every 64 samples

[mario buoninfante]

Hi Christof,


thanks a lot for this :D
in the meanwhile I looked at Miller Puckette's book, and in fact what 
you described is reported also there.


thanks for your explanation.


cheers,

Mario


On 28/07/18 12:58, Christof Ressi wrote:

Hi Mario,

you're right, [del], [pipe] (and [metro] btw) themselves are unproblematic 
because clocks are timestamped (and therefore [timer] will show the correct 
logical time). the problem really lies in the conversion from/to audio, as you 
noted correctly.

for the sake of completeness:

with every scheduler tick, Pd checks for clock timeouts, polls the GUI and does 
64 samples of DSP computation.
now let's say a canvas has [block~ 256]: in the first 3 schedular ticks nothing happens 
expect for [inlet~] buffering, only at the 4th tick we actually do the 256 samples of 
DSP. but this means that clock timeouts can only happen before those 256 samples - not in 
between! still, clock timeouts happen at the same "rate" as DSP computation.
now imagine this canvas has a subcanvas with [block~ 64]: everytime the parent 
canvas (256 samples) is processed, the subcanvas (64 samples) gets processed 4 
times in a row and clock timeouts effectively only happen every 4 blocks. but 
this means DSP computation and clock timeouts are out of sync and even 
sub-sample correct objects like [vline~] might behave strangely.

eventually, the number of samples between clock timeouts for a canvas and all 
its subcanvasses is determined by the largest blocksize within the list of 
parent canvasses.

[block~ 1] on a root canvas is just the simple case where the parent blocksize 
equals the schedular tick size of 64 samples.

Christof



Gesendet: Samstag, 28. Juli 2018 um 11:50 Uhr
Von: "mario buoninfante" 
An: "Christof Ressi" 
Cc: Pd-List 
Betreff: Re: Aw: [PD] triggering [print~] faster than every 64 samples

Hi Christof,


thanks for that, this clarifies quite a lot of things. that said it
seems that objects like [del] and [pipe] can deal with this kind of
situations (ie [del 1 10 samp]). the "issue" seems to appear when you
start using "hybrid" objects (control signal to audio signal or the
other way around). am I right assuming that?


cheers,

Mario


On 28/07/18 10:43, Christof Ressi wrote:

the technical reason is that clock timeouts can't happen in intervals smaller 
than 64 samples (pd's scheduler blocksize) *), so any objects relying on clocks 
(e.g. [print~], [bang~], [line~], [vline~], [del], [pipe], etc) might not work 
as expected.

Christof

*) more generally, clock timeouts are limited to the largest parent blocksize. 
see attached patch.


Gesendet: Samstag, 28. Juli 2018 um 10:45 Uhr
Von: "mario buoninfante" 
An: Pd-List 
Betreff: [PD] triggering [print~] faster than every 64 samples

Hi,

I'm trying to trigger [print~] every sample. in the same patch I'm using
[block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger
[print~].

but I noticed that [print~] is yes printing 1 sample at time (in accord
with the block size) but only every 64 samples. so it receives a bang
every sample but prints every 64 (default block size).

can you guys help me understanding why? I'm pretty sure I'm missing
something here :D


cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] triggering [print~] faster than every 64 samples

[Christof Ressi]

Hi Mario,

you're right, [del], [pipe] (and [metro] btw) themselves are unproblematic 
because clocks are timestamped (and therefore [timer] will show the correct 
logical time). the problem really lies in the conversion from/to audio, as you 
noted correctly.

for the sake of completeness:

with every scheduler tick, Pd checks for clock timeouts, polls the GUI and does 
64 samples of DSP computation. 
now let's say a canvas has [block~ 256]: in the first 3 schedular ticks nothing 
happens expect for [inlet~] buffering, only at the 4th tick we actually do the 
256 samples of DSP. but this means that clock timeouts can only happen before 
those 256 samples - not in between! still, clock timeouts happen at the same 
"rate" as DSP computation.
now imagine this canvas has a subcanvas with [block~ 64]: everytime the parent 
canvas (256 samples) is processed, the subcanvas (64 samples) gets processed 4 
times in a row and clock timeouts effectively only happen every 4 blocks. but 
this means DSP computation and clock timeouts are out of sync and even 
sub-sample correct objects like [vline~] might behave strangely.

eventually, the number of samples between clock timeouts for a canvas and all 
its subcanvasses is determined by the largest blocksize within the list of 
parent canvasses.

[block~ 1] on a root canvas is just the simple case where the parent blocksize 
equals the schedular tick size of 64 samples.

Christof


> Gesendet: Samstag, 28. Juli 2018 um 11:50 Uhr
> Von: "mario buoninfante" 
> An: "Christof Ressi" 
> Cc: Pd-List 
> Betreff: Re: Aw: [PD] triggering [print~] faster than every 64 samples
>
> Hi Christof,
> 
> 
> thanks for that, this clarifies quite a lot of things. that said it 
> seems that objects like [del] and [pipe] can deal with this kind of 
> situations (ie [del 1 10 samp]). the "issue" seems to appear when you 
> start using "hybrid" objects (control signal to audio signal or the 
> other way around). am I right assuming that?
> 
> 
> cheers,
> 
> Mario
> 
> 
> On 28/07/18 10:43, Christof Ressi wrote:
> > the technical reason is that clock timeouts can't happen in intervals 
> > smaller than 64 samples (pd's scheduler blocksize) *), so any objects 
> > relying on clocks (e.g. [print~], [bang~], [line~], [vline~], [del], 
> > [pipe], etc) might not work as expected.
> >
> > Christof
> >
> > *) more generally, clock timeouts are limited to the largest parent 
> > blocksize. see attached patch.
> >
> >> Gesendet: Samstag, 28. Juli 2018 um 10:45 Uhr
> >> Von: "mario buoninfante" 
> >> An: Pd-List 
> >> Betreff: [PD] triggering [print~] faster than every 64 samples
> >>
> >> Hi,
> >>
> >> I'm trying to trigger [print~] every sample. in the same patch I'm using
> >> [block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger
> >> [print~].
> >>
> >> but I noticed that [print~] is yes printing 1 sample at time (in accord
> >> with the block size) but only every 64 samples. so it receives a bang
> >> every sample but prints every 64 (default block size).
> >>
> >> can you guys help me understanding why? I'm pretty sure I'm missing
> >> something here :D
> >>
> >>
> >> cheers,
> >>
> >> Mario
> >>
> >>
> >> ___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> https://lists.puredata.info/listinfo/pd-list
> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] faustgen~ - the FAUST compiler embedded in a Pure Data external

[Pierre Guillot]

Hi,

The CICM and the GRAME are pleased to announce the faustgen~ object for
Pure Data.

Faustgen~ is an external object with the FAUST just-in-time (JIT) compiler
embedded that allows to load, compile and play FAUST files within the audio
programming environment Pure Data. FAUST (Functional Audio Stream) is a
functional programming language specifically designed for real-time signal
processing and synthesis developed by the GRAME. The FAUST JIT compiler -
built with LLVM - brings together the convenience of a standalone
interpreted language with the efficiency of a compiled language. The
faustgen~ object for Pure Data is a very first version with elementary
features, help and contributions are more than welcome. The faustgen~
object is available for Linux, Mac and Windows (64-bit) via Deken (v0.4.1)
or via the github repository: https://github.com/CICM/pd-faustgen/releases.

We hope that you'll enjoy this project!

>
> FAUST: http://faust.grame.fr
GRAME: http://www.grame.fr
CICM: http://cicm.mshparisnord.org

>
___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] triggering [print~] faster than every 64 samples

[mario buoninfante]

Hi Christof,


thanks for that, this clarifies quite a lot of things. that said it 
seems that objects like [del] and [pipe] can deal with this kind of 
situations (ie [del 1 10 samp]). the "issue" seems to appear when you 
start using "hybrid" objects (control signal to audio signal or the 
other way around). am I right assuming that?



cheers,

Mario


On 28/07/18 10:43, Christof Ressi wrote:

the technical reason is that clock timeouts can't happen in intervals smaller 
than 64 samples (pd's scheduler blocksize) *), so any objects relying on clocks 
(e.g. [print~], [bang~], [line~], [vline~], [del], [pipe], etc) might not work 
as expected.

Christof

*) more generally, clock timeouts are limited to the largest parent blocksize. 
see attached patch.


Gesendet: Samstag, 28. Juli 2018 um 10:45 Uhr
Von: "mario buoninfante" 
An: Pd-List 
Betreff: [PD] triggering [print~] faster than every 64 samples

Hi,

I'm trying to trigger [print~] every sample. in the same patch I'm using
[block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger
[print~].

but I noticed that [print~] is yes printing 1 sample at time (in accord
with the block size) but only every 64 samples. so it receives a bang
every sample but prints every 64 (default block size).

can you guys help me understanding why? I'm pretty sure I'm missing
something here :D


cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] triggering [print~] faster than every 64 samples

[Christof Ressi]

the technical reason is that clock timeouts can't happen in intervals smaller 
than 64 samples (pd's scheduler blocksize) *), so any objects relying on clocks 
(e.g. [print~], [bang~], [line~], [vline~], [del], [pipe], etc) might not work 
as expected.

Christof

*) more generally, clock timeouts are limited to the largest parent blocksize. 
see attached patch.

> Gesendet: Samstag, 28. Juli 2018 um 10:45 Uhr
> Von: "mario buoninfante" 
> An: Pd-List 
> Betreff: [PD] triggering [print~] faster than every 64 samples
>
> Hi,
> 
> I'm trying to trigger [print~] every sample. in the same patch I'm using 
> [block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger 
> [print~].
> 
> but I noticed that [print~] is yes printing 1 sample at time (in accord 
> with the block size) but only every 64 samples. so it receives a bang 
> every sample but prints every 64 (default block size).
> 
> can you guys help me understanding why? I'm pretty sure I'm missing 
> something here :D
> 
> 
> cheers,
> 
> Mario
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 

clock_test.pd
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] triggering [print~] faster than every 64 samples

[mario buoninfante]

Hi,

I'm trying to trigger [print~] every sample. in the same patch I'm using 
[block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger 
[print~].


but I noticed that [print~] is yes printing 1 sample at time (in accord 
with the block size) but only every 64 samples. so it receives a bang 
every sample but prints every 64 (default block size).


can you guys help me understanding why? I'm pretty sure I'm missing 
something here :D



cheers,

Mario


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list