rdtable has three input signals. The first one must be contant and known at
compile time, it define the size of the table, The second input signal
defines the content of the table and must be also known at compile time.
And the third signal is the read index and it must generate values in the
limits of the table.
In your first example the compiler will compute the first 2048 samples of
the second signal and store in the table. But in your second example the
signal used to fill the table is not known at compile time (because it
depends of the audio input). This is why it is rejected.
Yann
2014-05-21 14:42 GMT+01:00 Stephen Sinclair <radars...@gmail.com>:
> On Tue, May 13, 2014 at 9:02 PM, Orlarey Yann <orla...@grame.fr> wrote:
> > Hi Stephen,
> >
> > The third input signal of rdtable is the read index. In your case it
> should
> > be an integer signal with values in the interval [0..2047]. But in your
> > example cnt will generate reads outside the boundaries of the table
> causing
> > segfaults. In other words you should use a phasor as read index. You can
> > have a look at osc in music.lib...
>
> Okay I see now that osc uses x-floor(x) to generate a bounded phasor
> for the 3rd argument.
>
> However, I don't understand the inputs to rdtable. I thought maybe
> the 3rd argument was a *write* index to be honest, eg. the input to
> the fill() function, or something. If it is the *read* index, then
> what is the left-over input that drives an rdtable?
>
> That is, the following compiles and works as expected:
>
> ~~~~~~~~~~~~
> increment = +(1) ~ _;
> cnt = int(+(1) ~ %(2048) : -(1));
> func = (_/2048*2*PI - PI) : sin;
> tab = max(0,_) : min(_, 2048) : rdtable(2048, func, cnt);
> process = increment : tab;
> ~~~~~~~~~~~~
>
> whereas, simply "process = tab" does not.
>
> This implies to me that rdtable() takes 3 arguments, PLUS an
> additional input which drives it, which I thought was the read index.
> Additionally, "process = (increment+1024) : tab" gives a
> half-rectified sinusoid (due to min(2048)), which implies that this
> additional input does indeed drive it as the read index.
>
> So what is the role of the 3rd argument vs. the input signal? Is one
> at run-time and the other at initialization time? If so, which is
> which?
>
> thanks,
> Steve
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Faudiostream-devel mailing list
> Faudiostream-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-devel
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Faudiostream-devel mailing list
Faudiostream-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-devel