Here is a simple example: sr = 48000 ksmps = 32 nchnls = 1 0dbfs = 1 stack 100000 instr 1 a1 oscils 0.7, 220, 0 k1 line 0, p3, 1 push "blah", 123.45, a1, k1 push rnd(k(1)) k_rnd pop S01, i01, a01, k01 pop printf_i "S01 = '%s', i01 = %g\n", 1, S01, i01 ktrig metro 5.0 printf "k01 = %.3f, k_rnd = %.3f\n", ktrig, k01, k_rnd out a01 endin i 1 0 5 e On Friday 05 May 2006 05:32, Steven Yi wrote: > I'm trying to figure out what this would look like in code, and it > seems to be--as you said--a bit hackish. Would it look something > like: > > istack stack 50 > > push ival1, istack > push ival2, istack > push ival3, istack > ... > push ival4, istack > > myUDO ival1, ival2, ival3, ..., istack > > or > > istack myUDO > > ival1 pop istack > ival2 pop istack > ival3 pop istack > ival4 pop istack > ival5 pop istack > ... > > I guess it would save a little bit of typing versus using tableiw and > table with ftables and passing that back from a UDO, but then you > could at least use ftlen with the table to count the returned values > if you wanted to have a varying amount of items returned. I guess a > stackCount opcode could enable that too with a stack. > > But strictly in terms of programming techniques, this doesn't add any > new abilities than what can be done with ftables I think, so I'd say > it's not worth adding. What might be nice would be some UDO's for > making working with ftables a bit easier, so that work with them like > a stack (i.e. a push opcode, a pop opcode). I probably should have > done something like that for a FIFO queue with the code I posted > earlier today for the voice allocation test. > > Those could be done as UDO's and might be useful as C opcodes too for > efficiency, but probably not necessary unless they really get used a > lot. > > The one thing you did mention that isn't doable without wrapping with > calls to strset and strget is an ftable full of strings. Or is that > possible?