No, that creates an empty (silent) buffer for the oscillator generation to
write to.
The code that needs rewriting is the code that calls sin().
-Manish Goregaokar
On Wed, Nov 7, 2018 at 3:27 PM Avanthikaa Ravichandran
wrote:
> Thank you for your response.
> I was also wondering if the statem
Thank you for your response.
I was also wondering if the statement
inputs.blocks.push(Default::default());
in "oscillator_node.rs" is the one setting default values for the
oscillator node wave? What exactly does this statement push into the input
blocks? From my understanding, this needs to be rew
Yes, if there are types that derive Copy right now that are being
modified in ways that forbid that (such as adding a Vec member), feel
free to remove the derivation.
Cheers,
Josh
On 11/6/18 8:09 PM, Avanthikaa Ravichandran wrote:
Hi,
I am trying to write an implementation for the PeriodicWav
Yeah, it is fine to remove the Copy.
On Tue, Nov 6, 2018, 5:09 PM Avanthikaa Ravichandran Hi,
> I am trying to write an implementation for the PeriodicWaveOptions in the
> oscillator node. The parameters for this - real and imaginary, do not have
> fixed sizes at compile time since they depend on
Hi,
I am trying to write an implementation for the PeriodicWaveOptions in the
oscillator node. The parameters for this - real and imaginary, do not have
fixed sizes at compile time since they depend on the user input options.
This requires the use of the Vec datatype. However, vectors do not derive
5 matches
Mail list logo
