Quantcast

Ndef question

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

Ndef question

mott
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

mott

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

mott

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
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

mott
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

mott
bump, bump.

So did no Linux users have trouble running code below? If it ran
smoothly, with no pauses or synch errors after resetting the ndef
parameters, can you please let me know what your system is and perhaps
the jack settings (although my settings are very conservative so i don't
think it's jack related) ?

Running the code throws now error messages.  Is there a verbose mode I
can try? Any other suggestions?

Thanks,

Iain

Em 18/02/2017 18:26, Iain Mott escreveu:

> 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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

gilFuser
This post was updated on .
Well, the test I made back in the beggining of this thread was in an old laptop, with
Linux Ubuntu Studio 16.10 using Jack not conservatively.
I have a suggestion that may help others with ideas of what is happening.
You could record the problems you are having. Hearing the symptom can be
good to find what is going on.
I would guess you are having problems somewhere else. Have you tried with a
different sound interface and/or speakers?

bests,
Gil

Iain Mott <mott@escuta.org> schrieb am Sa., 25. Feb. 2017 um 21:28 Uhr:

> bump, bump.
>
> So did no Linux users have trouble running code below? If it ran
> smoothly, with no pauses or synch errors after resetting the ndef
> parameters, can you please let me know what your system is and perhaps
> the jack settings (although my settings are very conservative so i don't
> think it's jack related) ?
>
> Running the code throws now error messages.  Is there a verbose mode I
> can try? Any other suggestions?
>
> Thanks,
>
> Iain
>
> Em 18/02/2017 18:26, Iain Mott escreveu:
> > 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 <mott@escuta.org> 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 <mott@escuta.org> 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/
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

daniel-mayer
In reply to this post by mott

Am 25.02.2017 um 21:28 schrieb Iain Mott <[hidden email]>:

> bump, bump.
>
> So did no Linux users have trouble running code below?


I'm not on Linux, sorry, I can't say about that. On OS X it works without glitches here.

Just a tip: if you provide a reproducer example that can immediately be run
on plain SC chances will be much higher that people will answer.

Here the user, who hasn't installed DiodeRingMod, is confronted with an error message.
Most people will loose interest at that point.
Those, who haven't, would have to research what kind of extension it is,
to install it, recompile etc.

Similiarily with undefined variables or locally stored buffers as it sometimes happens -
all this requires extra work and time if it should be checked ...

Regards

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------





_______________________________________________
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

mott
In reply to this post by gilFuser

Thanks Gil. Yes, good idea. Here's a recording. The first 12 or so seconds in the recording shows the problem. When the parameters are reset (aprox 4 sec) there's a sort of bumping noise as the panning is reset seemingly out of sync with the pulse - or some other problem. After 12 seconds in the demo, I run a second block of code which plays the acceleration part as it should sound, ie. without doing any ndef parameter resets (i included this block of code too in my posts above).

http://escuta.org/en/projects/test.html

And yes, I did try a different system. I ran the code on a second machine, a laptop with Ubuntu studio 14.04 and SC 3.7.2. It reproduced the same problem. The soundcard on my main machine is a RME Multiface mark 1.

Iain


Em 25/02/2017 18:12, Gil Fuser escreveu:
Well, the test I made back when this thread was in an old laptop, with Linux Ubuntu Studio 16.10 using Jack not conservatively.
I have a suggestion that may help others with ideas of what is happening.
You could record the problems you are having. Hearing the symptom can be good to find what is going on.
I would guess you are having problems somewhere else. Have you tried with a different sound interface and/or speakers?

bests,
Gil

Iain Mott <[hidden email]> schrieb am Sa., 25. Feb. 2017 um 21:28 Uhr:
bump, bump.

So did no Linux users have trouble running code below? If it ran
smoothly, with no pauses or synch errors after resetting the ndef
parameters, can you please let me know what your system is and perhaps
the jack settings (although my settings are very conservative so i don't
think it's jack related) ?

Running the code throws now error messages.  Is there a verbose mode I
can try? Any other suggestions?

Thanks,

Iain

Em 18/02/2017 18:26, Iain Mott escreveu:
> 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/

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

Re: Ndef question

mott
In reply to this post by daniel-mayer
good point too. Here it is without DiodeRingMod:

Ndef.clear(1);

(
Ndef(\tel,
     {
         arg freq = 200, pan = 0, rate = 3;
           var snd = LFPulse.ar(freq ) * 0.2 * Lag.ar(
                 LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
         Pan2.ar(snd, pan);
     };
);


The reset:

(

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));

)


and as the acceleration should sound:

(
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 = LFPulse.ar(freq ) * 0.2 * Lag.ar(
                LFPulse.ar( rate, 0, 0.4), 0.05) * 0.2;
        Pan2.ar(snd, pan);
    };
).play;
)


Em 25/02/2017 18:39, Daniel Mayer escreveu:

> Am 25.02.2017 um 21:28 schrieb Iain Mott <[hidden email]>:
>
>> bump, bump.
>>
>> So did no Linux users have trouble running code below?
>
> I'm not on Linux, sorry, I can't say about that. On OS X it works without glitches here.
>
> Just a tip: if you provide a reproducer example that can immediately be run
> on plain SC chances will be much higher that people will answer.
>
> Here the user, who hasn't installed DiodeRingMod, is confronted with an error message.
> Most people will loose interest at that point.
> Those, who haven't, would have to research what kind of extension it is,
> to install it, recompile etc.
>
> Similiarily with undefined variables or locally stored buffers as it sometimes happens -
> all this requires extra work and time if it should be checked ...
>
> Regards
>
> Daniel
>
> -----------------------------
> www.daniel-mayer.at
> -----------------------------
>
>
>
>
>
> _______________________________________________
> 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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

mott
In reply to this post by mott

Hi Linux users. So when you run the code below, does it sound different to my audio example?

http://escuta.org/en/projects/test.html

thanks


Em 26/02/2017 07:44, Iain Mott escreveu:

Thanks Gil. Yes, good idea. Here's a recording. The first 12 or so seconds in the recording shows the problem. When the parameters are reset (aprox 4 sec) there's a sort of bumping noise as the panning is reset seemingly out of sync with the pulse - or some other problem. After 12 seconds in the demo, I run a second block of code which plays the acceleration part as it should sound, ie. without doing any ndef parameter resets (i included this block of code too in my posts above).

http://escuta.org/en/projects/test.html

And yes, I did try a different system. I ran the code on a second machine, a laptop with Ubuntu studio 14.04 and SC 3.7.2. It reproduced the same problem. The soundcard on my main machine is a RME Multiface mark 1.

Iain


Em 25/02/2017 18:12, Gil Fuser escreveu:
Well, the test I made back when this thread was in an old laptop, with Linux Ubuntu Studio 16.10 using Jack not conservatively.
I have a suggestion that may help others with ideas of what is happening.
You could record the problems you are having. Hearing the symptom can be good to find what is going on.
I would guess you are having problems somewhere else. Have you tried with a different sound interface and/or speakers?

bests,
Gil

Iain Mott <[hidden email]> schrieb am Sa., 25. Feb. 2017 um 21:28 Uhr:
bump, bump.

So did no Linux users have trouble running code below? If it ran
smoothly, with no pauses or synch errors after resetting the ndef
parameters, can you please let me know what your system is and perhaps
the jack settings (although my settings are very conservative so i don't
think it's jack related) ?

Running the code throws now error messages.  Is there a verbose mode I
can try? Any other suggestions?

Thanks,

Iain

Em 18/02/2017 18:26, Iain Mott escreveu:
> 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/

-- 
_________
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
I listened to your sound example and it sound as expected. This is not a glitch, it’s just sounds differently from your other example because the Ndef already plays its sound.

If you want to reset, you can write: Ndef(\x).send

The two examples sound the same when you add the line:

Ndef(\tel).send.play;

to your parameter mappings.

I hope this helps!


> On 28.02.2017, at 17:58, Iain Mott <[hidden email]> wrote:
>
> Hi Linux users. So when you run the code below, does it sound different to my audio example?
> http://escuta.org/en/projects/test.html
>
> thanks
>
>
> Em 26/02/2017 07:44, Iain Mott escreveu:
>> Thanks Gil. Yes, good idea. Here's a recording. The first 12 or so seconds in the recording shows the problem. When the parameters are reset (aprox 4 sec) there's a sort of bumping noise as the panning is reset seemingly out of sync with the pulse - or some other problem. After 12 seconds in the demo, I run a second block of code which plays the acceleration part as it should sound, ie. without doing any ndef parameter resets (i included this block of code too in my posts above).
>>
>> http://escuta.org/en/projects/test.html
>>
>> And yes, I did try a different system. I ran the code on a second machine, a laptop with Ubuntu studio 14.04 and SC 3.7.2. It reproduced the same problem. The soundcard on my main machine is a RME Multiface mark 1.
>> Iain
>>
>> Em 25/02/2017 18:12, Gil Fuser escreveu:
>>> Well, the test I made back when this thread was in an old laptop, with Linux Ubuntu Studio 16.10 using Jack not conservatively.
>>> I have a suggestion that may help others with ideas of what is happening.
>>> You could record the problems you are having. Hearing the symptom can be good to find what is going on.
>>> I would guess you are having problems somewhere else. Have you tried with a different sound interface and/or speakers?
>>>
>>> bests,
>>> Gil
>>>
>>> Iain Mott <[hidden email]> schrieb am Sa., 25. Feb. 2017 um 21:28 Uhr:
>>> bump, bump.
>>>
>>> So did no Linux users have trouble running code below? If it ran
>>> smoothly, with no pauses or synch errors after resetting the ndef
>>> parameters, can you please let me know what your system is and perhaps
>>> the jack settings (although my settings are very conservative so i don't
>>> think it's jack related) ?
>>>
>>> Running the code throws now error messages.  Is there a verbose mode I
>>> can try? Any other suggestions?
>>>
>>> Thanks,
>>>
>>> Iain
>>>
>>> Em 18/02/2017 18:26, Iain Mott escreveu:
>>> > 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/
>>
>> --
>> _________
>> 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

gilFuser
... and if you put these .lags here, so the change wouldn't be so abrupt:

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

Julian Rohrhuber <[hidden email]> schrieb am Di., 28. Feb. 2017 um 19:48 Uhr:
I listened to your sound example and it sound as expected. This is not a glitch, it’s just sounds differently from your other example because the Ndef already plays its sound.

If you want to reset, you can write: Ndef(\x).send

The two examples sound the same when you add the line:

Ndef(\tel).send.play;

to your parameter mappings.

I hope this helps!


> On 28.02.2017, at 17:58, Iain Mott <[hidden email]> wrote:
>
> Hi Linux users. So when you run the code below, does it sound different to my audio example?
> http://escuta.org/en/projects/test.html
>
> thanks
>
>
> Em 26/02/2017 07:44, Iain Mott escreveu:
>> Thanks Gil. Yes, good idea. Here's a recording. The first 12 or so seconds in the recording shows the problem. When the parameters are reset (aprox 4 sec) there's a sort of bumping noise as the panning is reset seemingly out of sync with the pulse - or some other problem. After 12 seconds in the demo, I run a second block of code which plays the acceleration part as it should sound, ie. without doing any ndef parameter resets (i included this block of code too in my posts above).
>>
>> http://escuta.org/en/projects/test.html
>>
>> And yes, I did try a different system. I ran the code on a second machine, a laptop with Ubuntu studio 14.04 and SC 3.7.2. It reproduced the same problem. The soundcard on my main machine is a RME Multiface mark 1.
>> Iain
>>
>> Em 25/02/2017 18:12, Gil Fuser escreveu:
>>> Well, the test I made back when this thread was in an old laptop, with Linux Ubuntu Studio 16.10 using Jack not conservatively.
>>> I have a suggestion that may help others with ideas of what is happening.
>>> You could record the problems you are having. Hearing the symptom can be good to find what is going on.
>>> I would guess you are having problems somewhere else. Have you tried with a different sound interface and/or speakers?
>>>
>>> bests,
>>> Gil
>>>
>>> Iain Mott <[hidden email]> schrieb am Sa., 25. Feb. 2017 um 21:28 Uhr:
>>> bump, bump.
>>>
>>> So did no Linux users have trouble running code below? If it ran
>>> smoothly, with no pauses or synch errors after resetting the ndef
>>> parameters, can you please let me know what your system is and perhaps
>>> the jack settings (although my settings are very conservative so i don't
>>> think it's jack related) ?
>>>
>>> Running the code throws now error messages.  Is there a verbose mode I
>>> can try? Any other suggestions?
>>>
>>> Thanks,
>>>
>>> Iain
>>>
>>> Em 18/02/2017 18:26, Iain Mott escreveu:
>>> > 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/
>>
>> --
>> _________
>> 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

mott
In reply to this post by julian.rohrhuber
Many thanks Julian and Gil. Gil had mentioned using send to reset
parameters, but I'd gone about implementing it the wrong way. Now it's
working pretty well.

All the best!

Iain









Em 28/02/2017 15:47, Julian Rohrhuber escreveu:

> I listened to your sound example and it sound as expected. This is not a glitch, it’s just sounds differently from your other example because the Ndef already plays its sound.
>
> If you want to reset, you can write: Ndef(\x).send
>
> The two examples sound the same when you add the line:
>
> Ndef(\tel).send.play;
>
> to your parameter mappings.
>
> I hope this helps!
>
>
>> On 28.02.2017, at 17:58, Iain Mott <[hidden email]> wrote:
>>
>> Hi Linux users. So when you run the code below, does it sound different to my audio example?
>> http://escuta.org/en/projects/test.html
>>
>> thanks
>>
>>
>> Em 26/02/2017 07:44, Iain Mott escreveu:
>>> Thanks Gil. Yes, good idea. Here's a recording. The first 12 or so seconds in the recording shows the problem. When the parameters are reset (aprox 4 sec) there's a sort of bumping noise as the panning is reset seemingly out of sync with the pulse - or some other problem. After 12 seconds in the demo, I run a second block of code which plays the acceleration part as it should sound, ie. without doing any ndef parameter resets (i included this block of code too in my posts above).
>>>
>>> http://escuta.org/en/projects/test.html
>>>
>>> And yes, I did try a different system. I ran the code on a second machine, a laptop with Ubuntu studio 14.04 and SC 3.7.2. It reproduced the same problem. The soundcard on my main machine is a RME Multiface mark 1.
>>> Iain
>>>
>>> Em 25/02/2017 18:12, Gil Fuser escreveu:
>>>> Well, the test I made back when this thread was in an old laptop, with Linux Ubuntu Studio 16.10 using Jack not conservatively.
>>>> I have a suggestion that may help others with ideas of what is happening.
>>>> You could record the problems you are having. Hearing the symptom can be good to find what is going on.
>>>> I would guess you are having problems somewhere else. Have you tried with a different sound interface and/or speakers?
>>>>
>>>> bests,
>>>> Gil
>>>>
>>>> Iain Mott <[hidden email]> schrieb am Sa., 25. Feb. 2017 um 21:28 Uhr:
>>>> bump, bump.
>>>>
>>>> So did no Linux users have trouble running code below? If it ran
>>>> smoothly, with no pauses or synch errors after resetting the ndef
>>>> parameters, can you please let me know what your system is and perhaps
>>>> the jack settings (although my settings are very conservative so i don't
>>>> think it's jack related) ?
>>>>
>>>> Running the code throws now error messages.  Is there a verbose mode I
>>>> can try? Any other suggestions?
>>>>
>>>> Thanks,
>>>>
>>>> Iain
>>>>
>>>> Em 18/02/2017 18:26, Iain Mott escreveu:
>>>>> 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/
>>> --
>>> _________
>>> 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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ndef question

julian.rohrhuber
good that it worked, and that, again, linux wasn’t to be blamed!

> On 28.02.2017, at 21:05, Iain Mott <[hidden email]> wrote:
>
> Many thanks Julian and Gil. Gil had mentioned using send to reset parameters, but I'd gone about implementing it the wrong way. Now it's working pretty well.


_______________________________________________
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

mott
yes!


Em 28/02/2017 17:47, Julian Rohrhuber escreveu:

> good that it worked, and that, again, linux wasn’t to be blamed!
>
>> On 28.02.2017, at 21:05, Iain Mott <[hidden email]> wrote:
>>
>> Many thanks Julian and Gil. Gil had mentioned using send to reset parameters, but I'd gone about implementing it the wrong way. Now it's working pretty well.
>
> _______________________________________________
> 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...