RBEP->SDIFBuffer->sdif::ToSinusoids->AddSynth
Brought to you by:
peoplestank
Menu
▾
▴
Anyone see any glitches in a competent programmer doing the above? Loris RBEL matrices represent partials with exact timing envelope points - the timing of the envelopes have not been adjusted to regular intervals to make synthesizing less demanding. Not sure if this would matter to the OSW transforms.
Have not studied source yet .... SDIFBuffer output stream would include the Loris noise partial data, and the sdiff::ToSinusoids would output the noise partial plus sine partials. AddSynth takes the partial data - now including noise partial and creates sample data.
So does AddSynth care about env points falling on regular time intervals?
Should be sitting on a beach right now in Negril, Jamaica - but we think the beach is gone. Need some coding challenges to keep my mind from Red Stripe and Cool Music :-)
Regards,
Mic.
sdif::ToSinusoids should be able to read Loris SDIF files, but it will currently through away the additional columns for bandwidth and time displacement. The resulting output of AddSynth will thus not take the exact envelopes or noisiness (bandwidth) of partials into account.
The Sinusoids data type only includes partial index, frequency, amplitude and phase. In order to fully support bandwidth-enhanced sinusoids, we need a new data type that is a subclass of Sinusoids (NoisySinusoids?), and a new transform that implements Loris-type synthesis.
Thanks so much for the info - do I stand a chance of implementing this? :-)
Or as the author, knowing what it would entail, would you tactfully say " I advise you to wait to see if we implement this"?
Mic.
Actually, I would say you have a decent chance of being able to implement this as an OSW external. My advice would be to wait on the data structure part (I have some ideas how I want to do that so that the extended versions remain compatible with the existing Sinusoids transforms), and when that's done, go ahead and give the Loris port a try.
Stay tuned...