polyphonic synth with cnmat's sinusoids~

giantmolecules's icon

hi everyone,

as of late, i've become interested in spectral synthesis and am currently trying to develop a polyphonic synthesizer using cnmat's sinusoids~ object. It's a basic synth similar to the one described in the synth-building tutorials on this site.

i am relatively new to spectral synthesis. i have gone through all the tutorials provided by cnmat and am quite pleased by what i've learned. i've been using spear to analyze piano notes and have been subsequently hand-picking partials to place in a (somewhat large, but less than 256-element) message that is fed to sinusoids~. i am also using sin-transform to scale the partials. this is encapsulated in a poly~ voice patcher that receives the midi notes and velocity from the parent synth patch. the result is only a monophonic synth that at least responds correctly to midi input.

i concluded that sinusoids~ is probably not the correct object in this case, and perhaps sin-synth~ is more appropriate, but considering that i would then need separately named sdif buffers for each instance (as far as i can understand), i have no idea as to how that would be done. i suppose one could set up sixteen buffers at startup to cover all possible simultaneous notes, but that seems somehow wasteful of memory space. i also admit that i know very little of OSC, if that would have any benefit here.

so, my attempts to make a polyphonic synth have failed thus far, and now i turn to you for advice. any ideas?

best,

gm

mzed's icon

Hi giantmolecules-

sin-synth~ has an SDIF-buffer~ object built into it, so each copy will add another buffer. I don't think you'll have a memory problem with six of them, but you could make a version that uses an external buffer. That's what I would do.

Quickly, I'd save a copy of sin-synth~ as sin-synth-ext~, or something, and delete the SDIF-buffer object from that new version. Then, I'd make an SDIF-buffer at a high level of the patch that holds your model. Finally, I would name each instance of the new sin-synt-ext~ with the same name as your SDIF-buffer. This will screw up their ability to have separate messages via "send OSC," but you could still talk to them via their inlets.

IS that at all clear?

mz

Quote: giantmolecules wrote on Tue, 23 October 2007 18:25
----------------------------------------------------
> hi everyone,
>
> as of late, i've become interested in spectral synthesis and am currently trying to develop a polyphonic synthesizer using cnmat's sinusoids~ object. It's a basic synth similar to the one described in the synth-building tutorials on this site.
>
> i am relatively new to spectral synthesis. i have gone through all the tutorials provided by cnmat and am quite pleased by what i've learned. i've been using spear to analyze piano notes and have been subsequently hand-picking partials to place in a (somewhat large, but less than 256-element) message that is fed to sinusoids~. i am also using sin-transform to scale the partials. this is encapsulated in a poly~ voice patcher that receives the midi notes and velocity from the parent synth patch. the result is only a monophonic synth that at least responds correctly to midi input.
>
> i concluded that sinusoids~ is probably not the correct object in this case, and perhaps sin-synth~ is more appropriate, but considering that i would then need separately named sdif buffers for each instance (as far as i can understand), i have no idea as to how that would be done. i suppose one could set up sixteen buffers at startup to cover all possible simultaneous notes, but that seems somehow wasteful of memory space. i also admit that i know very little of OSC, if that would have any benefit here.
>
> so, my attempts to make a polyphonic synth have failed thus far, and now i turn to you for advice. any ideas?
>
> best,
>
> gm
>
>
----------------------------------------------------

mzed's icon

Quote: mzed wrote on Wed, 24 October 2007 12:33
----------------------------------------------------
>
> sin-synth~ has an SDIF-buffer~ object built into it, so each copy will add another buffer. I don't think you'll have a memory problem with six of them, but you could make a version that uses an external buffer. That's what I would do.
>
>

In fact, that's what I did:

Expect that in the next release of the CNMAT MMJ Depot.

mz