Whenever I try to write a UDO that takes a string I get an error saving 
invalid input type? Is this not possible? Or is the only way of doing it 
to cast as an i-type before I pass the string? Cheers,
Rory.

Seems that way. The funny thing is that in the case of soundin for 
example, we have one parameter 'ifilecode' that is an i-type yet is 
accepts a string. If we try this in our own UDO's, i.e., pass a string 
when an i-type variable is expect we get an invalid argument? 
Perhaps/hopefully I've got this wrong but for instance check out the 
ultra useful UDO below!

opcode  printString, i, i
ifile xin
print ifile
endop

instr 1
i1 printString "testing"
endin

Rory.

Steven Yi wrote:
> Hi Rory,
> 
> The manual seems to imply that S-types aren't supported:
> 
> http://csounds.com/manual/html/opcode.html
> 
> I'd love to be wrong on this though.
> 
> steven
> 
> 
> On 5/2/06, Rory Walsh  wrote:
>> Whenever I try to write a UDO that takes a string I get an error saving
>> invalid input type? Is this not possible? Or is the only way of doing it
>> to cast as an i-type before I pass the string? Cheers,
>> Rory.
>> -- 
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>

Thanks Steven. Looks like that's the way to go. Cheers,
Rory.

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.
> 
> steven
> 
> 
> On 5/2/06, Rory Walsh  wrote:
>> Seems that way. The funny thing is that in the case of soundin for
>> example, we have one parameter 'ifilecode' that is an i-type yet is
>> accepts a string. If we try this in our own UDO's, i.e., pass a string
>> when an i-type variable is expect we get an invalid argument?
>> Perhaps/hopefully I've got this wrong but for instance check out the
>> ultra useful UDO below!
>>
>> opcode  printString, i, i
>> ifile xin
>> print ifile
>> endop
>>
>> instr 1
>> i1 printString "testing"
>> endin
>>
>> Rory.
>>
>> Steven Yi wrote:
>> > Hi Rory,
>> >
>> > The manual seems to imply that S-types aren't supported:
>> >
>> > http://csounds.com/manual/html/opcode.html
>> >
>> > I'd love to be wrong on this though.
>> >
>> > steven
>> >
>> >
>> > On 5/2/06, Rory Walsh  wrote:
>> >> Whenever I try to write a UDO that takes a string I get an error 
>> saving
>> >> invalid input type? Is this not possible? Or is the only way of 
>> doing it
>> >> to cast as an i-type before I pass the string? Cheers,
>> >> Rory.
>> >> --
>> >> Send bugs reports to this list.
>> >> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>> >>
>> -- 
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>

I, for one certainly like the sound of this - it reminds me of the 
things I like about using SC3. This would likely also work toward 
unifying the Subinstr and UDO idea into a more coherent whole, under 
the hood.

Of course, a change of the magnitude suggested would hopefully coincide 
with a release of version increment 5.03, as the 5.02 release date is 
approaching rapidly and there are already a ton of new and exciting 
frontends etc that should be out and available to the public to use 
that arguably should take precedence over the exciting changes 
suggested in the previous email.



-David

ps. new\n parser\n parser\n parser\n ;)

On May 4, 2006, at 5:38 AM, Istvan Varga wrote:

> 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.