Re: NRT options Part II

Good point, I didn't think of that.

Perhaps it would be best to just do the original one I had mentioned (with a simple duration argument).

The more I think about it, the more the start seems less than ideal... 

> I think it would be maybe most beneficial to simple have a method that
> returns a new score with the desired range. This score you can then record.
> as you have to copy the messages anyway, this wouldn't be any less efficient.

This also makes sense.  Probably better not to mess with recordNRT and approach it this way. 

I may try to do something like what Julian suggests, along with keeping all events at time 0.0. (I don't know about anyone else, but this is usually where I set up groups and buffers for NRT). It does seem like, once the start time changes, all sorts of things can become a problem. For now I will put something together that simply truncates a score, and think more about altering start times.

Thanks James and Julian.

Josh

On Aug 18, 2004, at 2:11 PM, James McCartney wrote:

> On Aug 18, 2004, at 12:28 PM, Joshua Parmenter wrote:
>
> > Obviously, this doesn't  render any events that start BEFORE the start time
>
> The problem with this is that you will miss any configuration events at the beginning, like setting up groups for example.
>
> -- 
> --- james mccartney   james-M9HdPQXNfxq9Zq0HfjR8jw@xxxxxxxxxxxxxxxx   <http://www.audiosynth.com>
> SuperCollider - a real time audio synthesis programming language
>
> _______________________________________________
> sc-dev mailing list
> sc-dev-Ayv8T2snMLBt9CRQqspbbg@xxxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev
_______________________________________________
sc-dev mailing list
sc-dev-Ayv8T2snMLBt9CRQqspbbg@xxxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-dev