I def agree leave as is.

I've been starting to play around with some line / transeg guided tablemix
stuff, & although the termination value of the line is under certain
conditions never reached (dependent on the krate factors discussed) the
point should be to map a trajectory to time, & krate just pulls the
interpolated values.

If the line trajectory is defined from p fields, & destination values are
then used as an init value for transmission of further line "segments",
timed in turn to to coincide with the previous line trajectory's termination
time, then this should ensure a percieved "continuity" between sucessive
trajectories...

at least i am hoping this will be the case, as i'm planning on exploiting
this extensively, & i wouldn't want any changes to complicate this type of
implementation.




-----
*******************
www.phasetransitions.net
hermetic music * python * csound * possibly mindless ranting
various werk in perpetual delusions of progress....

-- 
View this message in context: http://www.nabble.com/line-opcode-and-ksmps-tp15685283p15704967.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi steven

this is a timely discussion for me, as not only am i dealing with the same
issues, it highlights that in blue, as in my parseval scripts controlled
instruments, the same use of interpolating lines supplying gk (&/ or ga)
values is the basic modus operandi (& someone else posted to this effect a
week or 2 ago, I made some off the cuff enquiry about "finding out more".
Although we all get to "roll our own", i still wonder to what extent our
doobies are all smoking along the same lines, so to speak...)

That's why i have previously suggested that, in theory a blue instrument & a
parseval instrument could be  interchangeable - which would also mean that
possibly i am somehow creating / promoting a higher level score syntax that
sits somewhere between csound sco & the "Graphic Display" of csound score
via a Blue GUI interface display..(as opposed to the more "conventional"
interpretation of the blue GUI interface creating the csound score.. i'm
looking at it more "bottom up" - does that make sense?)

all high levels of compatability & interchangeability based on the adoption
simply of using gk & ga to allow for "user / custom score control" over any
so defined parameter... 

the point you make below therefore is a particularly timely one for me.
basically if the trajectory becomes "inactive" at any point, the inactivity
should be "punctuated" with an initialisation to the final value... an extra
step, but possibly worth it in the context of everything else achieved via
this method so far...

anyway, enough heart warming consensus... thanks for posting about this.


Steven Yi wrote:
> 
> Regarding the slope of the line, yes, it would become dependent on
> ksmps, but one thing to note is that once ksmps=1, either method
> should virtually get to the same point at the same time.  When ksmps >
> 1, that's where things diverge.
> 
> The problem is that this is resulting in automation values in blue,
> which uses a single instrument writing to gk signals, like:
> 
> instr 3
> gk_some_val line p4, p3, p5
> endin
> 
> Other instruments use the gk signal.  If an automation goes to p5 but
> doesn't reach it, it stays at that last value as the project
> continues.
> 
> Hmm.... I'm guess then in theory, if we want things to be sample
> accurate we need to either use a-sigs or ksmps=1, and it is correct
> that the slope be maintained and this is all just an artifact of
> sampling a continuous signal.  In Tim's reply he mentions when line
> segments are joined the the next line should get it to the full value
> which I think is correct, just that the problem occurs when the value
> from the last line in a number of segments is held.
> 
> I'm thinking that for a solution then is that I need to change blue's
> behavior where a line value is held that instead of not generating a
> value to generate a note that set the final value and turn itself off.
>  That's probably the most accurate solution then.
> 
> Thanks everyone for the discussion!  I'm going to proceed with this.
> 
> steven
> 
> 
> On Tue, Feb 26, 2008 at 8:48 AM, Andres Cabrera 
> wrote:
>> Hi Drake,
>>
>>
>>  On Tue, Feb 26, 2008 at 10:03 AM, Drake Wilson 
>> wrote:
>>  > Quoth Andres Cabrera , on 2008-02-26 08:44:23
>> -0500:
>>  >
>>
>> >  Using fully closed intervals for values like that creates subtle
>>  >  semantic problems because they don't stack on top of each other
>>  >  properly.  (This is related to one of the reasons people index arrays
>>  >  from 0.)  I don't think that would be more predictable, per se,
>>  >  especially since the actual slope of the line would depend on the
>>  >  value of ksmps (!).  The stacking is the case where a line from 0 to
>> 1
>>  >  over 1 second followed by a line from 1 to 2 over 1 second doesn't
>>  >  connect together as a line but rather has a weird 1/kr hold period in
>>  >  between.
>>  >
>>  You´re right, predictable is not a good word, I meant something like
>>  expected, as a user would expect the line to get to a certain value,
>>  and in the current state it may not.
>>
>>
>>  >  I would vote to make it take a half-open interval and clarify that in
>>  >  the documentation; if you need the closed interval at k-rate,
>> subtract
>>  >  1/kr from the duration (or add 1/kr to the duration of everything
>>  >  else).
>>
>>  You're probably right that the best approach is probably leave it as
>>  it is, and make a note in the docs.
>>
>>  Cheers,
>>  Andrés
>>
>>
>>
>> 
>> -------------------------------------------------------------------------
>>  This SF.net email is sponsored by: Microsoft
>>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>  _______________________________________________
>>  Csound-devel mailing list
>>  Csound-devel@lists.sourceforge.net
>>  https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 


-----
*******************
www.phasetransitions.net
hermetic music * python * csound * possibly mindless ranting
various werk in perpetual delusions of progress....

-- 
View this message in context: http://www.nabble.com/line-opcode-and-ksmps-tp15685283p15710152.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cso

Steven Yi wrote:
> Regarding the slope of the line, yes, it would become dependent on
> ksmps, but one thing to note is that once ksmps=1, either method
> should virtually get to the same point at the same time.  When ksmps >
> 1, that's where things diverge.
> 
> The problem is that this is resulting in automation values in blue,
> which uses a single instrument writing to gk signals, like:
> 
> instr 3
> gk_some_val line p4, p3, p5
> endin

what about:

instr 3
gk_some_val line p4, p3-1/kr, p5
endin

> Other instruments use the gk signal.  If an automation goes to p5 but
> doesn't reach it, it stays at that last value as the project
> continues.
> 
> Hmm.... I'm guess then in theory, if we want things to be sample
> accurate we need to either use a-sigs or ksmps=1, and it is correct
> that the slope be maintained and this is all just an artifact of
> sampling a continuous signal.  In Tim's reply he mentions when line
> segments are joined the the next line should get it to the full value
> which I think is correct, just that the problem occurs when the value
> from the last line in a number of segments is held.
> 
> I'm thinking that for a solution then is that I need to change blue's
> behavior where a line value is held that instead of not generating a
> value to generate a note that set the final value and turn itself off.
>  That's probably the most accurate solution then.
> 
> Thanks everyone for the discussion!  I'm going to proceed with this.
> 
> steven
> 
> 
> On Tue, Feb 26, 2008 at 8:48 AM, Andres Cabrera  wrote:
>> Hi Drake,
>>
>>
>>  On Tue, Feb 26, 2008 at 10:03 AM, Drake Wilson  wrote:
>>  > Quoth Andres Cabrera , on 2008-02-26 08:44:23 -0500:
>>  >
>>
>>>  Using fully closed intervals for values like that creates subtle
>>  >  semantic problems because they don't stack on top of each other
>>  >  properly.  (This is related to one of the reasons people index arrays
>>  >  from 0.)  I don't think that would be more predictable, per se,
>>  >  especially since the actual slope of the line would depend on the
>>  >  value of ksmps (!).  The stacking is the case where a line from 0 to 1
>>  >  over 1 second followed by a line from 1 to 2 over 1 second doesn't
>>  >  connect together as a line but rather has a weird 1/kr hold period in
>>  >  between.
>>  >
>>  You´re right, predictable is not a good word, I meant something like
>>  expected, as a user would expect the line to get to a certain value,
>>  and in the current state it may not.
>>
>>
>>  >  I would vote to make it take a half-open interval and clarify that in
>>  >  the documentation; if you need the closed interval at k-rate, subtract
>>  >  1/kr from the duration (or add 1/kr to the duration of everything
>>  >  else).
>>
>>  You're probably right that the best approach is probably leave it as
>>  it is, and make a note in the docs.
>>
>>  Cheers,
>>  Andrés
>>
>>
>>
>>  -------------------------------------------------------------------------
>>  This SF.net email is sponsored by: Microsoft
>>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>  _______________________________________________
>>  Csound-devel mailing list
>>  Csound-devel@lists.sourceforge.net
>>  https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net