I recently posted about my frustration with writing endless amount of
inits at the top of my instruments. It was suggested that I could
write a UDO to initialise my variables but UDOs can't have a variable
size of inputs so I'd basically end up having to write 20 different
UDO, each with a different number of inputs. Any other ideas? Perhaps
I'm missing a simple solution..


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> I recently posted about my frustration with writing endless amount of
> inits at the top of my instruments. It was suggested that I could
> write a UDO to initialise my variables but UDOs can't have a variable
> size of inputs so I'd basically end up having to write 20 different
> UDO, each with a different number of inputs. Any other ideas? Perhaps
> I'm missing a simple solution..
>

It would be possible to do a multiple_init opcode if that would help. 
Actually quite easy code
==John ff



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

That's what I initially suggested, but before writing an opcode I
thought it would be better to ask on the list if there is a way of
doing it natively.


On 11 February 2010 16:30,   wrote:
>> I recently posted about my frustration with writing endless amount of
>> inits at the top of my instruments. It was suggested that I could
>> write a UDO to initialise my variables but UDOs can't have a variable
>> size of inputs so I'd basically end up having to write 20 different
>> UDO, each with a different number of inputs. Any other ideas? Perhaps
>> I'm missing a simple solution..
>>
>
> It would be possible to do a multiple_init opcode if that would help.
> Actually quite easy code
> ==John ff
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Rory,

I don't think there is any other way as Csound only allocates
variables if they are on the lefthand side of an opcode, and as you
mentioned UDO's can not be specified for variable list of out args.

John, any possibility to change init to allow multiple out args? I've
forgotten the polymorphic opcode types and wasn't sure if we had the
possibility to do this (same in args, different out args).

Thanks!
steven



On Thu, Feb 11, 2010 at 11:34 AM, Rory Walsh  wrote:
> That's what I initially suggested, but before writing an opcode I
> thought it would be better to ask on the list if there is a way of
> doing it natively.
>
>
> On 11 February 2010 16:30,   wrote:
>>> I recently posted about my frustration with writing endless amount of
>>> inits at the top of my instruments. It was suggested that I could
>>> write a UDO to initialise my variables but UDOs can't have a variable
>>> size of inputs so I'd basically end up having to write 20 different
>>> UDO, each with a different number of inputs. Any other ideas? Perhaps
>>> I'm missing a simple solution..
>>>
>>
>> It would be possible to do a multiple_init opcode if that would help.
>> Actually quite easy code
>> ==John ff
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> John, any possibility to change init to allow multiple out args? I've
> forgotten the polymorphic opcode types and wasn't sure if we had the
> possibility to do this (same in args, different out args).
>
> Thanks!
> steven
>

I have init woking with multiple in/out
At present the numbers must match.  It would be possible for

k1, k2, k3  init 0,0,0

or

k1, k2, k3 init 0

as long as we determin the semantics of

k1, k2, k3 init 1, 2

==John




Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

John, any possibility to change init to allow multiple out args? I've
forgotten the polymorphic opcode types and wasn't sure if we had the
possibility to do this (same in args, different out args).

Thanks!
steven

    

I have init woking with multiple in/out
At present the numbers must match.  It would be possible for

k1, k2, k3  init 0,0,0

or

k1, k2, k3 init 0

as long as we determin the semantics of

k1, k2, k3 init 1, 2

==John




Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
  

Version in CVS now allows upto 24 output and input arguments and they must
have the same count.  The question is what to do if the counts do not
match.  Two options; an error or repeat the last in  if necessary, and
still an error in more ins than outs

>         jpff@cs.bath.ac.uk wrote:         John, any possibility to change
> init to allow multiple out args? I've forgotten the polymorphic
> opcode types and wasn't sure if we had the possibility to do this
> (same in args, different out args).  Thanks! steven             I
> have init woking with multiple in/out At present the numbers must
> match.  It would be possible for  k1, k2, k3  init 0,0,0  or  k1,
> k2, k3 init 0  as long as we determin the semantics of  k1, k2, k3
> init 1, 2  ==John     Send bugs reports to this list. To
> unsubscribe, send email sympa@lists.bath.ac.uk with body
> "unsubscribe csound"     First off, I think this is a great idea
> to simplify orchestras. I think the simplest way to go about it
> would be to assume that the args correspond to the outlet
> variables, and any non-corresponding variables would assume the
> last arg. So, in the instance of:
>
>  k1, k2, k3 init 1, 2
>
>  ki = 1, k2 = 2, k3 = 2
>
>  .mmb
>




Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

And another thought; should assignment of = also allow multiple in/out
arguments?  More complex in some ways but would save some internal code.
  Personally I do not like it
==John




Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

jpff@cs.bath.ac.uk wrote:
> And another thought; should assignment of = also allow multiple in/out
> arguments?  More complex in some ways but would save some internal code.
>   Personally I do not like it
>   

It is possible in Python (but only with equal number of in/out 
arguments). Since Python is used a lot by CSound users, it would not 
seem strange to them.

So as it stands if a user was to:

k1, k2, k3, init 0

would that initialize all variables to zero or produce an error? I
think if users don't put in the correct amount of init values all
variables should be initialised to what the last init value is, in
this case 0.

Rory.


On 12 February 2010 07:25,   wrote:
> And another thought; should assignment of = also allow multiple in/out
> arguments?  More complex in some ways but would save some internal code.
>  Personally I do not like it
> ==John
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

>From a user's point of view, I see no problem with repeating the last
input even if it's:
i1, i2, i3 = 1, 2
in which case i2 and i3 could both be 2. I also don't know if it's
necessary to have an error if there are more inputs than outputs, but
I guess that would be consistent with other opcodes that are required
to match.

Seems like one problem with = might be that it can be i-time or
p-time. Another idea from the world of python, though, what about
something like:
i1 = i2 = i3 = 8

?
Wouldn't accomplish quite the same thing, but maybe that would make a
difference re coding and errors.

-Chuckk


On Fri, Feb 12, 2010 at 9:25 AM,   wrote:
> And another thought; should assignment of = also allow multiple in/out
> arguments?  More complex in some ways but would save some internal code.
>  Personally I do not like it
> ==John
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 
http://www.badmuthahubbard.com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> From a user's point of view, I see no problem with repeating the last
> input even if it's:
> i1, i2, i3 = 1, 2
> in which case i2 and i3 could both be 2. I also don't know if it's
> necessary to have an error if there are more inputs than outputs, but
> I guess that would be consistent with other opcodes that are required
> to match.
>

I will adjust the code to repeat the last input if necessary.
If more inputs that outputs to me that is a clear error.

The implementation of = in case i-rate and k-rate is the same as init
previousky, so changing the semantics to multiple assign is easy.

And I think ka,kb = kb, ka

will do the CPL thing rather that the BCPL version.  Need to check thatr.

A-rate adssign and f-rate assign might need a little work.


> Seems like one problem with = might be that it can be i-time or
> p-time. Another idea from the world of python, though, what about
> something like:
> i1 = i2 = i3 = 8

Ingerited from C, but a source of real problem in Csound (old parser). 
Not too hard in teh new parser, but not a high priority

>
> ?
> Wouldn't accomplish quite the same thing, but maybe that would make a
> difference re coding and errors.
>
> -Chuckk
>




Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Extremely useful additions.
May I ask you if one might be easy, too:
To remove ALL messages except the explicitely directed ones by print,  
printks and others?
This would give the user the ability to form the console output.
At the moment, there is no way to get rid of a lot of printouts at the  
beginning which are more important for debugging but not for running a  
csd, and it slows down for example the QuteCsound GUI for the first  
seconds (and may confuse many newbies).
Thanks -

	joachim


Am 12.02.2010 um 14:10 schrieb jpff@cs.bath.ac.uk:

>> From a user's point of view, I see no problem with repeating the last
>> input even if it's:
>> i1, i2, i3 = 1, 2
>> in which case i2 and i3 could both be 2. I also don't know if it's
>> necessary to have an error if there are more inputs than outputs, but
>> I guess that would be consistent with other opcodes that are required
>> to match.
>>
>
> I will adjust the code to repeat the last input if necessary.
> If more inputs that outputs to me that is a clear error.
>
> The implementation of = in case i-rate and k-rate is the same as init
> previousky, so changing the semantics to multiple assign is easy.
>
> And I think ka,kb = kb, ka
>
> will do the CPL thing rather that the BCPL version.  Need to check  
> thatr.
>
> A-rate adssign and f-rate assign might need a little work.
>
>
>> Seems like one problem with = might be that it can be i-time or
>> p-time. Another idea from the world of python, though, what about
>> something like:
>> i1 = i2 = i3 = 8
>
> Ingerited from C, but a source of real problem in Csound (old parser).
> Not too hard in teh new parser, but not a high priority
>
>>
>> ?
>> Wouldn't accomplish quite the same thing, but maybe that would make a
>> difference re coding and errors.
>>
>> -Chuckk
>>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> Extremely useful additions.
> May I ask you if one might be easy, too:
> To remove ALL messages except the explicitely directed ones by print,
> printks and others?
> This would give the user the ability to form the console output.
> At the moment, there is no way to get rid of a lot of printouts at the
> beginning which are more important for debugging but not for running a
> csd, and it slows down for example the QuteCsound GUI for the first
> seconds (and may confuse many newbies).
> Thanks -
>
> 	joachim
>

We are looking at that.  Lots of small cghanges I guess
==John ff



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"