September 2005 - chuck-dev - lists.cs.princeton.edu

JACK correctness part IX (callback vs. blocking)
by Ge Wang 28 Sep '05

28 Sep '05

Greetings! On the recommendation of Dave Robillard, Florian Schmidt, and other Linux audio developers, we have implemented callback functionality for real-time audio, while keeping the blocking functionality. Both are accessible using command line flags (--callback vs. --blocking). The default is callback. Perhaps not surprisingly, this is much more stable for small buffersize on all platforms except windows directsound. Hopefully, it is a step in the right direction for alleviating problems running chuck under Linux/JACK. The newest version is in CVS: cvs -d :ext:anon-chuck@cvs.cs.princeton.edu:/cvs checkout chuck_dev password: (hit enter) The code is in chuck_dev/v2/ I must admit that I don't know Jack and would like to ask Linux/Jack users here to give it a spin under various conditions. Please let us know how things fare. Dave, Florian, Leonard - can you guys give this a try? Thank you very much! Best, Ge!

3 3

Bug+Fix: Various combinations of virtual functions and base-class variable references fail.
by Robin Davies 26 Sep '05

26 Sep '05

Problem: Various legal constructs in extended classes fail to compile, particularly references to base class members and methods. References to global variables in constructor code also fails. See the test file given below. Fix: chuck-emit.cpp line 3303 delete 3303 < assert( v->owner_class == emit->env->class_def ); chuck-type.cpp line 1758 < if( !env->class_def || env->class_scope > 0 ) > if( !env->class_def) Discussion: The assert is incorrect. The reference may be to a base-class member, (or perhaps a global variable. I'm not sure about that). It may be better to replace the assert with something like: assert(is_parent_type(emit->env->class_def,v->owner_class) || is_global_type(v->owner_class) ) (neither function currently avaialble). The second fix is more difficult. Generally, we want the test to fail and go to the else clause which searches class scope for the variable if we're in a class definition. I don't understand the purpose of the test on class_scope, which is certainly incorrect, whatever it's supposed to do. What I do know: class_scope is zero in constructor code, and increments for each nested scope (function, code block &c) in the code at this point. If the intention is to prevent references to base class or global variables in constructure code, then it would be "env->class_scope == 0" (sense inverted); but this seems like an arbitrary restriction on a perfectly useful functionality, and removing the test altogether doesn't seem to cause problems in code generation. References to global variables and variables in the current scope seem to be caught before this (which, thinking about it, suggests that global variable references will take precedence over base-class references, which is incorrect -- possibly another bug). The main issue seems to be base-class references. Deleting the || test seems to correct the scanning pass, and the generated code passes the test case given below. With respect to global and base-class variables with the same name, I wrote a test for this case (see ScopeTest-11 tests below). The test succeeds, with the above patches applied. Both type checking and code generation seem to work. So I'm not going to hunt further. Test case for the fix: ScopeTest.ck ///////////////////////////// // ScopeTest.ck // Test Scoping of variables and virtual functions in extended classes. // ///////////////////////////// function void Assert(int condition, string message) { if (!condition) { <<< "Assert Failed: ", message >>>; } } 1 => int globalVariable; Assert(globalVariable == 1,"ScopeTest-1 Global Assignment"); string globalAndBaseclassVariable; class Base { int globalAndBaseclassVariable; 2 => globalVariable; Assert(globalVariable == 2,"ScopeTest-2 Global Assignment from constructor."); 3 => int v; Assert(v == 3,"ScopeTest-3 Assigment to class variable in ctor"); function int GetV() { return v; } function int GetVVirtual() { return v; } } class Super extends Base { 4 => int v2; Assert(v2 == 4,"ScopeTest-4 Assigment to class scope from extended class."); 5 => v; Assert(v == 5, "ScopeTest-5 Assignment to variable in superclass."); 6 => v; Assert(GetV() == 6, "ScopeTest-6 Assignment to variable in superclass."); 7 => globalVariable; Assert(globalVariable == 7, "ScopeTest-7 assignement to global variable in extended class"); function int Test() { return GetV(); } function int GetVVirtual() { return v2; } function int GetglobalAndBaseclassVariable() { return globalAndBaseclassVariable; } } Base b; Assert(globalVariable == 2, "ScopeTest-2.1 constructor side-effects in global scope."); Super s; Assert(globalVariable == 7, "ScopeTest-7.1 superclass constructor side-effects in global scope."); 8 => b.v; Assert(b.v == b.GetV(),"ScopeTest-8 assigment to class-scope variable."); 9 => s.v; Assert(s.v == s.GetV(),"ScopeTest-9 assigment to base-class-scope variable."); 10 => s.v2; Assert(s.v == s.GetV(),"ScopeTest-10 assigment to super-class-scope variable."); Assert(s.v2 == 10,"ScopeTest-10.1 assigment to super-class-scope variable."); Assert(s.v2 == s.GetVVirtual(),"ScopeTest-10.1 virtual function resolution."); "110" => globalAndBaseclassVariable; 111 => s.globalAndBaseclassVariable; Assert(globalAndBaseclassVariable == "110","ScopeTest-11.1 aliased global and base-class variable."); Assert(s.GetglobalAndBaseclassVariable() == 111,"ScopeTest-11.2 aliased global and base-class variable."); Assert(s.globalAndBaseclassVariable() == 111,"ScopeTest-11.3 aliased global and base-class variable.");

2 1

Bug: Incorrect scanning of nested classes.
by Robin Davies 26 Sep '05

26 Sep '05

The following code : public class Instrument { class IInstrument { } } produces the following error. [t.ck]:line(25): class/type 'IInstrument' is already defined in namespace 'Instrument' The fix: ChuckScan.cpp line 1225: < ret = type_engine_scan0_class_def( env, body->section->class_def ); > ret = type_engine_scan1_class_def( env, body->section->class_def ); Rationale: The nested class has already had scan0 peformed during scan0 of the parent class. This call is made during scan1 processing, and should perform scan1 processing. Note that the other two cases in this switch perform scan1 processing, not scan0 processing. Please review the fix for correctness. I'm 98% sure it's correct. Regards, Robin Davies.

2 1

RE: [chuck-dev] Block execution of ugens?
by Robin Davies 06 Sep '05

06 Sep '05

> 1) detect/mark cycles in the ugen graph when changing connections > 2) when computing samples, nodes in cycles still compute > sample at a time, while the rest can compute in blocks. > 3) furthermore, non-cyclic nodes need to be partitioned > and sorted. subgraphs that a cycle depend on must compute > the block before the first sample of that cycle computes. > 4) We may be able to further optimize if delay-lines are involved > in the cycle. <thinking hat off for a sec...> Interesting problem. I thought it was trivial until I realized that there may be multiple loops with multiple minimum block sizes. However, it may be trivially doable after a little non-trivial thinking. I was going to ask whether circular chucks was a feature you were particularly attached to, when I saw somebody posting about the fun they were having with delays and echos. And then, in a blinding flash of insight, I understood why the Stk Echo doesn't have a feeback property. (echo echo echo echo). <... thinking hat back on> - Robin Davies.

1 0

Block execution of ugens?
by Robin Davies 02 Sep '05

02 Sep '05

ok.. I've been happily hacking away at Chuck 1.2.0.0 sources, with good results so far. I have a set of band-limited oscillaters: currently, bltsawosc, bltsqrosc, and blitosc (impulse train), based on "Alias-Free Digital Synthesis of Classic Analog WaveForms", Stilson/Smith. Also, buzzosc -- a band-limited DSF, similar to SAOL and CSound buzz. All are ready and waiting for access to the load function. I'll probably drop in a bltrectosc (with a width control), soon, as well. (You can have them now, if you like -- a .cpp and .h file, with a query function to register the ugens, all in the same style as current ugens; but I'd like to do a little more testing if you do want it now). Next on the slab: VSTs. And there, things didn't go so well. The key issue is the VSTs like to operate on blocks of audio data rather than running sample at a time. This isn't a huge problem with VST instruments: fetching data in small blocks (say 30 or 40 samples at a time) introduces a small (< 1ms) disconnect between controls and generated audio. But buffering input and output of effects probably isn't going to work as well. I'm really not confident that delaying audio effect output isn't going to produce odd side-effects. I supposed it is possible to try running VSTs one sample at a time. I may give this a try, anyway, in the meantime. But, having written a few VSTs, I don't think I'd be happy if somebody called my VSTs one sample at a time. This probably isn't a priority for you guys right now, but I'd like to raise the idea anyway. What do you think about converting Chuck_VM::run( ) to execute Ugens on blocks of samples at a time? As far as I can see, it's do-able. And the across-the-board performance gains would probably be worth the effort. Roughly, I think the revised code would look like this: #define MAX_UGEN_BLOCKSIZE 32 // or so while( m_running ) run shreds for 1 tick broadcast queued events determine how many ticks we can run ugens for: int ugenBlockSize; if (shreds active) { ugenblocksize = 1; } else { ugenblocksize = min(MAX_UGEN_BLOCKSIZE,ticks_to_next_shred()) } Run_ugens(ugenblocksize); process messages } Ugens would be modified to have input and output buffers of SAMPLE[MAX_UGEN_BLOCKSIZE). Existing UGens would inherit a method that converts Ugen block ticks into single-cycle ticks. The only breaking change I can see is Ugens that are chucked into loops, which is, I think, legal in the current implementation, but would work with buffered input. I seem to remember seeing a mention of this somewhere in the docs. I imagine this might significantly complicate the implementation of ugens written in chuck, too. I'm not sure that I have any decent theories as to how that one would be tackled. (Separate schreduling queues for UGEN tick methods, maybe?) I'm willing to take a crack at an experimental version some time, but I don't imagine your sources are too stable right now. I'd be a bit concerned about making this kind of wide-ranging change on a very active source tree, with no prospect of ever being able to merge it back into mainline sources. Thoughts?

2 1