Quantcast

Ndef question

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Ndef question

Iain Mott-2
Hello again,

I'm trying to learn how to use Ndefs and parameter mapping. I'm running
into trouble when using parameter modifiers that have envelopes/line
generators which are triggered on creation. From what I can see, these
parameter modifiers need to be declared at the time of mapping so that
the line generators are triggered at that very moment. This however,
seems to cause timing errors and other glitches in the sound.
For example, this first block of code creates a simple pulse:

(
Ndef(\tel,
     {
         arg freq = 200, pan = -1, rate = 3;
         var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
             SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
                 LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
         Pan2.ar(snd, pan);
     };
);
Ndef(\tel).play;
)

If I then modify the Ndef with the following block of code, at best --
on my machine at least -- there is a slight pause in the pulsing sound
before the modifiers take effect. Sometimes however, other more
unpleasant audio glitches occur:

(
Ndef(\rateramp, { XLine.kr(3, 164, 30) });
Ndef(\freqramp, { RunningMax.kr(200 + (Stepper.kr(Impulse.kr(XLine.kr(3,
164, 30)), 1, 0, 1000, 1, 0) * 2)) });
Ndef(\panmod, { PulseCount.kr(Impulse.kr(XLine.kr(3, 164, 30)))%2*2-1  });


Ndef(\tel).map(\rate, Ndef(\rateramp));
Ndef(\tel).map(\freq, Ndef(\freqramp));
Ndef(\tel).map(\pan, Ndef(\panmod));
)

If I remove the 1st 3 lines of this last block and place them at the end
of the first block, no timing glitches occur. But the problem there is
that the line generators have already been triggered in the 1st block -
ie. the horse has already bolted and they don't provide the intended
adjustments to the sound.

I did try using "rebuild" on the parameter modifiers in the second block
but this has exactly the same effect as defining them there.

What can I do here to avoid the problem? Is it necessary to somehow
retrigger the line generators?

Thanks,

Iain



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

gilFuser
Hi Iain.

I tried here and got no glitches and pauses.

If you want to retrigger the modifiers by hand you can do something like this: Ndef(\rateramp).send.

Maybe if you put the the Ndef(\tel).map(... before the modifiers you can prevent them to have been triggered before they are attached to the arguments of Ndef(\tel).

I would also use ).set( instead of ).map(. I heard that .map is deprecated. And you don't have to have them in the same block as the modifier Ndefs. You only map or set once and you have it.

bests,
Gil

Iain Mott <[hidden email]> schrieb am Fr., 10. Feb. 2017 um 20:44 Uhr:
Hello again,

I'm trying to learn how to use Ndefs and parameter mapping. I'm running
into trouble when using parameter modifiers that have envelopes/line
generators which are triggered on creation. From what I can see, these
parameter modifiers need to be declared at the time of mapping so that
the line generators are triggered at that very moment. This however,
seems to cause timing errors and other glitches in the sound.
For example, this first block of code creates a simple pulse:

(
Ndef(\tel,
     {
         arg freq = 200, pan = -1, rate = 3;
         var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
             SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
                 LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
         Pan2.ar(snd, pan);
     };
);
Ndef(\tel).play;
)

If I then modify the Ndef with the following block of code, at best --
on my machine at least -- there is a slight pause in the pulsing sound
before the modifiers take effect. Sometimes however, other more
unpleasant audio glitches occur:

(
Ndef(\rateramp, { XLine.kr(3, 164, 30) });
Ndef(\freqramp, { RunningMax.kr(200 + (Stepper.kr(Impulse.kr(XLine.kr(3,
164, 30)), 1, 0, 1000, 1, 0) * 2)) });
Ndef(\panmod, { PulseCount.kr(Impulse.kr(XLine.kr(3, 164, 30)))%2*2-1  });


Ndef(\tel).map(\rate, Ndef(\rateramp));
Ndef(\tel).map(\freq, Ndef(\freqramp));
Ndef(\tel).map(\pan, Ndef(\panmod));
)

If I remove the 1st 3 lines of this last block and place them at the end
of the first block, no timing glitches occur. But the problem there is
that the line generators have already been triggered in the 1st block -
ie. the horse has already bolted and they don't provide the intended
adjustments to the sound.

I did try using "rebuild" on the parameter modifiers in the second block
but this has exactly the same effect as defining them there.

What can I do here to avoid the problem? Is it necessary to somehow
retrigger the line generators?

Thanks,

Iain



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

Iain Mott-2

Hi Gil,

Thanks. Using set now instead of map. Running the modifier declarations before setting them doesn't work as it interferes with the initial pulsing sound. Also, resetting the modifiers does remove the glitches but the result is that the modifiers are out of sync with the original pulse.

I wonder why my system is giving glitches are yours not. Could it be a Linux issue? I'm using Linux and SC 3.8.0. This machine is pretty fast and has lots of memory.

Just so it's clear in terms of sound, the effect I was trying to achieve in the code I sent in last email was to go from this steady pulse:

(
Ndef(\tel,
    {
        arg freq = 200, pan = -1, rate = 1;
        var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
            SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
                LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
        Pan2.ar(snd, pan);
    };
);
Ndef(\tel).play;
)

to this, seamlessly:

(
Ndef(\test,
   {
       var rate = XLine.kr(3, 164, 20);
        var trig= Impulse.kr(rate);
       var freq = RunningMax.kr(200 + (Stepper.kr(trig, 0, 0, 1000, 1) * 2));
         var pan= PulseCount.kr(trig)%2*2-1;
       var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
           SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
               LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
       Pan2.ar(snd, pan.poll);
   };
).play;
)

Is that what you heard?

All the best,

Iain




Em 10/02/2017 20:09, Gil Fuser escreveu:
Hi Iain.

I tried here and got no glitches and pauses.

If you want to retrigger the modifiers by hand you can do something like this: Ndef(\rateramp).send.

Maybe if you put the the Ndef(\tel).map(... before the modifiers you can prevent them to have been triggered before they are attached to the arguments of Ndef(\tel).

I would also use ).set( instead of ).map(. I heard that .map is deprecated. And you don't have to have them in the same block as the modifier Ndefs. You only map or set once and you have it.

bests,
Gil

Iain Mott <[hidden email]> schrieb am Fr., 10. Feb. 2017 um 20:44 Uhr:
Hello again,

I'm trying to learn how to use Ndefs and parameter mapping. I'm running
into trouble when using parameter modifiers that have envelopes/line
generators which are triggered on creation. From what I can see, these
parameter modifiers need to be declared at the time of mapping so that
the line generators are triggered at that very moment. This however,
seems to cause timing errors and other glitches in the sound.
For example, this first block of code creates a simple pulse:

(
Ndef(\tel,
     {
         arg freq = 200, pan = -1, rate = 3;
         var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
             SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
                 LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
         Pan2.ar(snd, pan);
     };
);
Ndef(\tel).play;
)

If I then modify the Ndef with the following block of code, at best --
on my machine at least -- there is a slight pause in the pulsing sound
before the modifiers take effect. Sometimes however, other more
unpleasant audio glitches occur:

(
Ndef(\rateramp, { XLine.kr(3, 164, 30) });
Ndef(\freqramp, { RunningMax.kr(200 + (Stepper.kr(Impulse.kr(XLine.kr(3,
164, 30)), 1, 0, 1000, 1, 0) * 2)) });
Ndef(\panmod, { PulseCount.kr(Impulse.kr(XLine.kr(3, 164, 30)))%2*2-1  });


Ndef(\tel).map(\rate, Ndef(\rateramp));
Ndef(\tel).map(\freq, Ndef(\freqramp));
Ndef(\tel).map(\pan, Ndef(\panmod));
)

If I remove the 1st 3 lines of this last block and place them at the end
of the first block, no timing glitches occur. But the problem there is
that the line generators have already been triggered in the 1st block -
ie. the horse has already bolted and they don't provide the intended
adjustments to the sound.

I did try using "rebuild" on the parameter modifiers in the second block
but this has exactly the same effect as defining them there.

What can I do here to avoid the problem? Is it necessary to somehow
retrigger the line generators?

Thanks,

Iain



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

-- 
_________
Iain Mott
http://escuta.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

Iain Mott-2

Hi List, I'm bumping this topic. Looking at it a week later I still don't know how to reset the parameters of the following ndef without causing various glitches and synch problems. Here is the basic ndef:

(
Ndef(\tel,
    {
        arg freq = 200, pan = 0, rate = 3;
        //var trig= Impulse.kr(rate);
          var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
            SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
                LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
        Pan2.ar(snd, pan);
    };
);
Ndef(\tel).play;
)

I then wish to make the pulse accelerate and pan alternatively hard-left and hard-right with each consecutive pulse:

(

Ndef(\rateramp, { XLine.kr(3, 164, 10) });
Ndef(\freqramp, { RunningMax.kr(200 + (Stepper.kr(Impulse.kr(XLine.kr(3, 164, 30)), 1, 0, 1000, 1, 0) * 2)) });
Ndef(\panmod, { PulseCount.kr(Impulse.kr(XLine.kr(3, 164, 30)))%2*2-1  });


Ndef(\tel).set(\freq, Ndef(\freqramp));
Ndef(\tel).set(\pan, Ndef(\panmod));
Ndef(\tel).set(\rate, Ndef(\rateramp));

)

This however on my system (Linux, SC 3.8), causes various audio glitches as I mentioned. Should it work and if so, why do you think it isn't? If not, what am I doing wrong?

The accelerating part of the sound should sound like this (and this by itself does work):

(
Ndef(\test,
   {
       var rate = XLine.kr(3, 164, 20);
       var trig= Impulse.kr(rate);
       var freq = RunningMax.kr(200 + (Stepper.kr(trig, 0, 0, 1000, 1) * 2));
       var pan= PulseCount.kr(trig)%2*2-1;
       var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
           SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
               LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
       Pan2.ar(snd, pan);
   };
).play;
)

Thanks a lot.

Iain








Em 11/02/2017 07:01, Iain Mott escreveu:

Hi Gil,

Thanks. Using set now instead of map. Running the modifier declarations before setting them doesn't work as it interferes with the initial pulsing sound. Also, resetting the modifiers does remove the glitches but the result is that the modifiers are out of sync with the original pulse.

I wonder why my system is giving glitches are yours not. Could it be a Linux issue? I'm using Linux and SC 3.8.0. This machine is pretty fast and has lots of memory.

Just so it's clear in terms of sound, the effect I was trying to achieve in the code I sent in last email was to go from this steady pulse:

(
Ndef(\tel,
    {
        arg freq = 200, pan = -1, rate = 1;
        var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
            SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
                LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
        Pan2.ar(snd, pan);
    };
);
Ndef(\tel).play;
)

to this, seamlessly:

(
Ndef(\test,
   {
       var rate = XLine.kr(3, 164, 20);
        var trig= Impulse.kr(rate);
       var freq = RunningMax.kr(200 + (Stepper.kr(trig, 0, 0, 1000, 1) * 2));
         var pan= PulseCount.kr(trig)%2*2-1;
       var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
           SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
               LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
       Pan2.ar(snd, pan.poll);
   };
).play;
)

Is that what you heard?

All the best,

Iain




Em 10/02/2017 20:09, Gil Fuser escreveu:
Hi Iain.

I tried here and got no glitches and pauses.

If you want to retrigger the modifiers by hand you can do something like this: Ndef(\rateramp).send.

Maybe if you put the the Ndef(\tel).map(... before the modifiers you can prevent them to have been triggered before they are attached to the arguments of Ndef(\tel).

I would also use ).set( instead of ).map(. I heard that .map is deprecated. And you don't have to have them in the same block as the modifier Ndefs. You only map or set once and you have it.

bests,
Gil

Iain Mott <[hidden email]> schrieb am Fr., 10. Feb. 2017 um 20:44 Uhr:
Hello again,

I'm trying to learn how to use Ndefs and parameter mapping. I'm running
into trouble when using parameter modifiers that have envelopes/line
generators which are triggered on creation. From what I can see, these
parameter modifiers need to be declared at the time of mapping so that
the line generators are triggered at that very moment. This however,
seems to cause timing errors and other glitches in the sound.
For example, this first block of code creates a simple pulse:

(
Ndef(\tel,
     {
         arg freq = 200, pan = -1, rate = 3;
         var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
             SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
                 LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
         Pan2.ar(snd, pan);
     };
);
Ndef(\tel).play;
)

If I then modify the Ndef with the following block of code, at best --
on my machine at least -- there is a slight pause in the pulsing sound
before the modifiers take effect. Sometimes however, other more
unpleasant audio glitches occur:

(
Ndef(\rateramp, { XLine.kr(3, 164, 30) });
Ndef(\freqramp, { RunningMax.kr(200 + (Stepper.kr(Impulse.kr(XLine.kr(3,
164, 30)), 1, 0, 1000, 1, 0) * 2)) });
Ndef(\panmod, { PulseCount.kr(Impulse.kr(XLine.kr(3, 164, 30)))%2*2-1  });


Ndef(\tel).map(\rate, Ndef(\rateramp));
Ndef(\tel).map(\freq, Ndef(\freqramp));
Ndef(\tel).map(\pan, Ndef(\panmod));
)

If I remove the 1st 3 lines of this last block and place them at the end
of the first block, no timing glitches occur. But the problem there is
that the line generators have already been triggered in the 1st block -
ie. the horse has already bolted and they don't provide the intended
adjustments to the sound.

I did try using "rebuild" on the parameter modifiers in the second block
but this has exactly the same effect as defining them there.

What can I do here to avoid the problem? Is it necessary to somehow
retrigger the line generators?

Thanks,

Iain



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

-- 
_________
Iain Mott
http://escuta.org

-- 
_________
Iain Mott
http://escuta.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

Julian Rohrhuber-3
your examples work fine here, I wonder what is wrong in the version you have. Maybe someone on linux 3.8 could try and reproduce?


> On 17.02.2017, at 15:21, Iain Mott <[hidden email]> wrote:
>
> Hi List, I'm bumping this topic. Looking at it a week later I still don't know how to reset the parameters of the following ndef without causing various glitches and synch problems. Here is the basic ndef:
>
> (
> Ndef(\tel,
>     {
>         arg freq = 200, pan = 0, rate = 3;
>         //var trig= Impulse.kr(rate);
>           var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>             SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>                 LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>         Pan2.ar(snd, pan);
>     };
> );
> Ndef(\tel).play;
> )
>
> I then wish to make the pulse accelerate and pan alternatively hard-left and hard-right with each consecutive pulse:
>
> (
>
> Ndef(\rateramp, { XLine.kr(3, 164, 10) });
> Ndef(\freqramp, { RunningMax.kr(200 + (Stepper.kr(Impulse.kr(XLine.kr(3, 164, 30)), 1, 0, 1000, 1, 0) * 2)) });
> Ndef(\panmod, { PulseCount.kr(Impulse.kr(XLine.kr(3, 164, 30)))%2*2-1  });
>
>
> Ndef(\tel).set(\freq, Ndef(\freqramp));
> Ndef(\tel).set(\pan, Ndef(\panmod));
> Ndef(\tel).set(\rate, Ndef(\rateramp));
>
> )
>
> This however on my system (Linux, SC 3.8), causes various audio glitches as I mentioned. Should it work and if so, why do you think it isn't? If not, what am I doing wrong?
>
> The accelerating part of the sound should sound like this (and this by itself does work):
> (
> Ndef(\test,
>    {
>        var rate = XLine.kr(3, 164, 20);
>        var trig= Impulse.kr(rate);
>        var freq = RunningMax.kr(200 + (Stepper.kr(trig, 0, 0, 1000, 1) * 2));
>        var pan= PulseCount.kr(trig)%2*2-1;
>        var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>            SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>                LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>        Pan2.ar(snd, pan);
>    };
> ).play;
> )
>
> Thanks a lot.
>
> Iain
>
>
>
>
>
>
>
> Em 11/02/2017 07:01, Iain Mott escreveu:
>> Hi Gil,
>> Thanks. Using set now instead of map. Running the modifier declarations before setting them doesn't work as it interferes with the initial pulsing sound. Also, resetting the modifiers does remove the glitches but the result is that the modifiers are out of sync with the original pulse.
>>
>> I wonder why my system is giving glitches are yours not. Could it be a Linux issue? I'm using Linux and SC 3.8.0. This machine is pretty fast and has lots of memory.
>> Just so it's clear in terms of sound, the effect I was trying to achieve in the code I sent in last email was to go from this steady pulse:
>>
>> (
>> Ndef(\tel,
>>     {
>>         arg freq = 200, pan = -1, rate = 1;
>>         var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>>             SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>>                 LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>>         Pan2.ar(snd, pan);
>>     };
>> );
>> Ndef(\tel).play;
>> )
>> to this, seamlessly:
>>
>> (
>> Ndef(\test,
>>    {
>>        var rate = XLine.kr(3, 164, 20);
>>         var trig= Impulse.kr(rate);
>>        var freq = RunningMax.kr(200 + (Stepper.kr(trig, 0, 0, 1000, 1) * 2));
>>          var pan= PulseCount.kr(trig)%2*2-1;
>>        var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>>            SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>>                LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>>        Pan2.ar(snd, pan.poll);
>>    };
>> ).play;
>> )
>>
>> Is that what you heard?
>>
>> All the best,
>>
>> Iain
>>
>>
>>
>>
>> Em 10/02/2017 20:09, Gil Fuser escreveu:
>>> Hi Iain.
>>>
>>> I tried here and got no glitches and pauses.
>>>
>>> If you want to retrigger the modifiers by hand you can do something like this: Ndef(\rateramp).send.
>>>
>>> Maybe if you put the the Ndef(\tel).map(... before the modifiers you can prevent them to have been triggered before they are attached to the arguments of Ndef(\tel).
>>>
>>> I would also use ).set( instead of ).map(. I heard that .map is deprecated. And you don't have to have them in the same block as the modifier Ndefs. You only map or set once and you have it.
>>>
>>> bests,
>>> Gil
>>>
>>> Iain Mott <[hidden email]> schrieb am Fr., 10. Feb. 2017 um 20:44 Uhr:
>>> Hello again,
>>>
>>> I'm trying to learn how to use Ndefs and parameter mapping. I'm running
>>> into trouble when using parameter modifiers that have envelopes/line
>>> generators which are triggered on creation. From what I can see, these
>>> parameter modifiers need to be declared at the time of mapping so that
>>> the line generators are triggered at that very moment. This however,
>>> seems to cause timing errors and other glitches in the sound.
>>> For example, this first block of code creates a simple pulse:
>>>
>>> (
>>> Ndef(\tel,
>>>      {
>>>          arg freq = 200, pan = -1, rate = 3;
>>>          var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>>>              SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>>>                  LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>>>          Pan2.ar(snd, pan);
>>>      };
>>> );
>>> Ndef(\tel).play;
>>> )
>>>
>>> If I then modify the Ndef with the following block of code, at best --
>>> on my machine at least -- there is a slight pause in the pulsing sound
>>> before the modifiers take effect. Sometimes however, other more
>>> unpleasant audio glitches occur:
>>>
>>> (
>>> Ndef(\rateramp, { XLine.kr(3, 164, 30) });
>>> Ndef(\freqramp, { RunningMax.kr(200 + (Stepper.kr(Impulse.kr(XLine.kr(3,
>>> 164, 30)), 1, 0, 1000, 1, 0) * 2)) });
>>> Ndef(\panmod, { PulseCount.kr(Impulse.kr(XLine.kr(3, 164, 30)))%2*2-1  });
>>>
>>>
>>> Ndef(\tel).map(\rate, Ndef(\rateramp));
>>> Ndef(\tel).map(\freq, Ndef(\freqramp));
>>> Ndef(\tel).map(\pan, Ndef(\panmod));
>>> )
>>>
>>> If I remove the 1st 3 lines of this last block and place them at the end
>>> of the first block, no timing glitches occur. But the problem there is
>>> that the line generators have already been triggered in the 1st block -
>>> ie. the horse has already bolted and they don't provide the intended
>>> adjustments to the sound.
>>>
>>> I did try using "rebuild" on the parameter modifiers in the second block
>>> but this has exactly the same effect as defining them there.
>>>
>>> What can I do here to avoid the problem? Is it necessary to somehow
>>> retrigger the line generators?
>>>
>>> Thanks,
>>>
>>> Iain
>>>
>>>
>>>
>>> _______________________________________________
>>> sc-users mailing list
>>>
>>> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>>
>> --
>> _________
>> Iain Mott
>>
>> http://escuta.org
>
> --
> _________
> Iain Mott
>
> http://escuta.org


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

Iain Mott-2
Testing on an old laptop with Ubuntu Studio 14.04 and SC 3.7.2, the same
problem occurs. My main computer has Ubuntu Studio 16.04 and SC 3.8.0.

Thanks,


Em 18/02/2017 10:07, Julian Rohrhuber escreveu:

> your examples work fine here, I wonder what is wrong in the version you have. Maybe someone on linux 3.8 could try and reproduce?
>
>
>> On 17.02.2017, at 15:21, Iain Mott <[hidden email]> wrote:
>>
>> Hi List, I'm bumping this topic. Looking at it a week later I still don't know how to reset the parameters of the following ndef without causing various glitches and synch problems. Here is the basic ndef:
>>
>> (
>> Ndef(\tel,
>>      {
>>          arg freq = 200, pan = 0, rate = 3;
>>          //var trig= Impulse.kr(rate);
>>            var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>>              SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>>                  LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>>          Pan2.ar(snd, pan);
>>      };
>> );
>> Ndef(\tel).play;
>> )
>>
>> I then wish to make the pulse accelerate and pan alternatively hard-left and hard-right with each consecutive pulse:
>>
>> (
>>
>> Ndef(\rateramp, { XLine.kr(3, 164, 10) });
>> Ndef(\freqramp, { RunningMax.kr(200 + (Stepper.kr(Impulse.kr(XLine.kr(3, 164, 30)), 1, 0, 1000, 1, 0) * 2)) });
>> Ndef(\panmod, { PulseCount.kr(Impulse.kr(XLine.kr(3, 164, 30)))%2*2-1  });
>>
>>
>> Ndef(\tel).set(\freq, Ndef(\freqramp));
>> Ndef(\tel).set(\pan, Ndef(\panmod));
>> Ndef(\tel).set(\rate, Ndef(\rateramp));
>>
>> )
>>
>> This however on my system (Linux, SC 3.8), causes various audio glitches as I mentioned. Should it work and if so, why do you think it isn't? If not, what am I doing wrong?
>>
>> The accelerating part of the sound should sound like this (and this by itself does work):
>> (
>> Ndef(\test,
>>     {
>>         var rate = XLine.kr(3, 164, 20);
>>         var trig= Impulse.kr(rate);
>>         var freq = RunningMax.kr(200 + (Stepper.kr(trig, 0, 0, 1000, 1) * 2));
>>         var pan= PulseCount.kr(trig)%2*2-1;
>>         var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>>             SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>>                 LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>>         Pan2.ar(snd, pan);
>>     };
>> ).play;
>> )
>>
>> Thanks a lot.
>>
>> Iain
>>
>>
>>
>>
>>
>>
>>
>> Em 11/02/2017 07:01, Iain Mott escreveu:
>>> Hi Gil,
>>> Thanks. Using set now instead of map. Running the modifier declarations before setting them doesn't work as it interferes with the initial pulsing sound. Also, resetting the modifiers does remove the glitches but the result is that the modifiers are out of sync with the original pulse.
>>>
>>> I wonder why my system is giving glitches are yours not. Could it be a Linux issue? I'm using Linux and SC 3.8.0. This machine is pretty fast and has lots of memory.
>>> Just so it's clear in terms of sound, the effect I was trying to achieve in the code I sent in last email was to go from this steady pulse:
>>>
>>> (
>>> Ndef(\tel,
>>>      {
>>>          arg freq = 200, pan = -1, rate = 1;
>>>          var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>>>              SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>>>                  LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>>>          Pan2.ar(snd, pan);
>>>      };
>>> );
>>> Ndef(\tel).play;
>>> )
>>> to this, seamlessly:
>>>
>>> (
>>> Ndef(\test,
>>>     {
>>>         var rate = XLine.kr(3, 164, 20);
>>>          var trig= Impulse.kr(rate);
>>>         var freq = RunningMax.kr(200 + (Stepper.kr(trig, 0, 0, 1000, 1) * 2));
>>>           var pan= PulseCount.kr(trig)%2*2-1;
>>>         var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>>>             SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>>>                 LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>>>         Pan2.ar(snd, pan.poll);
>>>     };
>>> ).play;
>>> )
>>>
>>> Is that what you heard?
>>>
>>> All the best,
>>>
>>> Iain
>>>
>>>
>>>
>>>
>>> Em 10/02/2017 20:09, Gil Fuser escreveu:
>>>> Hi Iain.
>>>>
>>>> I tried here and got no glitches and pauses.
>>>>
>>>> If you want to retrigger the modifiers by hand you can do something like this: Ndef(\rateramp).send.
>>>>
>>>> Maybe if you put the the Ndef(\tel).map(... before the modifiers you can prevent them to have been triggered before they are attached to the arguments of Ndef(\tel).
>>>>
>>>> I would also use ).set( instead of ).map(. I heard that .map is deprecated. And you don't have to have them in the same block as the modifier Ndefs. You only map or set once and you have it.
>>>>
>>>> bests,
>>>> Gil
>>>>
>>>> Iain Mott <[hidden email]> schrieb am Fr., 10. Feb. 2017 um 20:44 Uhr:
>>>> Hello again,
>>>>
>>>> I'm trying to learn how to use Ndefs and parameter mapping. I'm running
>>>> into trouble when using parameter modifiers that have envelopes/line
>>>> generators which are triggered on creation. From what I can see, these
>>>> parameter modifiers need to be declared at the time of mapping so that
>>>> the line generators are triggered at that very moment. This however,
>>>> seems to cause timing errors and other glitches in the sound.
>>>> For example, this first block of code creates a simple pulse:
>>>>
>>>> (
>>>> Ndef(\tel,
>>>>       {
>>>>           arg freq = 200, pan = -1, rate = 3;
>>>>           var snd = DiodeRingMod.ar(SinOsc.ar(freq ),
>>>>               SinOsc.ar(200 * [0.75, 1, 0.5])).sum * 0.2 * Lag.ar(
>>>>                   LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
>>>>           Pan2.ar(snd, pan);
>>>>       };
>>>> );
>>>> Ndef(\tel).play;
>>>> )
>>>>
>>>> If I then modify the Ndef with the following block of code, at best --
>>>> on my machine at least -- there is a slight pause in the pulsing sound
>>>> before the modifiers take effect. Sometimes however, other more
>>>> unpleasant audio glitches occur:
>>>>
>>>> (
>>>> Ndef(\rateramp, { XLine.kr(3, 164, 30) });
>>>> Ndef(\freqramp, { RunningMax.kr(200 + (Stepper.kr(Impulse.kr(XLine.kr(3,
>>>> 164, 30)), 1, 0, 1000, 1, 0) * 2)) });
>>>> Ndef(\panmod, { PulseCount.kr(Impulse.kr(XLine.kr(3, 164, 30)))%2*2-1  });
>>>>
>>>>
>>>> Ndef(\tel).map(\rate, Ndef(\rateramp));
>>>> Ndef(\tel).map(\freq, Ndef(\freqramp));
>>>> Ndef(\tel).map(\pan, Ndef(\panmod));
>>>> )
>>>>
>>>> If I remove the 1st 3 lines of this last block and place them at the end
>>>> of the first block, no timing glitches occur. But the problem there is
>>>> that the line generators have already been triggered in the 1st block -
>>>> ie. the horse has already bolted and they don't provide the intended
>>>> adjustments to the sound.
>>>>
>>>> I did try using "rebuild" on the parameter modifiers in the second block
>>>> but this has exactly the same effect as defining them there.
>>>>
>>>> What can I do here to avoid the problem? Is it necessary to somehow
>>>> retrigger the line generators?
>>>>
>>>> Thanks,
>>>>
>>>> Iain
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sc-users mailing list
>>>>
>>>> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
>>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>>> --
>>> _________
>>> Iain Mott
>>>
>>> http://escuta.org
>> --
>> _________
>> Iain Mott
>>
>> http://escuta.org
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

--
_________
Iain Mott
http://escuta.org


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Loading...