I am also planning to add a few new opcodes in the next few days for dynamic
waveshaping and phase distortion.  I am sure that the waveshaping opcodes
will be useful, but I wonder about the phase distortion ones.  I am
considering adding them because two of them would require ksmps == 1 to
emulate with orchestra code.  (pdclip could be emulated with the limit
opcode, I think).  Do you think these opcodes will be useful enough or
should I just make them available as UDOs?

aout    pdhalf      ain, kShapeAmount [, ifullscale]
aout    pdhalfy     ain, kShapeAmount [, ifullscale]
aout    pdclip      ain, kWidth, kCenter [, ifullscale]

PDhalf

This opcode is designed to emulate the "classic" phase distortion synthesis
method of the Casio CZ-series of synthesizers from the mid-1980's.  This
technique reads the first and second halves of a function table at different
rates in order to warp the waveform.  The rates are chosen so that the
overall period of oscillation is preserved.  Thus, phase distortion can only
produce higher partials in a harmonic series.  It does not produce sidebands
which may be inharmonic in the way that frequency modulation does.

pdhalf calculates a transfer function which is composed of two linear
segments.  (See attached image).  These segments meet at a "pivot point"
which always lies on the x axis (for a bipolar input).  The kShapeAmount
parameter specifies where on the x axis this point falls.  The negative half
of the input range is mapped linearly between -1.0*ifullscale and
kShapeAmount.  The positive half is mapped linearly between kShapeAmount and
ifullscale.  A value of zero for kShapeAmount will not have any effect on
the input signal.  If the output is used to index a table, values for
kShapeAmount that are less than zero will cause the first half of the table
to be read more quickly than the second half.  The reverse is true for
values of kShapeAmount greater than zero.

Currently, pdhalf expects a bipolar input signal.  So you must scale and
offset your input (and output!) appropriately if it is a unipolar phasor.  I
will probably add an optional parameter to support unipolar signals before
committing.  kShapeAmount is always between -1 and 1 for bipolar operation.

A typical example of the use of pdhalf is
  aosc  phasor  ifreq
  apd   pdhalf  2*aosc - 1.0, kamount   ; convert aosc to bipolar
  aout  tablei  0.5*(apd+1.0), 1, 1     ; convert apd back to unipolar

PDhalfy

This is a variation on PDhalf that places the pivot point of the phase
distortion on the y axis instead of the x axis.  Thus, it does not read the
two halves of a table at different rates, but instead divides it into two
segments of different sizes depending upon the kShapeAmount parameter.  Each
of these segments is then mapped to half of the oscillator period (or just
the output range if not being used to distort a phasor).  This opcode has a
milder quality to its distortion in my experience.

PDclip

This opcode performs linear clipping on the input signal ain. kwidth is the
percentage of the signal range that is clipped (must be between 0 and 1).
The rest of the input range is mapped linearly from -ifullscale to
ifullscale.  kcenter specifies an offset for shifting the unclipped window
of the signal higher or lower in the range (essentially a DC offset).
ifullscale sets the maximum amplitude of the input and output signals
(defaults to 1.0).

This amounts to waveshaping the input with the following transfer function
(normalized to ifullscale=1.0) :

        1|   _______      width of clipped region is kwidth
         |  /             width of unclipped region is (1-kwidth)
         | /              kcenter shifts the unclipped region
-1       |/        1        left or right (up to kwidth)
--------------------
        /|
       / |
      /  |
------   |-1

This opcode may be used for direct, linear distortion of an audio signal.
Alternatively, you might use it to modify the output of a phasor before it
is used to index a function table, effectively making this a phase
distortion technique.

Victor.Lazzarini@nuim.ie wrote on 12/5/07 2:54 AM:

> PD seem useful. UDOs are also good because they're didactical, can you
> do both?

Thanks.  I wrote the phase dist. opcodes (and powershape below) a while ago
but I will make UDOs too.

> How do the waveshaping opcodes you mention
> differ from simply building them with oscillator and table
> lookup?

They allow for _dynamic_ waveshaping where the transfer function varies over
time.  I have written the following opcodes so far and hope to come up with
some more:

aout  powershape    ain, kShapeAmount [, ifullscale]
aout  polynomial    ain, ka0 [, ka1 [, ka2 [...]]]
aout  chebyshevpoly ain, ka0 [, ka1 [, ka2 [...]]]

polynomial efficiently calculates any single-variable polynomial with k-rate
coefficients.  chebyshevpoly does the same but each coefficient is a
multiplier for an nth-order chebyshev polynomial.  With a sine wave input,
this allows precise time-varying control over any number of
harmonically-tuned partials, but requires only one oscillator.
 
Manual description for powershape:

This opcode is very similar to the pow unit generators that already exist in
Csound for calculating the mathematical "power of" operation.  However, it
introduces a couple of twists which I think make it much more useful for
waveshaping audio-rate signals.  The kShapeAmount parameter is the exponent
to which the input signal is raised.

Normally, unless the exponent is an odd integer, the pow() of a negative
input is a complex number, so the Csound ugens simply return zero in those
cases.  This will turn a bipolar audio signal into a unipolar signal with
large portions of the output pinned to zero.  The powershape opcode instead
treats all input values as positive but preserves their sign in the output
signal.  This allows for smooth shaping of any input signal while varying
the exponent over any range.  (Powershape also (hopefully) deals
intelligently with  discontinuities that could arise when the exponent and
input are both zero.  Note though that negative exponents will usually cause
the signal to exceed the maximum amplitude specified by the ifullscale
parameter and should normally be avoided).

The other adaptation involves the ifullscale parameter.  The input signal is
divided by ifullscale before being raised to kShapeAmount and then
multiplied by ifullscale before being output.  This normalizes the input
signal to the interval [-1,1], guaranteeing that the output will also be
within this range.  Also, the pow() function provides a smoothly evolving
transfer function when its input is in this range.  Values of kShapeAmount
between (0,1) will make the signal more "convex" while values greater than 1
will make it more "concave" and a value of exactly 1.0 will produce no
change in the input signal.


Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://anthonykozar.net/


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree that it would be excellent to have both the opcodes and the  
UDOs.

-dB


On Dec 5, 2007, at 2:54 AM, Victor.Lazzarini@nuim.ie wrote:

> PD seem useful. UDOs are also good because they're didactical, can you
> do both?
>
> How do the waveshaping opcodes you mention
> differ from simply building them with oscillator and table
> lookup?
>
> Victor
> ----- Original Message -----
> From: Anthony Kozar 
> Date: Wednesday, December 5, 2007 2:33 am
> Subject: [Cs-dev] New opcodes useful?
> To: New Csound Developer list 
>
> > I am also planning to add a few new opcodes in the next few days
> > for dynamic
> > waveshaping and phase distortion.  I am sure that the
> > waveshaping opcodes
> > will be useful, but I wonder about the phase distortion
> > ones.  I am
> > considering adding them because two of them would require ksmps
> > == 1 to
> > emulate with orchestra code.  (pdclip could be emulated
> > with the limit
> > opcode, I think).  Do you think these opcodes will be
> > useful enough or
> > should I just make them available as UDOs?
> >
> > aout    pdhalf      ain,
> > kShapeAmount [, ifullscale]
> > aout    pdhalfy     ain,
> > kShapeAmount [, ifullscale]
> > aout    pdclip      ain,
> > kWidth, kCenter [, ifullscale]
> >
> > PDhalf
> >
> > This opcode is designed to emulate the "classic" phase
> > distortion synthesis
> > method of the Casio CZ-series of synthesizers from the mid-
> > 1980's.  This
> > technique reads the first and second halves of a function table
> > at different
> > rates in order to warp the waveform.  The rates are chosen
> > so that the
> > overall period of oscillation is preserved.  Thus, phase
> > distortion can only
> > produce higher partials in a harmonic series.  It does not
> > produce sidebands
> > which may be inharmonic in the way that frequency modulation does.
> >
> > pdhalf calculates a transfer function which is composed of two  
> linear
> > segments.  (See attached image).  These segments meet
> > at a "pivot point"
> > which always lies on the x axis (for a bipolar input).  The
> > kShapeAmountparameter specifies where on the x axis this point
> > falls.  The negative half
> > of the input range is mapped linearly between -1.0*ifullscale and
> > kShapeAmount.  The positive half is mapped linearly between
> > kShapeAmount and
> > ifullscale.  A value of zero for kShapeAmount will not have
> > any effect on
> > the input signal.  If the output is used to index a table,
> > values for
> > kShapeAmount that are less than zero will cause the first half
> > of the table
> > to be read more quickly than the second half.  The reverse
> > is true for
> > values of kShapeAmount greater than zero.
> >
> > Currently, pdhalf expects a bipolar input signal.  So you
> > must scale and
> > offset your input (and output!) appropriately if it is a
> > unipolar phasor.  I
> > will probably add an optional parameter to support unipolar
> > signals before
> > committing.  kShapeAmount is always between -1 and 1 for
> > bipolar operation.
> >
> > A typical example of the use of pdhalf is
> >   aosc  phasor  ifreq
> >   apd   pdhalf  2*aosc - 1.0,
> > kamount   ; convert aosc to bipolar
> >   aout  tablei  0.5*(apd+1.0), 1,
> > 1     ; convert apd back to unipolar
> >
> > PDhalfy
> >
> > This is a variation on PDhalf that places the pivot point of the  
> phase
> > distortion on the y axis instead of the x axis.  Thus, it
> > does not read the
> > two halves of a table at different rates, but instead divides it
> > into two
> > segments of different sizes depending upon the kShapeAmount
> > parameter.  Each
> > of these segments is then mapped to half of the oscillator
> > period (or just
> > the output range if not being used to distort a phasor).
> > This opcode has a
> > milder quality to its distortion in my experience.
> >
> > PDclip
> >
> > This opcode performs linear clipping on the input signal ain.
> > kwidth is the
> > percentage of the signal range that is clipped (must be between
> > 0 and 1).
> > The rest of the input range is mapped linearly from -ifullscale to
> > ifullscale.  kcenter specifies an offset for shifting the
> > unclipped window
> > of the signal higher or lower in the range (essentially a DC  
> offset).
> > ifullscale sets the maximum amplitude of the input and output  
> signals
> > (defaults to 1.0).
> >
> > This amounts to waveshaping the input with the following
> > transfer function
> > (normalized to ifullscale=1.0) :
> >
> >         1|
> > _______      width of clipped region is
> > kwidth         |
> > /             width of unclipped region is (1-kwidth)
> >          |
> > /              kcenter shifts the unclipped region
> > -1
> > |/        1        left or right (up to kwidth)
> > --------------------
> >         /|
> >        / |
> >       /  |
> > ------   |-1
> >
> > This opcode may be used for direct, linear distortion of an
> > audio signal.
> > Alternatively, you might use it to modify the output of a phasor
> > before it
> > is used to index a function table, effectively making this a phase
> > distortion technique.
> >
> > > -----------------------------------------------------------------
> > --------
> > SF.Net email is sponsored by: The Future of Linux Business White  
> Paper
> > from Novell.  From the desktop to the data center, Linux is going
> > mainstream.  Let it simplify your IT future.
> > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4>  
> _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> ---------------------------------------------------------------------- 
> ---
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/ 
> 8857-50307-18918-4_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, if my intuitions are correct, using continuous k-rate coefficients
with either the polynomial or chebyshevpoly opcodes should produce smooth
and continuous changes in the output.  I have tested the latter by
controlling several harmonics independently and I got smooth changes just as
if I had used additive synthesis with multiple oscillators.  I would be
interested to know if there is some mathematical problem that I am
overlooking.

Regarding the phase distortion opcodes:  the reason I was questioning their
utility is that they DO produce aliasing because the derivative of the
resulting signal is discontinuous.  I think -- but am not sure -- that
Casio's original implementation of this technique was not 100% digital.  But
depending on the genre of music, aliasing is not always a bad thing :)

Another use for the PD opcodes is to use them on audio signals instead of
phasors, in which case they behave as piecewise-linear transfer functions.
This also produces aliasing, but they have definite applications as
alternative distortion techniques.  powershape is also excellent for
distortion, although it can produce milder, bandlimited changes too.

At least this is my understanding of everything -- I am not a DSP guru ...

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://anthonykozar.net/


> Victor.Lazzarini@nuim.ie wrote on 12/5/07 4:00 AM:
> 
> Interesting... I am wondering if radical changes tothe the transfer function
> would cause discontinuities inthe output signal. Never thought of the
> question. I'll love to try them. Coincidentally, I was only
> yesterdayteaching
> a class on waveshaping.

>> Victor.Lazzarini@nuim.ie wrote on 12/5/07 2:54 AM:
>> 
>>> PD seem useful. UDOs are also good because they're didactical, can you
>>> do both?
>> 
>> Thanks.  I wrote the phase dist. opcodes (and powershape below) a while ago
>> but I will make UDOs too.
>> 
>>> How do the waveshaping opcodes you mention
>>> differ from simply building them with oscillator and table
>>> lookup?
>> 
>> They allow for _dynamic_ waveshaping where the transfer function varies over
>> time.  I have written the following opcodes so far and hope to come up with
>> some more:
>> 
>> aout  powershape    ain, kShapeAmount [, ifullscale]
>> aout  polynomial    ain, ka0 [, ka1 [, ka2 [...]]]
>> aout  chebyshevpoly ain, ka0 [, ka1 [, ka2 [...]]]


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

They sound like they will be great and I think that they will ALL be  
very very useful.
Can't wait to hear them - in all their aliased glory.  The CZ101  
lives on!!!  Yeah.

-dB


On Dec 5, 2007, at 2:40 PM, Anthony Kozar wrote:

> Well, if my intuitions are correct, using continuous k-rate  
> coefficients
> with either the polynomial or chebyshevpoly opcodes should produce  
> smooth
> and continuous changes in the output.  I have tested the latter by
> controlling several harmonics independently and I got smooth  
> changes just as
> if I had used additive synthesis with multiple oscillators.  I  
> would be
> interested to know if there is some mathematical problem that I am
> overlooking.
>
> Regarding the phase distortion opcodes:  the reason I was  
> questioning their
> utility is that they DO produce aliasing because the derivative of the
> resulting signal is discontinuous.  I think -- but am not sure -- that
> Casio's original implementation of this technique was not 100%  
> digital.  But
> depending on the genre of music, aliasing is not always a bad thing :)
>
> Another use for the PD opcodes is to use them on audio signals  
> instead of
> phasors, in which case they behave as piecewise-linear transfer  
> functions.
> This also produces aliasing, but they have definite applications as
> alternative distortion techniques.  powershape is also excellent for
> distortion, although it can produce milder, bandlimited changes too.
>
> At least this is my understanding of everything -- I am not a DSP  
> guru ...
>
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> http://anthonykozar.net/
>
>
>> Victor.Lazzarini@nuim.ie wrote on 12/5/07 4:00 AM:
>>
>> Interesting... I am wondering if radical changes tothe the  
>> transfer function
>> would cause discontinuities inthe output signal. Never thought of the
>> question. I'll love to try them. Coincidentally, I was only
>> yesterdayteaching
>> a class on waveshaping.
>
>>> Victor.Lazzarini@nuim.ie wrote on 12/5/07 2:54 AM:
>>>
>>>> PD seem useful. UDOs are also good because they're didactical,  
>>>> can you
>>>> do both?
>>>
>>> Thanks.  I wrote the phase dist. opcodes (and powershape below) a  
>>> while ago
>>> but I will make UDOs too.
>>>
>>>> How do the waveshaping opcodes you mention
>>>> differ from simply building them with oscillator and table
>>>> lookup?
>>>
>>> They allow for _dynamic_ waveshaping where the transfer function  
>>> varies over
>>> time.  I have written the following opcodes so far and hope to  
>>> come up with
>>> some more:
>>>
>>> aout  powershape    ain, kShapeAmount [, ifullscale]
>>> aout  polynomial    ain, ka0 [, ka1 [, ka2 [...]]]
>>> aout  chebyshevpoly ain, ka0 [, ka1 [, ka2 [...]]]
>
>
> ---------------------------------------------------------------------- 
> ---
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

even i must admit that i'd be tempted to play with both these casio &
waveshaping opcodes desribed in this thread if & when i get back to looking
into some more oscillator type synthesis at some point in the future.

i want to develop some percussion syntax for my python environ eventually,
so that might be the invitation to explore some of the "old school"
synthesis capabilities of csound.

i used to like a lot of beats & stuff back a few years ago anyway. Dub & 2
step & house & stuff. I can see the casio sitting very nicely in some of
that....

& dynamic waveshaping was another area i explored unsucessfully in Max a few
years ago. I don't have my head fully around the details of the
implementation or discussion here, but thought i may as well add my possibly
unexpected voice of support for both the opcodes & the pedagogic / hackable
UDO versions



-- 
View this message in context: http://www.nabble.com/New-opcodes-useful--tf4947099.html#a14182494
Sent from the Csound - Dev mailing list archive at Nabble.com.


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Steven Yi wrote on 12/5/07 6:28 PM:

> Hmm... what I'm finding is that the PD is sort of like waveshaping but
> for the phasor and not the audio signal (phase shaping is what I'm
> calling it in this instrument I have here).  Thus, what Anthony is
> going for is actually different from the CZ101 if I understand the
> instrument correctly.

PD is exactly waveshaping for the phasor in my understanding too which is
why I am lumping these opcodes with the waveshaping ones.  (BTW, I like
"phaseshaping" :)  What might be confusing the issue right now is that my
initial implementations of the PD opcodes expect bipolar signals.  I plan to
change that before they become public to be unipolar with an option for
bipolar behavior.

The pdhalf opcode is supposed to exactly mimic the CZ-series PD "pattern"
that changes a sine wave into a sawtooth approximation.  The other two
opcodes, pdclip and pdhalfy, represent my own variations on the technique.

> andx    phasor kpchline
> andx    table3    andx, giphaseshape_, 1
> aout    table3  andx, gi_sine, 1

This is how I currently use pdhalf -- it basically takes the place of your
first phaseshaping table lookup and has a k-rate parameter to control the
shape of the transfer function:

  aosc  phasor  ifreq
  apd   pdhalf  2*aosc - 1.0, kamount   ; convert aosc to bipolar
  aout  tablei  0.5*(apd+1.0), 1, 1     ; convert apd back to unipolar
  
Once they are unipolar by default, you will be able to just do this:

  aosc  phasor  ifreq
  apd   pdhalf  aosc, kamount
  aout  tablei  apd, 1, 1

> The phase-shape table then has boundaries of 0-1, to correspond with
> the phase.  This would be different than what I think Anthony is
> building which I believe is more akin to waveshaping than phase
> distortion.
> 
> Can anyone confirm this?

My intention is to create opcodes that only do the phase manipulation part
of the technique (which makes them simple transfer functions).  So, you
still have to use a phasor and a table opcode.  The advantage of this is
obvious:  you can use the opcodes to modify other types of signals or as
inputs to other processes.  In particular, because of the similarity to
waveshaping, I think these opcodes could be used to shape audio signals
instead of phasors.  That is why I want the bipolar operation too.

(btw, I am open to other names for these opcodes).

Steven Yi wrote on 12/5/07 3:15 PM:

> I did find this wikipedia article just now:
> 
> http://en.wikipedia.org/wiki/Phase_distortion_synthesis

Thanks so much, Steven, for all of those good reference links.  The
Wikipedia article in particular mentioned some details that I had forgotten
(or never before understood).  In particular, I had forgotten that there
must be different "phase distortion patterns" to obtain some of the other
waveforms that the CZ offered.  Currently, my opcode pdhalf only implements
the first of the CZ's patterns and the other opcodes do not duplicate any of
the others.  It looks like I may have to write some more opcodes!  (or
provide options to choose between the patterns :)

The difficulty is that I have only seen patterns for the first two
waveforms: sawtooth and square.  I may have to try and infer the others from
the waveform shapes.

The other thing I never really understood was the resonance waveforms.
According to Wikipedia, these are actually created using an oscillator sync
technique.  So there were several things going on in the CZ's: PD, Osc Sync,
and waveform sequencing.  Some of the web sites you mentioned lump all of
these under "phase distortion" but it seems clear to me that it is a
blending of three very different synthesis techniques.  (Incidently, I have
written some naive hard sync opcodes and I have been thinking of writing a
waveform sequencing opcode too).

Victor.Lazzarini@nuim.ie wrote on 12/5/07 2:54 PM:

> Do you know if there is any references on PD in the
> literature. Apart from the simple descriptions on Casio
> manuals, I never saw anything else.

> yes, the PD technique as I understand it does not seem
> to be bandlimited. But I wonder if there are any tricks
> that are not documented anywhere.

No, I am not aware of any other references (the ones Steven found were new
to me).  My information came from a CZ-3000 manual many years ago.  When I
created the pdhalf opcode, I was working from memory and from some notes I
made from that manual.

> Also do you know how to produce the resonant version
> of PD? That was an interesting sound.

I did not remember this before -- I may need more information about how it
worked before I can really duplicate this effect.

> Interesting to see the classic topic of waveshaping being
> discussed, as well. In these days of fast computers, people
> seemed to forget about these great ways of economically
> synthesising complex spectra.

I have always been attracted to the direct synthesis methods.  My father's
first synthesizer -- the first that I ever had the oppotunity to experiment
with -- was a Casio CZ-3000.  He later got a Korg 01/W that had about 60
choices for waveshaping tables (many of them not Chebyshev-based) that could
be applied to samples, not just sine waves.

The biggest frustration for me with these machines was that their manuals
did not fully explain all of the synthesis options that they provided!  I do
not remember the CZ manual explaining beyond the simple sine-to-saw example
and the Korg manual only provided graphs for about 3 out of the 60 tables.
So, you had to guess at what they would do based on fanciful names like
"Zipper" and "Rezzy 3".  (These are illustrative and may not have been
actual names).

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://anthonykozar.net/


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Steven Yi wrote on 12/6/07 1:36 AM:

> (I've attached the
> latest version if anyone is interested to render and hear how it's
> coming along. =) )

Thanks Steven!  Looking forward to trying this out.

> I was wondering though that from the experience of doing this now
> without *that* much Csound code, I am wondering what advantages are
> there to having it as a C opcode library versus a UDO?

Well, that is one of the reasons that I was questioning it ...

Anthony


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Steven,


Really wonderful instrument and musical demo.   So happy you are  
working in this area.
It was a fantastic instrument in its day.  I had 2 of them and loved  
them.  In fact, I hope to
buy one again on eBay.  Excellent for teaching!!!!  Thanks Anthony  
too - for bringing this
into focus for us all.

-dB

On Dec 6, 2007, at 1:36 AM, Steven Yi wrote:

> My head is still buzzing about all this, very interesting sounds!  I
> spent a couple hours tonight together with the CZ101 manual and
> continued to take the instrument from earlier further on, implementing
> a lot of the CZ101 features.  I've got most of the signal routing
> established, now have left to work on the filter key follow that
> adjusts amount of phaseshaping to do depending on frequency, but am
> getting close.  It's not going to be a CZ101 clone as there's some
> things I'm not interested to mimic like the 8 stage envelope, but a
> lot of the sound quality is there and very similar features which
> should make this very useful.  If anything, I'm enjoying the sounds
> very much!  I'll send a message out to the main mailing list and blue
> list with copies of the instrument when complete. (I've attached the
> latest version if anyone is interested to render and hear how it's
> coming along. =) )
>
> I was wondering though that from the experience of doing this now
> without *that* much Csound code, I am wondering what advantages are
> there to having it as a C opcode library versus a UDO?
>
> steven
>
> On Dec 5, 2007 5:22 PM, Anthony Kozar   
> wrote:
>> Steven Yi wrote on 12/5/07 6:28 PM:
>>
>>> Hmm... what I'm finding is that the PD is sort of like  
>>> waveshaping but
>>> for the phasor and not the audio signal (phase shaping is what I'm
>>> calling it in this instrument I have here).  Thus, what Anthony is
>>> going for is actually different from the CZ101 if I understand the
>>> instrument correctly.
>>
>> PD is exactly waveshaping for the phasor in my understanding too  
>> which is
>> why I am lumping these opcodes with the waveshaping ones.  (BTW, I  
>> like
>> "phaseshaping" :)  What might be confusing the issue right now is  
>> that my
>> initial implementations of the PD opcodes expect bipolar signals.   
>> I plan to
>> change that before they become public to be unipolar with an  
>> option for
>> bipolar behavior.
>>
>> The pdhalf opcode is supposed to exactly mimic the CZ-series PD  
>> "pattern"
>> that changes a sine wave into a sawtooth approximation.  The other  
>> two
>> opcodes, pdclip and pdhalfy, represent my own variations on the  
>> technique.
>>
>>> andx    phasor kpchline
>>> andx    table3    andx, giphaseshape_, 1
>>> aout    table3  andx, gi_sine, 1
>>
>> This is how I currently use pdhalf -- it basically takes the place  
>> of your
>> first phaseshaping table lookup and has a k-rate parameter to  
>> control the
>> shape of the transfer function:
>>
>>   aosc  phasor  ifreq
>>   apd   pdhalf  2*aosc - 1.0, kamount   ; convert aosc to bipolar
>>   aout  tablei  0.5*(apd+1.0), 1, 1     ; convert apd back to  
>> unipolar
>>
>> Once they are unipolar by default, you will be able to just do this:
>>
>>   aosc  phasor  ifreq
>>   apd   pdhalf  aosc, kamount
>>   aout  tablei  apd, 1, 1
>>
>>> The phase-shape table then has boundaries of 0-1, to correspond with
>>> the phase.  This would be different than what I think Anthony is
>>> building which I believe is more akin to waveshaping than phase
>>> distortion.
>>>
>>> Can anyone confirm this?
>>
>> My intention is to create opcodes that only do the phase  
>> manipulation part
>> of the technique (which makes them simple transfer functions).   
>> So, you
>> still have to use a phasor and a table opcode.  The advantage of  
>> this is
>> obvious:  you can use the opcodes to modify other types of signals  
>> or as
>> inputs to other processes.  In particular, because of the  
>> similarity to
>> waveshaping, I think these opcodes could be used to shape audio  
>> signals
>> instead of phasors.  That is why I want the bipolar operation too.
>>
>> (btw, I am open to other names for these opcodes).
>>
>> Steven Yi wrote on 12/5/07 3:15 PM:
>>
>>> I did find this wikipedia article just now:
>>>
>>> http://en.wikipedia.org/wiki/Phase_distortion_synthesis
>>
>> Thanks so much, Steven, for all of those good reference links.  The
>> Wikipedia article in particular mentioned some details that I had  
>> forgotten
>> (or never before understood).  In particular, I had forgotten that  
>> there
>> must be different "phase distortion patterns" to obtain some of  
>> the other
>> waveforms that the CZ offered.  Currently, my opcode pdhalf only  
>> implements
>> the first of the CZ's patterns and the other opcodes do not  
>> duplicate any of
>> the others.  It looks like I may have to write some more opcodes!   
>> (or
>> provide options to choose between the patterns :)
>>
>> The difficulty is that I have only seen patterns for the first two
>> waveforms: sawtooth and square.  I may have to try and infer the  
>> others from
>> the waveform shapes.
>>
>> The other thing I never really understood was the resonance  
>> waveforms.
>> According to Wikipedia, these are actually created using an  
>> oscillator sync
>> technique.  So there were several things going on in the CZ's: PD,  
>> Osc Sync,
>> and waveform sequencing.  Some of the web sites you mentioned lump  
>> all of
>> these under "phase distortion" but it seems clear to me that it is a
>> blending of three very different synthesis techniques.   
>> (Incidently, I have
>> written some naive hard sync opcodes and I have been thinking of  
>> writing a
>> waveform sequencing opcode too).
>>
>> Victor.Lazzarini@nuim.ie wrote on 12/5/07 2:54 PM:
>>
>>> Do you know if there is any references on PD in the
>>> literature. Apart from the simple descriptions on Casio
>>> manuals, I never saw anything else.
>>
>>> yes, the PD technique as I understand it does not seem
>>> to be bandlimited. But I wonder if there are any tricks
>>> that are not documented anywhere.
>>
>> No, I am not aware of any other references (the ones Steven found  
>> were new
>> to me).  My information came from a CZ-3000 manual many years  
>> ago.  When I
>> created the pdhalf opcode, I was working from memory and from some  
>> notes I
>> made from that manual.
>>
>>> Also do you know how to produce the resonant version
>>> of PD? That was an interesting sound.
>>
>> I did not remember this before -- I may need more information  
>> about how it
>> worked before I can really duplicate this effect.
>>
>>> Interesting to see the classic topic of waveshaping being
>>> discussed, as well. In these days of fast computers, people
>>> seemed to forget about these great ways of economically
>>> synthesising complex spectra.
>>
>> I have always been attracted to the direct synthesis methods.  My  
>> father's
>> first synthesizer -- the first that I ever had the oppotunity to  
>> experiment
>> with -- was a Casio CZ-3000.  He later got a Korg 01/W that had  
>> about 60
>> choices for waveshaping tables (many of them not Chebyshev-based)  
>> that could
>> be applied to samples, not just sine waves.
>>
>> The biggest frustration for me with these machines was that their  
>> manuals
>> did not fully explain all of the synthesis options that they  
>> provided!  I do
>> not remember the CZ manual explaining beyond the simple sine-to- 
>> saw example
>> and the Korg manual only provided graphs for about 3 out of the 60  
>> tables.
>> So, you had to guess at what they would do based on fanciful names  
>> like
>> "Zipper" and "Rezzy 3".  (These are illustrative and may not have  
>> been
>> actual names).
>>
>> Anthony Kozar
>> anthonykozar AT sbcglobal DOT net
>> http://anthonykozar.net/
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>>
>> SF.Net email is sponsored by: The Future of Linux Business White  
>> Paper
>> from Novell.  From the desktop to the data center, Linux is going
>> mainstream.  Let it simplify your IT future.
>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> 
> ---------------------------------------------------------------------- 
> ---
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/ 
> 8857-50307-18918-4_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Dr. Richard Boulanger wrote:

re: CZ101
> Really wonderful instrument and musical demo.   So happy you are  
> working in this area.
> It was a fantastic instrument in its day.  I had 2 of them and loved  
> them.  In fact, I hope to
> buy one again on eBay.  Excellent for teaching!!!!
I have one sitting here beside me, I use it to test various synth 
patches but never use it for its own sounds anymore.

Sigh... I have four hardware synths here, and I haven't used any of them 
for years.

Best,

dp


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net