« Return to Thread: delays and buffers
Re: delays and buffers
by Josh Parmenter
::
Rate this Message:
Maybe:
+ SimpleNumber {
feedbackToDecaytime {arg deltime = 0.1;
^(0.001.log2 * deltime) / this.log2;
}
}
0.995.feedbackToDecaytime(0.001)
I'm sure there can be a better way to phrase this... this is for a
-60db decay... perhaps that should be variable also:
+ SimpleNumber {
feedbackToDecaytime {arg deltime = 0.1, db = -60;
^(db.dbamp.log2 * deltime) / this.log2;
}
}
Josh
On Jun 29, 2008, at 10:59 AM, Dan Stowell wrote:
> 2008/6/29, Josh Parmenter <josh@...>:
>> On Jun 29, 2008, at 4:01 AM, Andre Bartetzki wrote:
>>
>>
>>> BufTapIn.ar(inputArray, bufnum);
>>> BufTapOut.ar(numChannels, bufnum, delaytime, interpolation);
>>> ???
>>> Would it be hard to implement that?
>>>
>>> Also, I'd like to have non-interpolating Delay UGens which take just
>> samples
>>> instead of delaytimes, like Delay1 and Delay2.
>>> For the construction of reverbs it would be good to also have
>>> sample based
>>> versions for Comb and Allpass. Plus a feedback argument instead of
>>> decaytime!
>>>
>>
>>
>> I think all of these are possible, but at the same time, these are
>> just
>> variants of things that do already exist. I agree that finding an
>> efficient
>> tap would be a good idea (I'll look into it), but converting
>> between time
>> and samples is pretty easy math. Making a new UGen for it seems
>> like a bit
>> of overkill.
>>
>> I think the main reason behind using times instead of samples and
>> decaytime
>> instead of feedback has to do making code that will easily move
>> between
>> sample rates. Samples and feedback would drastically change how a
>> delay
>> would react between different sample rates, so it is much safer to
>> use the
>> current UGens.
>>
>> With that in mind, if you really do think that you need a delay with
>> samples instead of time, it would be easy to make (actually easier
>> then the
>> ones we currently have)... feedback and decaytime as well.
>>
>> How do others feel?
>
> I agree that enough units already exist to cater for this. Converting
> between seconds and samples is just dividing by the sample-rate, an
> incredibly trivial thing for a user to do, so certainly doesn't
> justify any new UGens. The conversion from decaytime to feedback level
> is not quite so trivial but still fairly easy.
>
> For non-interpolating delays, Andre, are you aware that
> non-interpolating delays exist (DelayN instead of DelayC)? Just making
> sure, since you didn't mention it. Dividing by the sample-rate, and
> there you have your non-interpolating sample-specified delay.
>
> The findings re the efficiency of the different delay options are
> interesting. Finding a more efficient approach to Tap would be good -
> please do look into that further, IMHO. But I'd be hoping for a
> pseudo-UGen solution, rather than more UGen C code to maintain!
>
> Just my 2p
>
> Dan
>
> _______________________________________________
> sc-users mailing list
>
>
> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/
“Every composer – at all times and in all cases – gives his own
interpretation of how modern society is structured: whether actively
or passively, consciously or unconsciously, he makes choices in this
regard. He may be conservative or he may subject himself to continual
renewal; or he may strive for a revolutionary, historical or social
palingenesis." - Luigi Nono
*/
_______________________________________________
sc-users mailing list
info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
+ SimpleNumber {
feedbackToDecaytime {arg deltime = 0.1;
^(0.001.log2 * deltime) / this.log2;
}
}
0.995.feedbackToDecaytime(0.001)
I'm sure there can be a better way to phrase this... this is for a
-60db decay... perhaps that should be variable also:
+ SimpleNumber {
feedbackToDecaytime {arg deltime = 0.1, db = -60;
^(db.dbamp.log2 * deltime) / this.log2;
}
}
Josh
On Jun 29, 2008, at 10:59 AM, Dan Stowell wrote:
> 2008/6/29, Josh Parmenter <josh@...>:
>> On Jun 29, 2008, at 4:01 AM, Andre Bartetzki wrote:
>>
>>
>>> BufTapIn.ar(inputArray, bufnum);
>>> BufTapOut.ar(numChannels, bufnum, delaytime, interpolation);
>>> ???
>>> Would it be hard to implement that?
>>>
>>> Also, I'd like to have non-interpolating Delay UGens which take just
>> samples
>>> instead of delaytimes, like Delay1 and Delay2.
>>> For the construction of reverbs it would be good to also have
>>> sample based
>>> versions for Comb and Allpass. Plus a feedback argument instead of
>>> decaytime!
>>>
>>
>>
>> I think all of these are possible, but at the same time, these are
>> just
>> variants of things that do already exist. I agree that finding an
>> efficient
>> tap would be a good idea (I'll look into it), but converting
>> between time
>> and samples is pretty easy math. Making a new UGen for it seems
>> like a bit
>> of overkill.
>>
>> I think the main reason behind using times instead of samples and
>> decaytime
>> instead of feedback has to do making code that will easily move
>> between
>> sample rates. Samples and feedback would drastically change how a
>> delay
>> would react between different sample rates, so it is much safer to
>> use the
>> current UGens.
>>
>> With that in mind, if you really do think that you need a delay with
>> samples instead of time, it would be easy to make (actually easier
>> then the
>> ones we currently have)... feedback and decaytime as well.
>>
>> How do others feel?
>
> I agree that enough units already exist to cater for this. Converting
> between seconds and samples is just dividing by the sample-rate, an
> incredibly trivial thing for a user to do, so certainly doesn't
> justify any new UGens. The conversion from decaytime to feedback level
> is not quite so trivial but still fairly easy.
>
> For non-interpolating delays, Andre, are you aware that
> non-interpolating delays exist (DelayN instead of DelayC)? Just making
> sure, since you didn't mention it. Dividing by the sample-rate, and
> there you have your non-interpolating sample-specified delay.
>
> The findings re the efficiency of the different delay options are
> interesting. Finding a more efficient approach to Tap would be good -
> please do look into that further, IMHO. But I'd be hoping for a
> pseudo-UGen solution, rather than more UGen C code to maintain!
>
> Just my 2p
>
> Dan
>
> _______________________________________________
> sc-users mailing list
>
>
> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/
“Every composer – at all times and in all cases – gives his own
interpretation of how modern society is structured: whether actively
or passively, consciously or unconsciously, he makes choices in this
regard. He may be conservative or he may subject himself to continual
renewal; or he may strive for a revolutionary, historical or social
palingenesis." - Luigi Nono
*/
_______________________________________________
sc-users mailing list
info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
« Return to Thread: delays and buffers
| Free embeddable forum powered by Nabble | Forum Help |
