TTRamp design question

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

TTRamp design question

Nils Peters
Hi,

I am working on a unit test for TTRamp and now I have a design question.
If currentValue 0.0 and destinationValue 1.0, what should be the first
and last sample of the ramp function?

is th eramp function going from

a) 0.0 .... 1.0
b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
c) the first increment larger than zero (e.g. 0.0156250000) ... one
increment before one (e.g. 0.9843750000)

any comment?

--Nils

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Timothy Place-2
On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]> wrote:
Hi,

I am working on a unit test for TTRamp and now I have a design question.
If currentValue 0.0 and destinationValue 1.0, what should be the first
and last sample of the ramp function?

is th eramp function going from

a) 0.0 .... 1.0
b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
c) the first increment larger than zero (e.g. 0.0156250000) ... one
increment before one (e.g. 0.9843750000)

any comment?

Option (c) is definitely wrong -- it should end at the destination value

As to whether (a) or (b) is correct, I guess I'm not 100% sure.  I'm initially inclined to believe that the value is already at the starting point, so then there is no need to duplicate that in the ramp.  What do you think?

best,
  Tim


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Jesse Allison
I would think that (b) is the best option.  

My apologies if I missed an earlier part of this discussion, but I wonder too if when the ramp timer is set up, we should have the immediate triggering of the ramp wait for one tick before moving to the first value.  E.g. have a parameter at 0, trigger a ramp to 10 over 10 seconds.  Upon triggering, nothing happens, at the end of the first second it ramps to 1, etc. to 10.  That way we avoid the Max issue of having the destination value arrive one tick too early.  

it would look something like this

b) current value, then the first increment larger than zero (e.g. 0.0156250000) ... 1.0


 -jesse


On Mar 16, 2011, at 1:12 PM, Timothy Place wrote:

On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]> wrote:
Hi,

I am working on a unit test for TTRamp and now I have a design question.
If currentValue 0.0 and destinationValue 1.0, what should be the first
and last sample of the ramp function?

is th eramp function going from

a) 0.0 .... 1.0
b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
c) the first increment larger than zero (e.g. 0.0156250000) ... one
increment before one (e.g. 0.9843750000)

any comment?

Option (c) is definitely wrong -- it should end at the destination value

As to whether (a) or (b) is correct, I guess I'm not 100% sure.  I'm initially inclined to believe that the value is already at the starting point, so then there is no need to duplicate that in the ramp.  What do you think?

best,
  Tim

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d_______________________________________________
Jamoma-devel mailing list
[hidden email]
 QA  c xzzx


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Nils Peters
In reply to this post by Timothy Place-2
On 11-03-16 7:12 PM, Timothy Place wrote:

> On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     I am working on a unit test for TTRamp and now I have a design question.
>     If currentValue 0.0 and destinationValue 1.0, what should be the first
>     and last sample of the ramp function?
>
>     is th eramp function going from
>
>     a) 0.0 .... 1.0
>     b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
>     c) the first increment larger than zero (e.g. 0.0156250000) ... one
>     increment before one (e.g. 0.9843750000)
>
>     any comment?
>
>
> Option (c) is definitely wrong -- it should end at the destination value

Option (c) is currently the way it works. And I don't like it either.
I think I am preferring b), because that's what the parameter name
"currentValue" suggests.
If we opt for a), we should change the parameter to startValue or sth.
like that.

--nils

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Timothy Place-2
I concur.  Let's go with B.  Any who object to this, make your objections known now!

best,
  Tim


On Wed, Mar 16, 2011 at 2:13 PM, Nils Peters <[hidden email]> wrote:
On 11-03-16 7:12 PM, Timothy Place wrote:
> On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     I am working on a unit test for TTRamp and now I have a design question.
>     If currentValue 0.0 and destinationValue 1.0, what should be the first
>     and last sample of the ramp function?
>
>     is th eramp function going from
>
>     a) 0.0 .... 1.0
>     b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
>     c) the first increment larger than zero (e.g. 0.0156250000) ... one
>     increment before one (e.g. 0.9843750000)
>
>     any comment?
>
>
> Option (c) is definitely wrong -- it should end at the destination value

Option (c) is currently the way it works. And I don't like it either.
I think I am preferring b), because that's what the parameter name
"currentValue" suggests.
If we opt for a), we should change the parameter to startValue or sth.
like that.

--nils

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
jln
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

jln
Administrator
I also vote for B. No objection.

Best,
Julien


Le 16 mars 2011 à 22:35, Timothy Place a écrit :

I concur.  Let's go with B.  Any who object to this, make your objections known now!

best,
  Tim


On Wed, Mar 16, 2011 at 2:13 PM, Nils Peters <[hidden email]> wrote:
On 11-03-16 7:12 PM, Timothy Place wrote:
> On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     I am working on a unit test for TTRamp and now I have a design question.
>     If currentValue 0.0 and destinationValue 1.0, what should be the first
>     and last sample of the ramp function?
>
>     is th eramp function going from
>
>     a) 0.0 .... 1.0
>     b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
>     c) the first increment larger than zero (e.g. 0.0156250000) ... one
>     increment before one (e.g. 0.9843750000)
>
>     any comment?
>
>
> Option (c) is definitely wrong -- it should end at the destination value

Option (c) is currently the way it works. And I don't like it either.
I think I am preferring b), because that's what the parameter name
"currentValue" suggests.
If we opt for a), we should change the parameter to startValue or sth.
like that.

--nils

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

adrian.g
Administrator
Hi,

Are we talking about some internal representation of the ramp within the object or about actual behaviour? Does option b. mean that at time 0 of a ramp from 0 to 1 the value would be (as in the example) 0.0156250000?

If so, consider this:

initial parameter value is 1

in a CueScript we have the following:

     /parameter 0 ramp 1000
     WAIT 1000
     /parameter 1 ramp 1000

I imagine that at 1000 ms after triggering the script the value should be: 0 and at 2000 ms: 1

but if I understand it correctly, in case b. at time 1000 ms the value would reach 0 and then immediately (at the same logical time) jump to first larger than zero (e.g. 0.0156250000) and continue the ramp from there.

Am I understanding things right?

best

Adrian




On Wed, Mar 16, 2011 at 9:39 PM, jln [via Jamoma Forums/Mailing lists] <[hidden email]> wrote:
I also vote for B. No objection.

Best,
Julien


Le 16 mars 2011 à 22:35, Timothy Place a écrit :

I concur.  Let's go with B.  Any who object to this, make your objections known now!

best,
  Tim


On Wed, Mar 16, 2011 at 2:13 PM, Nils Peters <[hidden email]> wrote:
On 11-03-16 7:12 PM, Timothy Place wrote:
> On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi,
>
>     I am working on a unit test for TTRamp and now I have a design question.
>     If currentValue 0.0 and destinationValue 1.0, what should be the first
>     and last sample of the ramp function?
>
>     is th eramp function going from
>
>     a) 0.0 .... 1.0
>     b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
>     c) the first increment larger than zero (e.g. 0.0156250000) ... one
>     increment before one (e.g. 0.9843750000)
>
>     any comment?
>
>
> Option (c) is definitely wrong -- it should end at the destination value

Option (c) is currently the way it works. And I don't like it either.
I think I am preferring b), because that's what the parameter name
"currentValue" suggests.
If we opt for a), we should change the parameter to startValue or sth.
like that.

--nils

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel



If you reply to this email, your message will be added to the discussion below:
http://jamoma-forums-mailing-lists.3076123.n2.nabble.com/TTRamp-design-question-tp6178139p6178988.html
To start a new topic under Jamoma Development, email [hidden email]
To unsubscribe from Jamoma Development, click here.



--
Adrian Gierakowski
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Trond Lossius
Administrator
Hi,

Coming in late on the discussion, IMHO ramps should behave as much as possible the way they would if happening at signal rate. So in Adrian's example:

    /parameter 0 ramp 1000
     WAIT 1000
     /parameter 1 ramp 1000

Assuming that ramp is producing output every 20 ms, I would expect this to yield:

0 ms => 0.
1000 ms => 0.
1020 ms => 0.02
1040 ms => 0.04
1060 ms => 0.06
....
1960 ms => 0.196
1980 ms => 0.198
2000 ms => 2.0

Next one could discuss if the seemingly redundant value at 1000 ms should be output or not. For me this would depend on the value of @repetitions/allow.


Best,
Trond



On Mar 16, 2011, at 11:08 PM, adrian.g wrote:

> Hi,
>
> Are we talking about some internal representation of the ramp within the object or about actual behaviour? Does option b. mean that at time 0 of a ramp from 0 to 1 the value would be (as in the example) 0.0156250000?
>
> If so, consider this:
>
> initial parameter value is 1
>
> in a CueScript we have the following:
>
>      /parameter 0 ramp 1000
>      WAIT 1000
>      /parameter 1 ramp 1000
>
> I imagine that at 1000 ms after triggering the script the value should be: 0 and at 2000 ms: 1
>
> but if I understand it correctly, in case b. at time 1000 ms the value would reach 0 and then immediately (at the same logical time) jump to first larger than zero (e.g. 0.0156250000) and continue the ramp from there.
>
> Am I understanding things right?
>
> best
>
> Adrian
>
>
>
>
> On Wed, Mar 16, 2011 at 9:39 PM, jln [via Jamoma Forums/Mailing lists] <[hidden email]> wrote:
> I also vote for B. No objection.
>
> Best,
> Julien
>
>
> Le 16 mars 2011 à 22:35, Timothy Place a écrit :
>
>> I concur.  Let's go with B.  Any who object to this, make your objections known now!
>>
>> best,
>>   Tim
>>
>>
>> On Wed, Mar 16, 2011 at 2:13 PM, Nils Peters <[hidden email]> wrote:
>> On 11-03-16 7:12 PM, Timothy Place wrote:
>> > On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]
>> > <mailto:[hidden email]>> wrote:
>> >
>> >     Hi,
>> >
>> >     I am working on a unit test for TTRamp and now I have a design question.
>> >     If currentValue 0.0 and destinationValue 1.0, what should be the first
>> >     and last sample of the ramp function?
>> >
>> >     is th eramp function going from
>> >
>> >     a) 0.0 .... 1.0
>> >     b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
>> >     c) the first increment larger than zero (e.g. 0.0156250000) ... one
>> >     increment before one (e.g. 0.9843750000)
>> >
>> >     any comment?
>> >
>> >
>> > Option (c) is definitely wrong -- it should end at the destination value
>>
>> Option (c) is currently the way it works. And I don't like it either.
>> I think I am preferring b), because that's what the parameter name
>> "currentValue" suggests.
>> If we opt for a), we should change the parameter to startValue or sth.
>> like that.
>>
>> --nils
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Jamoma-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
>> Jamoma-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://jamoma-forums-mailing-lists.3076123.n2.nabble.com/TTRamp-design-question-tp6178139p6178988.html
> To start a new topic under Jamoma Development, email [hidden email]
>
>
>
> --
> Adrian Gierakowski
>
> View this message in context: Re: TTRamp design question
> Sent from the Jamoma Development mailing list archive at Nabble.com.
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Timothy Place-2
Nils was referring to TTRamp, which is an audio generator in the DSP lib.  Regarding the control-rate ramp, I think we should create a wiki page for this, as it is an obvious need that I think we are very likely to try implementing in the next 12-18 months.

best,
  Tim


On Wed, Mar 16, 2011 at 5:50 PM, Trond Lossius <[hidden email]> wrote:
Hi,

Coming in late on the discussion, IMHO ramps should behave as much as possible the way they would if happening at signal rate. So in Adrian's example:

   /parameter 0 ramp 1000
    WAIT 1000
    /parameter 1 ramp 1000

Assuming that ramp is producing output every 20 ms, I would expect this to yield:

0 ms            =>      0.
1000 ms         =>      0.
1020 ms         =>      0.02
1040 ms         =>      0.04
1060 ms         =>      0.06
....
1960 ms         =>      0.196
1980 ms         =>      0.198
2000 ms         =>      2.0

Next one could discuss if the seemingly redundant value at 1000 ms should be output or not. For me this would depend on the value of @repetitions/allow.


Best,
Trond



On Mar 16, 2011, at 11:08 PM, adrian.g wrote:

> Hi,
>
> Are we talking about some internal representation of the ramp within the object or about actual behaviour? Does option b. mean that at time 0 of a ramp from 0 to 1 the value would be (as in the example) 0.0156250000?
>
> If so, consider this:
>
> initial parameter value is 1
>
> in a CueScript we have the following:
>
>      /parameter 0 ramp 1000
>      WAIT 1000
>      /parameter 1 ramp 1000
>
> I imagine that at 1000 ms after triggering the script the value should be: 0 and at 2000 ms: 1
>
> but if I understand it correctly, in case b. at time 1000 ms the value would reach 0 and then immediately (at the same logical time) jump to first larger than zero (e.g. 0.0156250000) and continue the ramp from there.
>
> Am I understanding things right?
>
> best
>
> Adrian
>
>
>
>
> On Wed, Mar 16, 2011 at 9:39 PM, jln [via Jamoma Forums/Mailing lists] <[hidden email]> wrote:
> I also vote for B. No objection.
>
> Best,
> Julien
>
>
> Le 16 mars 2011 à 22:35, Timothy Place a écrit :
>
>> I concur.  Let's go with B.  Any who object to this, make your objections known now!
>>
>> best,
>>   Tim
>>
>>
>> On Wed, Mar 16, 2011 at 2:13 PM, Nils Peters <[hidden email]> wrote:
>> On 11-03-16 7:12 PM, Timothy Place wrote:
>> > On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]
>> > <mailto:[hidden email]>> wrote:
>> >
>> >     Hi,
>> >
>> >     I am working on a unit test for TTRamp and now I have a design question.
>> >     If currentValue 0.0 and destinationValue 1.0, what should be the first
>> >     and last sample of the ramp function?
>> >
>> >     is th eramp function going from
>> >
>> >     a) 0.0 .... 1.0
>> >     b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
>> >     c) the first increment larger than zero (e.g. 0.0156250000) ... one
>> >     increment before one (e.g. 0.9843750000)
>> >
>> >     any comment?
>> >
>> >
>> > Option (c) is definitely wrong -- it should end at the destination value
>>
>> Option (c) is currently the way it works. And I don't like it either.
>> I think I am preferring b), because that's what the parameter name
>> "currentValue" suggests.
>> If we opt for a), we should change the parameter to startValue or sth.
>> like that.
>>
>> --nils
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Jamoma-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
>> Jamoma-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://jamoma-forums-mailing-lists.3076123.n2.nabble.com/TTRamp-design-question-tp6178139p6178988.html
> To start a new topic under Jamoma Development, email [hidden email]
>
>
>
> --
> Adrian Gierakowski
>
> View this message in context: Re: TTRamp design question
> Sent from the Jamoma Development mailing list archive at Nabble.com.
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> Jamoma-devel mailing list
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Nathan Wolek-2
On Mar 16, 2011, at 8:45 PM, Timothy Place wrote:
> Nils was referring to TTRamp, which is an audio generator in the DSP lib.  Regarding the control-rate ramp, I think we should create a wiki page for this, as it is an obvious need that I think we are very likely to try implementing in the next 12-18 months.

Tim:
Is this ramp being used for enveloping at all?  If so, I would agree with Trond and vote for A.  I actually had a similar issue with my panning object years ago.  The zeroth sample didn't start at 0. and therefore you would get a little bit of sound when you didn't want it.  

That's my 2 cents.  If I am misunderstanding its function, fill me in on more details.

--Nathan
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Trond Lossius
Administrator
In reply to this post by Timothy Place-2
Hi,

in the audio case, supposing that we are able to trigger the ramp with the same kind of messages as for control rate, and we send the following messages:

        /parameter 0
        WAIT 1000
        /parameter 1 ramp 1000

IMHO the sample at exactly 1000 ms (the first sample after we have requested the ramp to start) should be 0., not the next incremental value towards According to Nils' list of options, that would be alternative A. I'll try to explain why I believe this to be the best. Assume that we do not want to wait, but instead send to messages just after each other:

        /parameter 0
        /parameter 1 ramp 1000

Now, assume that this is used to traverse a window function at audio rate. In this case it is important to be sure that we start from the very beginning of the window, not a little bit into it. To ensure that, we need to know for sure that the first sample value is the start value 0.


Best,
Trond



On Mar 17, 2011, at 1:45 AM, Timothy Place wrote:

> Nils was referring to TTRamp, which is an audio generator in the DSP lib.  Regarding the control-rate ramp, I think we should create a wiki page for this, as it is an obvious need that I think we are very likely to try implementing in the next 12-18 months.
>
> best,
>   Tim
>
>
> On Wed, Mar 16, 2011 at 5:50 PM, Trond Lossius <[hidden email]> wrote:
> Hi,
>
> Coming in late on the discussion, IMHO ramps should behave as much as possible the way they would if happening at signal rate. So in Adrian's example:
>
>    /parameter 0 ramp 1000
>     WAIT 1000
>     /parameter 1 ramp 1000
>
> Assuming that ramp is producing output every 20 ms, I would expect this to yield:
>
> 0 ms            =>      0.
> 1000 ms         =>      0.
> 1020 ms         =>      0.02
> 1040 ms         =>      0.04
> 1060 ms         =>      0.06
> ....
> 1960 ms         =>      0.196
> 1980 ms         =>      0.198
> 2000 ms         =>      2.0
>
> Next one could discuss if the seemingly redundant value at 1000 ms should be output or not. For me this would depend on the value of @repetitions/allow.
>
>
> Best,
> Trond
>
>
>
> On Mar 16, 2011, at 11:08 PM, adrian.g wrote:
>
> > Hi,
> >
> > Are we talking about some internal representation of the ramp within the object or about actual behaviour? Does option b. mean that at time 0 of a ramp from 0 to 1 the value would be (as in the example) 0.0156250000?
> >
> > If so, consider this:
> >
> > initial parameter value is 1
> >
> > in a CueScript we have the following:
> >
> >      /parameter 0 ramp 1000
> >      WAIT 1000
> >      /parameter 1 ramp 1000
> >
> > I imagine that at 1000 ms after triggering the script the value should be: 0 and at 2000 ms: 1
> >
> > but if I understand it correctly, in case b. at time 1000 ms the value would reach 0 and then immediately (at the same logical time) jump to first larger than zero (e.g. 0.0156250000) and continue the ramp from there.
> >
> > Am I understanding things right?
> >
> > best
> >
> > Adrian
> >
> >
> >
> >
> > On Wed, Mar 16, 2011 at 9:39 PM, jln [via Jamoma Forums/Mailing lists] <[hidden email]> wrote:
> > I also vote for B. No objection.
> >
> > Best,
> > Julien
> >
> >
> > Le 16 mars 2011 à 22:35, Timothy Place a écrit :
> >
> >> I concur.  Let's go with B.  Any who object to this, make your objections known now!
> >>
> >> best,
> >>   Tim
> >>
> >>
> >> On Wed, Mar 16, 2011 at 2:13 PM, Nils Peters <[hidden email]> wrote:
> >> On 11-03-16 7:12 PM, Timothy Place wrote:
> >> > On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]
> >> > <mailto:[hidden email]>> wrote:
> >> >
> >> >     Hi,
> >> >
> >> >     I am working on a unit test for TTRamp and now I have a design question.
> >> >     If currentValue 0.0 and destinationValue 1.0, what should be the first
> >> >     and last sample of the ramp function?
> >> >
> >> >     is th eramp function going from
> >> >
> >> >     a) 0.0 .... 1.0
> >> >     b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
> >> >     c) the first increment larger than zero (e.g. 0.0156250000) ... one
> >> >     increment before one (e.g. 0.9843750000)
> >> >
> >> >     any comment?
> >> >
> >> >
> >> > Option (c) is definitely wrong -- it should end at the destination value
> >>
> >> Option (c) is currently the way it works. And I don't like it either.
> >> I think I am preferring b), because that's what the parameter name
> >> "currentValue" suggests.
> >> If we opt for a), we should change the parameter to startValue or sth.
> >> like that.
> >>
> >> --nils
> >>
> >> ------------------------------------------------------------------------------
> >> Colocation vs. Managed Hosting
> >> A question and answer guide to determining the best fit
> >> for your organization - today and in the future.
> >> http://p.sf.net/sfu/internap-sfd2d
> >> _______________________________________________
> >> Jamoma-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
> >>
> >> ------------------------------------------------------------------------------
> >> Colocation vs. Managed Hosting
> >> A question and answer guide to determining the best fit
> >> for your organization - today and in the future.
> >> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> >> Jamoma-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
> >
> >
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Jamoma-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/jamoma-devel
> >
> >
> > If you reply to this email, your message will be added to the discussion below:
> > http://jamoma-forums-mailing-lists.3076123.n2.nabble.com/TTRamp-design-question-tp6178139p6178988.html
> > To start a new topic under Jamoma Development, email [hidden email]
> >
> >
> >
> > --
> > Adrian Gierakowski
> >
> > View this message in context: Re: TTRamp design question
> > Sent from the Jamoma Development mailing list archive at Nabble.com.
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> > Jamoma-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Nathan Wolek-2
Trond: windowing/enveloping is exactly the issue I was trying to raise in my post.  I am in agreement with you.

--Nathan

On Mar 17, 2011, at 9:08 AM, Trond Lossius wrote:
> Now, assume that this is used to traverse a window function at audio rate. In this case it is important to be sure that we start from the very beginning of the window, not a little bit into it. To ensure that, we need to know for sure that the first sample value is the start value 0.


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

adrian.g
Administrator
Hi all,

I agree with Trond, and I think there is no reason why control rate ramps should behave differently then audio rate ramps. The control ramp should only increment only after the first time grain (for example after 20 ms if that is the current granularity) from when it has been triggered, and not instantly jump to the next increment.

just my point of view though.

best

Adrian

On Thu, Mar 17, 2011 at 1:20 PM, Nathan Wolek-2 [via Jamoma Forums/Mailing lists] <[hidden email]> wrote:
Trond: windowing/enveloping is exactly the issue I was trying to raise in my post.  I am in agreement with you.

--Nathan

On Mar 17, 2011, at 9:08 AM, Trond Lossius wrote:
> Now, assume that this is used to traverse a window function at audio rate. In this case it is important to be sure that we start from the very beginning of the window, not a little bit into it. To ensure that, we need to know for sure that the first sample value is the start value 0.


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel



If you reply to this email, your message will be added to the discussion below:
http://jamoma-forums-mailing-lists.3076123.n2.nabble.com/TTRamp-design-question-tp6178139p6180841.html
To start a new topic under Jamoma Development, email [hidden email]
To unsubscribe from Jamoma Development, click here.



--
Adrian Gierakowski
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Timothy Place-2
In reply to this post by Trond Lossius
Thanks Trond -- that seems clear enough and also very reasonable.

Just to be difficult, I'll point out that in the case of Jamoma modular we are sending these message asynchronously and typically on a different thread than the audio is using for calculation.  So if you send a message to begin ramping, it will likely not start instantaneously and will be several samples later.  Maybe even a vectorsize or more. 

So the situation we've been discussing, from a pragmatic perspective, is somewhat academic.

That said, I think we should add some new functionality to TTRamp.  Namely, I think we should be able to trigger ramp start and stop with an audio signal.  This new scenario does demand the sample 0 behavior that you (and Nathan) are mentioning.

So Nils, my vote has changed to option A :-).

I guess we need a Redmine ticket for triggering with an audio signal too?

best,
  Tim


On Thu, Mar 17, 2011 at 8:08 AM, Trond Lossius <[hidden email]> wrote:
Hi,

in the audio case, supposing that we are able to trigger the ramp with the same kind of messages as for control rate, and we send the following messages:

       /parameter 0
       WAIT 1000
       /parameter 1 ramp 1000

IMHO the sample at exactly 1000 ms (the first sample after we have requested the ramp to start) should be 0., not the next incremental value towards According to Nils' list of options, that would be alternative A. I'll try to explain why I believe this to be the best. Assume that we do not want to wait, but instead send to messages just after each other:

       /parameter 0
       /parameter 1 ramp 1000

Now, assume that this is used to traverse a window function at audio rate. In this case it is important to be sure that we start from the very beginning of the window, not a little bit into it. To ensure that, we need to know for sure that the first sample value is the start value 0.


Best,
Trond



On Mar 17, 2011, at 1:45 AM, Timothy Place wrote:

> Nils was referring to TTRamp, which is an audio generator in the DSP lib.  Regarding the control-rate ramp, I think we should create a wiki page for this, as it is an obvious need that I think we are very likely to try implementing in the next 12-18 months.
>
> best,
>   Tim
>
>
> On Wed, Mar 16, 2011 at 5:50 PM, Trond Lossius <[hidden email]> wrote:
> Hi,
>
> Coming in late on the discussion, IMHO ramps should behave as much as possible the way they would if happening at signal rate. So in Adrian's example:
>
>    /parameter 0 ramp 1000
>     WAIT 1000
>     /parameter 1 ramp 1000
>
> Assuming that ramp is producing output every 20 ms, I would expect this to yield:
>
> 0 ms            =>      0.
> 1000 ms         =>      0.
> 1020 ms         =>      0.02
> 1040 ms         =>      0.04
> 1060 ms         =>      0.06
> ....
> 1960 ms         =>      0.196
> 1980 ms         =>      0.198
> 2000 ms         =>      2.0
>
> Next one could discuss if the seemingly redundant value at 1000 ms should be output or not. For me this would depend on the value of @repetitions/allow.
>
>
> Best,
> Trond
>
>
>
> On Mar 16, 2011, at 11:08 PM, adrian.g wrote:
>
> > Hi,
> >
> > Are we talking about some internal representation of the ramp within the object or about actual behaviour? Does option b. mean that at time 0 of a ramp from 0 to 1 the value would be (as in the example) 0.0156250000?
> >
> > If so, consider this:
> >
> > initial parameter value is 1
> >
> > in a CueScript we have the following:
> >
> >      /parameter 0 ramp 1000
> >      WAIT 1000
> >      /parameter 1 ramp 1000
> >
> > I imagine that at 1000 ms after triggering the script the value should be: 0 and at 2000 ms: 1
> >
> > but if I understand it correctly, in case b. at time 1000 ms the value would reach 0 and then immediately (at the same logical time) jump to first larger than zero (e.g. 0.0156250000) and continue the ramp from there.
> >
> > Am I understanding things right?
> >
> > best
> >
> > Adrian
> >
> >
> >
> >
> > On Wed, Mar 16, 2011 at 9:39 PM, jln [via Jamoma Forums/Mailing lists] <[hidden email]> wrote:
> > I also vote for B. No objection.
> >
> > Best,
> > Julien
> >
> >
> > Le 16 mars 2011 à 22:35, Timothy Place a écrit :
> >
> >> I concur.  Let's go with B.  Any who object to this, make your objections known now!
> >>
> >> best,
> >>   Tim
> >>
> >>
> >> On Wed, Mar 16, 2011 at 2:13 PM, Nils Peters <[hidden email]> wrote:
> >> On 11-03-16 7:12 PM, Timothy Place wrote:
> >> > On Wed, Mar 16, 2011 at 12:39 PM, Nils Peters <[hidden email]
> >> > <mailto:[hidden email]>> wrote:
> >> >
> >> >     Hi,
> >> >
> >> >     I am working on a unit test for TTRamp and now I have a design question.
> >> >     If currentValue 0.0 and destinationValue 1.0, what should be the first
> >> >     and last sample of the ramp function?
> >> >
> >> >     is th eramp function going from
> >> >
> >> >     a) 0.0 .... 1.0
> >> >     b) the first increment larger than zero (e.g. 0.0156250000) ... 1.0
> >> >     c) the first increment larger than zero (e.g. 0.0156250000) ... one
> >> >     increment before one (e.g. 0.9843750000)
> >> >
> >> >     any comment?
> >> >
> >> >
> >> > Option (c) is definitely wrong -- it should end at the destination value
> >>
> >> Option (c) is currently the way it works. And I don't like it either.
> >> I think I am preferring b), because that's what the parameter name
> >> "currentValue" suggests.
> >> If we opt for a), we should change the parameter to startValue or sth.
> >> like that.
> >>
> >> --nils
> >>
> >> ------------------------------------------------------------------------------
> >> Colocation vs. Managed Hosting
> >> A question and answer guide to determining the best fit
> >> for your organization - today and in the future.
> >> http://p.sf.net/sfu/internap-sfd2d
> >> _______________________________________________
> >> Jamoma-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
> >>
> >> ------------------------------------------------------------------------------
> >> Colocation vs. Managed Hosting
> >> A question and answer guide to determining the best fit
> >> for your organization - today and in the future.
> >> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> >> Jamoma-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
> >
> >
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Jamoma-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/jamoma-devel
> >
> >
> > If you reply to this email, your message will be added to the discussion below:
> > http://jamoma-forums-mailing-lists.3076123.n2.nabble.com/TTRamp-design-question-tp6178139p6178988.html
> > To start a new topic under Jamoma Development, email [hidden email]
> >
> >
> >
> > --
> > Adrian Gierakowski
> >
> > View this message in context: Re: TTRamp design question
> > Sent from the Jamoma Development mailing list archive at Nabble.com.
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> > Jamoma-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>



------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Nils Peters
On 11-03-17 2:57 PM, Timothy Place wrote:
> So Nils, my vote has changed to option A :-).

Yes, that's fine with me too.

As said before, I'd suggest to change the attribute "currentValue" to
"startValue" and make the proper calculations.


--nils

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Trond Lossius
Administrator
In reply to this post by Timothy Place-2
Hi


> Thanks Trond -- that seems clear enough and also very reasonable.

Thanks!

:-)

> Just to be difficult, I'll point out that in the case of Jamoma modular we are sending these message asynchronously and typically on a different thread than the audio is using for calculation.  So if you send a message to begin ramping, it will likely not start instantaneously and will be several samples later.  Maybe even a vectorsize or more.  
>
> So the situation we've been discussing, from a pragmatic perspective, is somewhat academic.

It's not as academic as it might seem. It's true that there might be a delay in the convertion from control to sample rate, but if sending two messages in immedeate sequence:

       /parameter 0
       /parameter 1 ramp 1000

I would still expect both of them to be triggered from the same sample onwards. At least that's what I would expect if having a message box containing "0, 1 1000"  connected to line~.

Also we should bear in mind that the C++ frameworks eventually might be used with other environments then Max, e.g. Csound, where k-rate might be set to a, effectively turning control-rate into being sample-accurate.

And finally, could we imagine at some point in the future that Jamoma Graph might be driven by a different scheduler to the Max clock, and hence have a different mechanism for syncing control rate processes to signal rate? My guess is that Jamoma Graph at the time being don't have a clock at all?

> That said, I think we should add some new functionality to TTRamp.  Namely, I think we should be able to trigger ramp start and stop with an audio signal.  This new scenario does demand the sample 0 behavior that you (and Nathan) are mentioning.

I agree!

Best,
Trond
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Timothy Place-2
On Thu, Mar 17, 2011 at 2:40 PM, Trond Lossius <[hidden email]> wrote:
Hi


> Thanks Trond -- that seems clear enough and also very reasonable.

Thanks!

:-)

> Just to be difficult, I'll point out that in the case of Jamoma modular we are sending these message asynchronously and typically on a different thread than the audio is using for calculation.  So if you send a message to begin ramping, it will likely not start instantaneously and will be several samples later.  Maybe even a vectorsize or more.
>
> So the situation we've been discussing, from a pragmatic perspective, is somewhat academic.

It's not as academic as it might seem. It's true that there might be a delay in the convertion from control to sample rate, but if sending two messages in immedeate sequence:

      /parameter 0
      /parameter 1 ramp 1000

I would still expect both of them to be triggered from the same sample onwards. At least that's what I would expect if having a message box containing "0, 1 1000"  connected to line~.

You cannot count on this.  Any thread can interrupt the other at any time.  The setting of parameter to 0, all by itself, could be interrupted in the middle of doing this in order to calculate a whole vector of audio, backing-up a fragment of your computer, downloading part of an email, and then coming back to finish setting the parameter to zero.  Then it moves on to the ramp message, which is more involved and more likely to be interrupted.

In an environment other than Max, the rules could be entirely different in terms of how things are handled.  Most likely though, regardless of the environment, for anything working in realtime, the audio will be on a different thread than the control messages.

The Csound example is a good point: yes, it could be different if it is operating outside of realtime.


Also we should bear in mind that the C++ frameworks eventually might be used with other environments then Max, e.g. Csound, where k-rate might be set to a, effectively turning control-rate into being sample-accurate.

And finally, could we imagine at some point in the future that Jamoma Graph might be driven by a different scheduler to the Max clock, and hence have a different mechanism for syncing control rate processes to signal rate? My guess is that Jamoma Graph at the time being don't have a clock at all?

For the moment there is no scheduler to drive Jamoma Graph independently of Max.  This is needed in a number of case for porting Hipno to Plugtastic though.  This is where my vague allusion to a control rate ramp in the next 12-18 months was rooted.

From sunny KC at 24ºC :-),
   Tim


> That said, I think we should add some new functionality to TTRamp.  Namely, I think we should be able to trigger ramp start and stop with an audio signal.  This new scenario does demand the sample 0 behavior that you (and Nathan) are mentioning.

I agree!

Best,
Trond
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|

Re: TTRamp design question

Nils Peters
On 11-03-17 9:46 PM, Timothy Place wrote:

>     Also we should bear in mind that the C++ frameworks eventually might
>     be used with other environments then Max, e.g. Csound, where k-rate
>     might be set to a, effectively turning control-rate into being
>     sample-accurate.
>
>     And finally, could we imagine at some point in the future that
>     Jamoma Graph might be driven by a different scheduler to the Max
>     clock, and hence have a different mechanism for syncing control rate
>     processes to signal rate? My guess is that Jamoma Graph at the time
>     being don't have a clock at all?
>
>
> For the moment there is no scheduler to drive Jamoma Graph independently
> of Max.  This is needed in a number of case for porting Hipno to
> Plugtastic though.  This is where my vague allusion to a control rate
> ramp in the next 12-18 months was rooted.

One thought about the k-rate Graph: Would it be possible to run a second
AudioGraph in a very low sample rate (e.g. 10 Hz) for continuously
changing control messages?

--nils

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel