passing a string to a UDO?

[rory walsh]

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 [hidden email]

[Steven Yi]

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 <[hidden email]> 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 [hidden email]
>
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[rory walsh]

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 <[hidden email]> 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 [hidden email]
>>

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Steven Yi]

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email]
> >>
> --
> Send bugs reports to this list.
> To unsubscribe, send email to [hidden email]
>

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[rory walsh]

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email]
>> >>
>> --
>> Send bugs reports to this list.
>> To unsubscribe, send email to [hidden email]
>>

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Istvan Varga]

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.

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[David Akbari]

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.

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Istvan Varga]

The stack opcodes for a, k, i, and S types should not be very hard
to implement, so it may be possible to have them already in 5.02 if
they are found to be useful.

On Thursday 04 May 2006 15:48, David Akbari wrote:

> 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 ;)

Not sure if it would help much here, as the limitation is not on the
syntax level.
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Steven Yi]

Hi Istvan,

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?

steven



On 5/4/06, Istvan Varga <[hidden email]> wrote:

> The stack opcodes for a, k, i, and S types should not be very hard
> to implement, so it may be possible to have them already in 5.02 if
> they are found to be useful.
>
> On Thursday 04 May 2006 15:48, David Akbari wrote:
>
> > 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 ;)
>
> Not sure if it would help much here, as the limitation is not on the
> syntax level.
> --
> Send bugs reports to this list.
> To unsubscribe, send email to [hidden email]
>

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[john ffitch]

I largely agree with Steven.  It seems like a hack that could be
implemented other ways.
==John ffitch
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Istvan Varga]

OK, then forget about it. I will not add it or change anything for now.

On Friday 05 May 2006 07:03, [hidden email] wrote:

> I largely agree with Steven.  It seems like a hack that could be
> implemented other ways.
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Victor Lazzarini]

yes, but it would be nice to solve the problem, perhaps we can
still think about other solutions, if there are any.

Victor

At 11:49 05/05/2006, you wrote:
>OK, then forget about it. I will not add it or change anything for now.
>
>On Friday 05 May 2006 07:03, [hidden email] wrote:
>
> > I largely agree with Steven.  It seems like a hack that could be
> > implemented other ways.
>--
>Send bugs reports to this list.
>To unsubscribe, send email to [hidden email]

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Istvan Varga]

I do not really think there is anything to do. In the large
majority of cases, the existing code is sufficient, and when
it is not, there are already more than enough ways to work
around any limitations. I suggested the stack opcodes only
because they are easier to use than doing the same with
ftables, channels, and strset, but, as pointed out by Steven
Yi, they would not add any functionality that is not already
possible, even if requiring slightly more orchestra code.

On Friday 05 May 2006 14:04, Victor Lazzarini wrote:

> yes, but it would be nice to solve the problem, perhaps we can
> still think about other solutions, if there are any.
>
> Victor
>
> At 11:49 05/05/2006, you wrote:
> >OK, then forget about it. I will not add it or change anything for now.
> >
> >On Friday 05 May 2006 07:03, [hidden email] wrote:
> >
> > > I largely agree with Steven.  It seems like a hack that could be
> > > implemented other ways.

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Dr. Richard Boulanger-2]

I never mind redundancy, especially when it brings - simplicity,  
elegance, and leads to insight.

I thought that the stack opcode idea was pretty interesting.... not  
sure what I would do with them
in my own work, but...

that's like saying you could do an lfo with the oscil opcode.

well... I was happy we added lfo

and that's like saying you could do adsr with linseg

but I was happy we added adsr

You might still consider making these additions...

Dr. B.


On May 5, 2006, at 8:20 AM, Istvan Varga wrote:

> I do not really think there is anything to do. In the large
> majority of cases, the existing code is sufficient, and when
> it is not, there are already more than enough ways to work
> around any limitations. I suggested the stack opcodes only
> because they are easier to use than doing the same with
> ftables, channels, and strset, but, as pointed out by Steven
> Yi, they would not add any functionality that is not already
> possible, even if requiring slightly more orchestra code.
>
> On Friday 05 May 2006 14:04, Victor Lazzarini wrote:
>
>> yes, but it would be nice to solve the problem, perhaps we can
>> still think about other solutions, if there are any.
>>
>> Victor
>>
>> At 11:49 05/05/2006, you wrote:
>>> OK, then forget about it. I will not add it or change anything  
>>> for now.
>>>
>>> On Friday 05 May 2006 07:03, [hidden email] wrote:
>>>
>>>> I largely agree with Steven.  It seems like a hack that could be
>>>> implemented other ways.
> --
> Send bugs reports to this list.
> To unsubscribe, send email to [hidden email]

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Istvan Varga]

Here is a simple example:

<CsoundSynthesizer>
<CsInstruments>
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

</CsInstruments>
<CsScore>
i 1 0 5
e
</CsScore>
</CsoundSynthesizer>

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?

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[john ffitch]

It was well said (by Roger Needham) that all problems in computer
science can be solved by another level of indirection!  The simple
solution is to use an allocated vector of ins/outs rather than direct
in the structure.  Of course that would slow everything down.

Thinking to the keyboard, it may be possible to treat the UDO as
special cases and pass arguments the other way.  Hum
==John ffitch
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Oeyvind Brandtsegg]

hello,
 
I recently bought Garritan Personal Orchestra,
as an easy and straightforward way of getting access to symphonic instruments.
 
But csound segfaults when I'm trying to use it.
 
GPO works fine as a VST plugin within Cubase,
and I can use other VST plugins in Csound without problems.
 
I suspect that there might be a problem with the number of outputs of the GOP VST plugin. It uses 16 outputs.
The opcode vstaudio does (afaik) only allow two audio outputs.
Could vstaudio be modified to use a variable number of audio outputs ?
I guess there are other VST plugins than GPO that uses more than 2 audio outs.
If I comment out the line containing vstaudio in my orc,
everything works fine, but of course, I can not hear the audio being played by the GPO CST plugin when vstaudio is commented out.
 
best
Oeyvind
 
below is some info printed about the plugin in the console window:
***
Loaded plugin: Garritan Pe
Vendor name: Native Instru
Version: 1
Is synthesizer? Yes
Number of inputs: 0
Number of outputs: 16
Number of parameters: 0
Number of programs: 0

[Tobiah-3]

Oeyvind Brandtsegg wrote:
> hello,
>  
> I recently bought Garritan Personal Orchestra,

Did you find that it was worth the money?  Was
the piano particularly spectacular?
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Oeyvind Brandtsegg-2]

I only upacked it two hours ago,

but so far it seems to be exactly what I expected.

 

I do not intend to use it for fake symphonic recording purposes,

but as a general library of sounds for further processing in csound.

 

It seems that the popularity of the library has created a sort of recognizable sound, so those in the know would immediately spot that you're using the GPO library. For my purposes this does not matter much.

And besides, if you want to buy a really truly good symphonic library it's at least 20 times the cost.

 

I tested the piano briefly, and it sounded good to me.

Bear in mind that I'm no pianist, so there might be nuances that escapes me.

 

best

Oeyvind
 

On 6/13/06, Tobiah <[hidden email]> wrote:

Oeyvind Brandtsegg wrote:
> hello,
>
> I recently bought Garritan Personal Orchestra,

Did you find that it was worth the money?  Was
the piano particularly spectacular?
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]

[Bruce Petherick]

Tobiah wrote:

> Oeyvind Brandtsegg wrote:
>  
>> hello,
>>  
>> I recently bought Garritan Personal Orchestra,
>>    
>
> Did you find that it was worth the money?  Was
> the piano particularly spectacular?
>  

I may but in here, as I use this a bit for a number of projects. The
overall sounds are good but you really need to massage the MIDI for it
to sound lifelike (The orchestral stuff mainly). We tend to need to
overlay a small number of each string part (just like a real orchestra)
and then edit each part individually to make it sound even close to
real. Do not think that this will replace a real orchestra - it is
really for demos or really really really cheap films.
The piano is not spectacular, but I do use it as a workhorse sampled
piano for Classical music.

Bruce Petherick
--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]