Kjetil S. Matheussen wrote:
Doing things like this is nice with my k_cext external: http://www.notam02.no/~kjetism/pd/bin/
The following patch does what you want:
#N canvas 56 333 589 504 10; #X obj 73 309 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -6 0 10 -262144 -1 -1 10 256; #X obj 297 311 nbx 5 14 -1e+37 1e+37 0 0 empty empty empty 0 -6 0 10 -262144 -1 -1 1000 256; #X msg 59 36 bang; #X obj 60 115 k_cext 7 2 0 0 10 1 100 1000 100 ; int i , j ; for(i=I(1) SC i<=I(2) SC i+=I(3)) BEGIN ; . for(j=I(4) SC j<=I(5) SC j+=I(6)) BEGIN ; . . O0(i) ; . . O1(j) ; . END ; END ;; #X connect 2 0 3 0; #X connect 3 0 0 0; #X connect 3 1 1 0;
Wow Kjetil, this is impressive. I do have a question about the initial input values to the iterator code, can they be attached to an inlet, and be adjusted at run time? I don't say real-time, as I don't expect to be changing the iterator limits or step in a performance situation. Does the 'I(1)' refer to the "creation argument" of that number or are the inlet assignments? (or both?)
Also, does the compiled object have to be compiled everytime that the patch is opened? Or are the object files (the ones linked to PD) kept around from run to run? If they do need to be recreated each time, how much time does this add to the loading?
Are you using this as a "prototyping" system, where you take the finished C code and turn it into a full-fledged external?
Mike