Hello list, 

    After reading the documentation, learning about some new opcodes, and looking at several example files, I'm still stumped. I have an instrument that uses if/then/elseif statements based on incoming OSC messages to navigate through different code blocks. As you would expect, depending on the OSC messages and timing, there are sometimes pops when it switches from one signal processing routine in the instrument to another. (The sample code below does one of two processes, or silence.)

    

     What is the best way to envelope/fade the beginnings and endings of the audio produced by different code blocks so that there are no glitches when it comes and goes based on the OSC messages? Usually we know how long an event will be (even relatively) and envelope accordingly. With these OSC messages triggering the processes' coming and going..what to do?

Best, 

~L.

<CsoundSynthesizer>

<CsOptions>

</CsOptions>

<CsInstruments>

sr = 44100

ksmps = 100 ;samps / k-period

nchnls = 1

0dbfs = 1

gihandle OSCinit 7770

instr 1

kf1 init 0

kf2 init 0

kf3 init 0

kf4 init 0

kf5 init 0

kf6 init 0

kf7 init 0

kf8 init 0

kCount init 0

konoff init 0

ksim init 0

ibasefreq = p4

iscale = p5

isimscale = p6

ifn = p7

idelbase = p8

icarifn = p9

imodfreq = p10

imodamp = p11

imod_ifn = p12

kpulse_env_amp = p13

ipulse_shape = p14

ilowpulse = p15

ihighpulse = p16

isimthresh = p17

kk OSClisten gihandle, "/eeg", "iiiiiiiii", kCount, kf1, kf2, kf3, kf4, kf5, kf6, kf7, kf8

kk OSClisten gihandle, "/onoff", "i", konoff

kk OSClisten gihandle, "/similarity", "f", ksim

printks "%i %i %i %i %i %i %i %i %i\\n", 0, kCount, kf1, kf2, kf3, kf4, kf5, kf6, kf7, kf8

printks "toggle is %i\\n", 0, konoff

printks "similarity is %f\\n", 0, ksim

if (konoff == 0) then

kgoto noamp

elseif (ksim >= isimthresh ) && (konoff == 1) then

kgoto similarity ; goto similarity and PULSE

elseif (ksim < isimthresh) && (konoff == 1) then

kgoto yesamp

endif

yesamp:

;USING DATA FOR AMPLITUDE

;currentkf / maxkf

asig0 oscili .1 , ibasefreq, 1

asig1 oscili (kf1 / 18000000) * iscale, ibasefreq, ifn

asig2 oscili (kf2 / 18000000) * iscale, ibasefreq * 2, ifn

asig3 oscili (kf3 / 18000000) * iscale, ibasefreq * 3, ifn

asig4 oscili (kf4 / 18000000) * iscale, ibasefreq * 4, ifn

asig5 oscili (kf5 / 18000000) * iscale, ibasefreq * 5, ifn

asig6 oscili (kf6 / 18000000) * iscale, ibasefreq * 6, ifn

asig7 oscili (kf7 / 18000000) * iscale, ibasefreq * 7, ifn

asig8 oscili (kf8 / 18000000) * iscale, ibasefreq * 8, ifn

aoutsig = asig0 + asig1 + asig2 + asig3 + asig4 + asig5 + asig6 + asig7 + asig8

aoutsig = aoutsig * iscale

acomp oscili 1, 400, 1

abal balance aoutsig, acomp

afiltsig2 butlp abal, 1000

afiltsig butlp afiltsig2, 1000

adelay1 delay afiltsig, idelbase

adelay2 delay afiltsig, idelbase * .2

adelay3 delay afiltsig, idelbase * .3

adelay4 delay afiltsig, idelbase * .4

adelay5 delay afiltsig, idelbase * .5

adelay6 delay afiltsig, idelbase * .6

adelay7 delay afiltsig, idelbase * .7

adelay8 delay afiltsig, idelbase * .8

adelays = adelay1 + adelay2 + adelay3 + adelay4 + adelay5 + adelay6 + adelay7 + adelay8

abal2 balance adelays, acomp

aout = abal2

kgoto output

similarity:

kpulse_freq scale ksim, ihighpulse, ilowpulse

kpulse_env oscili kpulse_env_amp, kpulse_freq, ipulse_shape

amod oscili imodamp, imodfreq, imod_ifn

amod2 = amod * kpulse_env

acar oscili isimscale * kpulse_env, ibasefreq + amod2, icarifn

aout = acar

kgoto output

output:

out aout

noamp:

endin

</CsInstruments>

<CsScore>

;f1 0 16384 10 1 0 1 .8 .6 .3 .1

;f1 0 16384 10 1 0 .6 0 .1

f1 0 16384 10 1

f2 0 16384 10 1 0 1 0 .5 0 .2

f4 0 16384 10 1 0 1

f3 0 1024 9 0.5 1 0 ; half sine

f5 0 1025 7 0.01 150 .5 100 1 230 1 100 .4 445 0.01 ;exponential shark fin

f6 0 1025 5 .01 1025 .01

f7 0 1025 5 .01 200 .5 100 1 300 1 212 .5 200 .3 313 .01 ;throb

; freq amp simamp ifn idel carifn modfreq modamp modifn pulseNVamp pulseshape minpulse pulsehigh simthr

; p4 5 6 7 8 9 10 11 12 13 14 15 16 17

i1 0 3000 146.83 .015 1 1 .8 1 97.8 25 1 1 5 .8 1.5 .6

i1 0.153 3000 146.83 .015 1 1 .68 1 97.8 25 1 1 5 .8 1.5 .6

</CsScore>

</CsoundSynthesizer>

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Jul 20 2017, Linda Antas has written:
...
>     What is the best way to envelope/fade the beginnings and endings of
> the audio produced by different code blocks so that there are no glitches
> when it comes and goes based on the OSC messages?
Hey Linda,
have you considered using port or portk lowpass filters on an amplitude
modifier. A lowpass filter on a control signal smoothes its values:
kenv port korig_env, 2 ; 2seconds halftime
aout oscil 1*kenv, kfreq, itable
Now you can change korig_env and kenv will be a smoothed out version.

HTH Good luck!
...

Best wishes,

Jeanette

--------
* website: http://juliencoder.de - for summer is a state of sound
* SoundCloud: https://soundcloud.com/jeanette_c

All you people look at me like I'm a little girl.
Well did you ever think it be okay for me to step into this world. <3
(Britney Spears)

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I think port would work well for the way this instrument is designed,
but you might have to consider whether you should also have all of the
signal processing paths "always on" so that the parts that are fading
out keep producing sound while it fades (or the same for the part
fading in).  Or, you could maybe use fades but add an additional if-
check to see if an envelope value is 0 and, if so, skip over a block
of processing, something like:

if (konoff == 1) then

  kenv = port( (ksim >= isimthresh ) ? 1 : 0,  0.05)
  kenv2 = 1 - kenv

  if(kenv != 0) then
    ... do yesamp...
  endif

  if(kenv2 != 0) then
    ... do similarity ...
  endif
endif


An alternative is to separate the signal paths into separate
instruments and have instr 1 function as a kind of control instrument.
It could then turn on and off each sub instrument using
event/turnoff2. The instrument could be written using an envelope
generator that supports release segments (i.e. madsr, transegr, etc.).
You could set the attack and release times to be the same. For
example, if you had instr 2 have the "yesamp" code, and instr 3 have
the "similarity" code, your control instrument could turn off instance
of instr 2 and start a new instr 3, and they would cross fade
according to the attack/release times.  The advantage of going this
route is that when a "path" fades out it gets removed from processing,
freeing up CPU, and makes things a little more modular.  (For example,
you could design the control instrument to work with a variable number
of different sub instruments and add new instruments over time.)



On Thu, Jul 20, 2017 at 4:35 PM, Jeanette C.  wrote:
> Jul 20 2017, Linda Antas has written:
> ...
>>
>>     What is the best way to envelope/fade the beginnings and endings of
>> the audio produced by different code blocks so that there are no glitches
>> when it comes and goes based on the OSC messages?
>
> Hey Linda,
> have you considered using port or portk lowpass filters on an amplitude
> modifier. A lowpass filter on a control signal smoothes its values:
> kenv port korig_env, 2 ; 2seconds halftime
> aout oscil 1*kenv, kfreq, itable
> Now you can change korig_env and kenv will be a smoothed out version.
>
> HTH Good luck!
> ...
>
> Best wishes,
>
> Jeanette
>
> --------
> * website: http://juliencoder.de - for summer is a state of sound
> * SoundCloud: https://soundcloud.com/jeanette_c
>
> All you people look at me like I'm a little girl.
> Well did you ever think it be okay for me to step into this world. <3
> (Britney Spears)
>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Glad to be useful! :)  And best wishes for the installation!

On Thu, Jul 20, 2017 at 6:03 PM, Linda Antas  wrote:
> Yes, Steven! I appreciate your attention to "signal processing paths 'always
> on' " and the rest. This code (times several units) will be running on Pi
> 3's for days* as part of an installation, and efficiency is important for
> stability.
>
> *well, they'll be put to sleep at the end of each day...
>
> Thanks again, all
>
> On Thu, Jul 20, 2017 at 3:54 PM, Steven Yi  wrote:
>>
>> I think port would work well for the way this instrument is designed,
>> but you might have to consider whether you should also have all of the
>> signal processing paths "always on" so that the parts that are fading
>> out keep producing sound while it fades (or the same for the part
>> fading in).  Or, you could maybe use fades but add an additional if-
>> check to see if an envelope value is 0 and, if so, skip over a block
>> of processing, something like:
>>
>> if (konoff == 1) then
>>
>>   kenv = port( (ksim >= isimthresh ) ? 1 : 0,  0.05)
>>   kenv2 = 1 - kenv
>>
>>   if(kenv != 0) then
>>     ... do yesamp...
>>   endif
>>
>>   if(kenv2 != 0) then
>>     ... do similarity ...
>>   endif
>> endif
>>
>>
>> An alternative is to separate the signal paths into separate
>> instruments and have instr 1 function as a kind of control instrument.
>> It could then turn on and off each sub instrument using
>> event/turnoff2. The instrument could be written using an envelope
>> generator that supports release segments (i.e. madsr, transegr, etc.).
>> You could set the attack and release times to be the same. For
>> example, if you had instr 2 have the "yesamp" code, and instr 3 have
>> the "similarity" code, your control instrument could turn off instance
>> of instr 2 and start a new instr 3, and they would cross fade
>> according to the attack/release times.  The advantage of going this
>> route is that when a "path" fades out it gets removed from processing,
>> freeing up CPU, and makes things a little more modular.  (For example,
>> you could design the control instrument to work with a variable number
>> of different sub instruments and add new instruments over time.)
>>
>>
>>
>> On Thu, Jul 20, 2017 at 4:35 PM, Jeanette C.  wrote:
>> > Jul 20 2017, Linda Antas has written:
>> > ...
>> >>
>> >>     What is the best way to envelope/fade the beginnings and endings of
>> >> the audio produced by different code blocks so that there are no
>> >> glitches
>> >> when it comes and goes based on the OSC messages?
>> >
>> > Hey Linda,
>> > have you considered using port or portk lowpass filters on an amplitude
>> > modifier. A lowpass filter on a control signal smoothes its values:
>> > kenv port korig_env, 2 ; 2seconds halftime
>> > aout oscil 1*kenv, kfreq, itable
>> > Now you can change korig_env and kenv will be a smoothed out version.
>> >
>> > HTH Good luck!
>> > ...
>> >
>> > Best wishes,
>> >
>> > Jeanette
>> >
>> > --------
>> > * website: http://juliencoder.de - for summer is a state of sound
>> > * SoundCloud: https://soundcloud.com/jeanette_c
>> >
>> > All you people look at me like I'm a little girl.
>> > Well did you ever think it be okay for me to step into this world. <3
>> > (Britney Spears)
>> >
>> >
>> > Csound mailing list
>> > Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> > Send bugs reports to
>> >        https://github.com/csound/csound/issues
>> > Discussions of bugs and features can be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi All,

Just to follow up, I was discussing with Linda off-list and came up
with an example CSD that demonstrates the separate instruments
solution proposed earlier in this thread.  I've attached a CSD as well
as a TouchOSC interface file in case it is of use to anyone.

All best!
steven


On Thu, Jul 20, 2017 at 6:06 PM, Steven Yi  wrote:
> Glad to be useful! :)  And best wishes for the installation!
>
> On Thu, Jul 20, 2017 at 6:03 PM, Linda Antas  wrote:
>> Yes, Steven! I appreciate your attention to "signal processing paths 'always
>> on' " and the rest. This code (times several units) will be running on Pi
>> 3's for days* as part of an installation, and efficiency is important for
>> stability.
>>
>> *well, they'll be put to sleep at the end of each day...
>>
>> Thanks again, all
>>
>> On Thu, Jul 20, 2017 at 3:54 PM, Steven Yi  wrote:
>>>
>>> I think port would work well for the way this instrument is designed,
>>> but you might have to consider whether you should also have all of the
>>> signal processing paths "always on" so that the parts that are fading
>>> out keep producing sound while it fades (or the same for the part
>>> fading in).  Or, you could maybe use fades but add an additional if-
>>> check to see if an envelope value is 0 and, if so, skip over a block
>>> of processing, something like:
>>>
>>> if (konoff == 1) then
>>>
>>>   kenv = port( (ksim >= isimthresh ) ? 1 : 0,  0.05)
>>>   kenv2 = 1 - kenv
>>>
>>>   if(kenv != 0) then
>>>     ... do yesamp...
>>>   endif
>>>
>>>   if(kenv2 != 0) then
>>>     ... do similarity ...
>>>   endif
>>> endif
>>>
>>>
>>> An alternative is to separate the signal paths into separate
>>> instruments and have instr 1 function as a kind of control instrument.
>>> It could then turn on and off each sub instrument using
>>> event/turnoff2. The instrument could be written using an envelope
>>> generator that supports release segments (i.e. madsr, transegr, etc.).
>>> You could set the attack and release times to be the same. For
>>> example, if you had instr 2 have the "yesamp" code, and instr 3 have
>>> the "similarity" code, your control instrument could turn off instance
>>> of instr 2 and start a new instr 3, and they would cross fade
>>> according to the attack/release times.  The advantage of going this
>>> route is that when a "path" fades out it gets removed from processing,
>>> freeing up CPU, and makes things a little more modular.  (For example,
>>> you could design the control instrument to work with a variable number
>>> of different sub instruments and add new instruments over time.)
>>>
>>>
>>>
>>> On Thu, Jul 20, 2017 at 4:35 PM, Jeanette C.  wrote:
>>> > Jul 20 2017, Linda Antas has written:
>>> > ...
>>> >>
>>> >>     What is the best way to envelope/fade the beginnings and endings of
>>> >> the audio produced by different code blocks so that there are no
>>> >> glitches
>>> >> when it comes and goes based on the OSC messages?
>>> >
>>> > Hey Linda,
>>> > have you considered using port or portk lowpass filters on an amplitude
>>> > modifier. A lowpass filter on a control signal smoothes its values:
>>> > kenv port korig_env, 2 ; 2seconds halftime
>>> > aout oscil 1*kenv, kfreq, itable
>>> > Now you can change korig_env and kenv will be a smoothed out version.
>>> >
>>> > HTH Good luck!
>>> > ...
>>> >
>>> > Best wishes,
>>> >
>>> > Jeanette
>>> >
>>> > --------
>>> > * website: http://juliencoder.de - for summer is a state of sound
>>> > * SoundCloud: https://soundcloud.com/jeanette_c
>>> >
>>> > All you people look at me like I'm a little girl.
>>> > Well did you ever think it be okay for me to step into this world. <3
>>> > (Britney Spears)
>>> >
>>> >
>>> > Csound mailing list
>>> > Csound@listserv.heanet.ie
>>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> > Send bugs reports to
>>> >        https://github.com/csound/csound/issues
>>> > Discussions of bugs and features can be posted here
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here