Seeing these posts about limitations on UDO arguments, I am now thinking
about implementing new opcodes that allow for dynamically passing
arguments, not only to UDOs, but also subinstruments etc. For example,
the opcode 'push' could be called with any arguments, and the opcode
'pop' returns the most recently stored set of arguments (the number and
type of values must match for each bundle passed); if there are multiple
calls to 'push', 'pop' returns the argument sets in LIFO order. The
'stack' opcode would allocate some user-specified amount of space for
the argument stack - if this is not done, the first 'push' automatically
allocates a default amount of space.
This all sounds rather hackish, though, so I am not sure if the idea is
good or even worth bothering with. Any comments ?

On Wednesday 03 May 2006 09:36, Steven Yi wrote:

> Well, as far as I understand, in the past before there was a S type,
> strings were parsed by the parser and added to a table and the index
> assigned was how they were accessed under the hood by opcodes and
> other part of code.. It seems to me that that's mostly the same now
> taking a quick look.
> 
> You can use the strset and strget opcodes to assign text to a number
> and then use that number to pass in to the opcode.
> 
> 
> 	opcode printString,i,i
> 
> ifile xin
> Sval strget ifile
> prints Sval
> 
> 	endop
> 
> 
> 	instr 1	;Sound
> strset p1, "testing\n"
> i1 printString p1
> 	endin
> 
> 
> will print:
> 
> Strsets[1]: 'testing
> '
> testing
> 
> (The strset gives the message about strsets[1]). The i num to give for
> strset seems to require a little caution as one could easily overwrite
> values in the strset table, but if you're setting it and getting it
> within a single flow of code, it should probably be safe.
> 
> It would be a lot easier if Stypes were supported, but my guess is
> that it's not simple to do, and at least there is this work around for
> now.