Re: [commit] crucial update

On Jul 31, 2004, at 8:51 PM, Scott Wilson wrote:

>
> On 31 Jul 2004, at 18:20, crucial felix wrote:
>
>>
>> addToDefName support removed
>
> Just playing around with some of the examples checking out the update, 
> and the > button in a gui caused an error.

which example ?
thanks.

> There's still a call to addToDefName in InstrSynthDef 
> *defNameFromObjects

that whole method can be turned off then.

-cxd

Re: more on additional optimization

On Jul 31, 2004, at 7:12 AM, Ronald J. Kuivila wrote:

> Hi again,
>
>
>>> The problem with this optimization is that creating the closure 
>>> object
>>> is more overhead than the if statement.
>>>
>
> I think my previous reply was too vague.  My question was, if the
> 'if' is faster, can't you make a special primitive to encapsulate:
>
> Stream-nextNotNil { arg event, func; var inEvent
>         if ((inEvent = this.next(event).notNil,
>                 {^inEvent}, func);
> }
>
> As a specialized 'if' (i.e. using whatever branching magic makes if 
> fast)?
>
> RJK
>

You can't write a primitive that requires dispatching to a method 
within it. A primitive truly must be a primitive operation.
I don't think there is much to be gained here anyway. Eliminating the 
extra Routines being created at each level was a huge savings. This is 
peanuts.

Re: unit block number

unit->mWorld->mBufCounter

On Jul 31, 2004, at 4:46 AM, ccos wrote:

> i have a ugen on the server which is incrementing a counter at every 
> control period starting at zero, but i seem to remember a message to 
> this list that said that this is already done somewhere, just can't 
> seem to locate it if it is.
>
> could i just be reading it or do i need to count myself?
>
> thanks,
> _c
>
> _______________________________________________
> sc-dev mailing list
> sc-dev <at> create.ucsb.edu
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev
>

_______________________________________________
sc-dev mailing list
@...
http://www.create.ucsb.edu/mailman/listinfo/sc-dev

Re: more on additional optimization

> within it. A primitive truly must be a primitive operation.
> I don't think there is much to be gained here anyway. Eliminating the
> extra Routines being created at each level was a huge savings. This is
> peanuts.
> You may not realize how your change actually helped. The major gain
> from your fix was not really that it saved executing more byte codes,
> it was eliminating time spent in the garbage collector due to
> allocating the 512 slot stacks for each new Routine. By embedding
> method calls rather than Routines, fewer Routines get allocated and so
> less scanning needs to be done in the GC.
>

I see, that makes sense.
Just to understand the primitive issue further.  It would be possible to
write such a method for a specific class (like Routine) but it would have
to explicitly execute the 'next' code itself, right?

RJK

Re: sc3: sync clocks?

tell us the method you are going to use.
There were talks at the OSC conference on this topic.

On Jul 31, 2004, at 10:33 AM, nonprivate cylob wrote:

> hi,
>
> a while ago i had the following problem: i have 2 macs networked, 
> using one
> to sequence and the other as a sound server. as osc messages have an
> absolute timestamp, any discrepancy between the 2 computer clocks 
> results in
> late/screwed around timing on the server. i worked out a way to sync 
> one
> computer to the other down to the last nanosecond without their clocks
> needing to being in time. i wondered if anyone else had done this, and 
> if
> not, i'll work towards making it a generalised class / gui thing if 
> there is
> any interest in this. if not no worries, just thought i'd ask before i 
> spend
> time on it.
>
> _______________________________________________
> sc-dev mailing list
> sc-dev <at> create.ucsb.edu
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev
>

Re: more on additional optimization

On Jul 31, 2004, at 7:54 PM, Ronald J. Kuivila wrote:

>  It would be possible to
> write such a method for a specific class (like Routine) but it would 
> have
> to explicitly execute the 'next' code itself, right?

I'm not sure I'm following you, but you can't call the interpreter to 
evaluate a method from within a primitive.

Re: !?

? and ?? have a use in assignment statements. I can't see how this is 
useful in assignment statements and it is less efficient than this:

if (a.notNil) { blah }

On Jul 31, 2004, at 6:34 AM, ccos wrote:

> it is related to ? and ??, as in not ?, or if it is not nil value the 
> rhs.
> maybe of interest, you guys want it added?
>
> + Object {
> 	!? { |rhs| ^rhs.value(this) }
> }
> + Nil {
> 	!? {}
> }
>
>
> 555 !? { |x| x * 2 }
> nil !? { 666 }
>
>
> _c
> _______________________________________________
> sc-dev mailing list
> sc-dev <at> create.ucsb.edu
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev

[commit] large virtual machine change

I just committed a large set of changes. No methods in the class 
library were removed or changed so nothing should break.
As a result of the following changes some code runs slightly faster, 
some code runs much faster such as Patterns, and some code is slightly 
slower.

All function and method frames are now heap allocated. Previously there 
was a hybrid heap+stack scheme. This was done for efficiency of GC 
reasons, but I have since discovered techniques to make heap allocation 
just or nearly as fast. As a result, the stack sizes for Routines can 
be much smaller by default, resulting in less GC scanning.
Also these changes will allow for future changes such as adding tail 
call optimization, a correct implementation of unwind-protect, and 
possibily even continuations.

The GC now has a trick to partially simulate generational collection so 
that live data that has survived previous collections is scanned less 
often.

new byte codes to make ? and ?? faster.
The function for ?? is inlined.

edited a couple of lines in crucial to allow ?? blocks to be inlined.

new byte codes to make these slightly faster:
if (someExpression.isNil)
and:
if (someExpression.notNil)

Re: [commit] crucial update

On 1 Aug 2004, at 01:18, crucial felix wrote:

>
> On Jul 31, 2004, at 8:51 PM, Scott Wilson wrote:
>
>>
>> On 31 Jul 2004, at 18:20, crucial felix wrote:
>>
>>>
>>> addToDefName support removed
>>
>> Just playing around with some of the examples checking out the 
>> update, and the > button in a gui caused an error.
>
> which example ?
> thanks.
>
I didn't trace it through or test a lot, but actually it seems to 
happen in anything that calls Patch.play.

S.

Re: [commit] crucial update

On Aug 1, 2004, at 11:04 AM, Scott Wilson wrote:
>>>
>>> Just playing around with some of the examples checking out the 
>>> update, and the > button in a gui caused an error.
>>
> I didn't trace it through or test a lot, but actually it seems to 
> happen in anything that calls Patch.play.

ok, got it.
cvs got "confused" about some file.

-cx