Seems to be running; the specification is slightly different from that
suggested as it starts at p1 (the instrument number).  However we
could discuss this.  For example it could have a first argument to say
where to start, so one could do "passign 3, idur, iamp, ipitch".
  Anyone have any thoughts or preferences?  The code is in CVS but as
no one is using it yet we can adjust it now.
==John ffitch


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

Does it or can it support strings?  For example:

passign 3, idur, iamp, Sfile

Also, the first arg as where to start the assignments is probably a good idea.

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/



On Sun, Dec 13, 2009 at 1:36 AM, john ffitch  wrote:
> Seems to be running; the specification is slightly different from that
> suggested as it starts at p1 (the instrument number).  However we
> could discuss this.  For example it could have a first argument to say
> where to start, so one could do "passign 3, idur, iamp, ipitch".
>  Anyone have any thoughts or preferences?  The code is in CVS but as
> no one is using it yet we can adjust it now.
> ==John ffitch
>
>
> 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"

on 2009-12-13 at 09:36 john ffitch wrote:

> For example it could have a first argument to say where to start, so
> one could do "passign 3, idur, iamp, ipitch". 

that's the best option, IMO.



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

I was going to do this one myself but you beat me to it...

I would prefer all pfields, no starting index, accepting any number of
strings if that is possible, or at least one string anyway.

Another might be a variant passigndefault with pairs passigndefault
p1, p1default value...

Regards,
Mike

On 12/13/09, john ffitch  wrote:
> Seems to be running; the specification is slightly different from that
> suggested as it starts at p1 (the instrument number).  However we
> could discuss this.  For example it could have a first argument to say
> where to start, so one could do "passign 3, idur, iamp, ipitch".
>   Anyone have any thoughts or preferences?  The code is in CVS but as
> no one is using it yet we can adjust it now.
> ==John ffitch
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

Michael,

nice idea

  i would love to have both opcodes.

passign

and

passigndefault

and to be able to specify strings or "sample.aif"  too

-dB


Dr. Richard Boulanger  -  rboulanger@berklee.edu



On Dec 13, 2009, at 11:36 AM, Michael Gogins wrote:

> I was going to do this one myself but you beat me to it...
>
> I would prefer all pfields, no starting index, accepting any number of
> strings if that is possible, or at least one string anyway.
>
> Another might be a variant passigndefault with pairs passigndefault
> p1, p1default value...
>
> Regards,
> Mike
>
> On 12/13/09, john ffitch  wrote:
>> Seems to be running; the specification is slightly different from  
>> that
>> suggested as it starts at p1 (the instrument number).  However we
>> could discuss this.  For example it could have a first argument to  
>> say
>> where to start, so one could do "passign 3, idur, iamp, ipitch".
>>  Anyone have any thoughts or preferences?  The code is in CVS but as
>> no one is using it yet we can adjust it now.
>> ==John ffitch
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> 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"

One other option worth considering is have passign auto-create ivars
for the first three pfields, such that

    passign iamp, ipitch, Sfile

creates ivars i_instr istart and idur in addition to iamp, ipitch and
Sfile. That might be the cleanest looking and easiest to use. The
drawback is that it could cause some confusion since no other opcodes
that I'm aware automatically generate ivars.

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/



On Sun, Dec 13, 2009 at 8:40 AM, Dr. Richard Boulanger
 wrote:
> Michael,
>
> nice idea
>
>  i would love to have both opcodes.
>
> passign
>
> and
>
> passigndefault
>
> and to be able to specify strings or "sample.aif"  too
>
> -dB
>
>
> Dr. Richard Boulanger  -  rboulanger@berklee.edu
>
>
>
> On Dec 13, 2009, at 11:36 AM, Michael Gogins wrote:
>
>> I was going to do this one myself but you beat me to it...
>>
>> I would prefer all pfields, no starting index, accepting any number of
>> strings if that is possible, or at least one string anyway.
>>
>> Another might be a variant passigndefault with pairs passigndefault
>> p1, p1default value...
>>
>> Regards,
>> Mike
>>
>> On 12/13/09, john ffitch  wrote:
>>>
>>> Seems to be running; the specification is slightly different from that
>>> suggested as it starts at p1 (the instrument number).  However we
>>> could discuss this.  For example it could have a first argument to say
>>> where to start, so one could do "passign 3, idur, iamp, ipitch".
>>>  Anyone have any thoughts or preferences?  The code is in CVS but as
>>> no one is using it yet we can adjust it now.
>>> ==John ffitch
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> 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"

To keep things more consistent with existing syntax, putting the
assignments on the left may make more sense.

    idur, iamp, ifreq, Sfile passign 3
    i_instr, istart, idur, iamp, ifreq, Sfile passign

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/

On Sun, Dec 13, 2009 at 9:24 AM, Jacob Joaquin  wrote:
> One other option worth considering is have passign auto-create ivars
> for the first three pfields, such that
>
>    passign iamp, ipitch, Sfile
>
> creates ivars i_instr istart and idur in addition to iamp, ipitch and
> Sfile. That might be the cleanest looking and easiest to use. The
> drawback is that it could cause some confusion since no other opcodes
> that I'm aware automatically generate ivars.


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

That does make more sense really. Otherwise I think we would need to  
create the variables and then pass them to passign.

On 13 Dec 2009, at 17:43, Jacob Joaquin wrote:

> To keep things more consistent with existing syntax, putting the
> assignments on the left may make more sense.
>
>    idur, iamp, ifreq, Sfile passign 3
>    i_instr, istart, idur, iamp, ifreq, Sfile passign
>
> Best,
> Jake
> -- 
> The Csound Blog - http://csound.noisepages.com/
>
> On Sun, Dec 13, 2009 at 9:24 AM, Jacob Joaquin  
>  wrote:
>> One other option worth considering is have passign auto-create ivars
>> for the first three pfields, such that
>>
>>    passign iamp, ipitch, Sfile
>>
>> creates ivars i_instr istart and idur in addition to iamp, ipitch and
>> Sfile. That might be the cleanest looking and easiest to use. The
>> drawback is that it could cause some confusion since no other opcodes
>> that I'm aware automatically generate ivars.
>
>
> 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"

What if we called it pin instead of passign?

That opcode that most closely resembles passign is xin. The 'x' in xin
is obviously chosen because the types of inputs vary. Though in this
case, we always know that the input will be a pfield. Thus the name
pin.

Just trying to keep things in the language as consistent as possible.  :)

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/


On Sun, Dec 13, 2009 at 9:57 AM, Victor Lazzarini
 wrote:
> That does make more sense really. Otherwise I think we would need to create
> the variables and then pass them to passign.
>
> On 13 Dec 2009, at 17:43, Jacob Joaquin wrote:
>
>> To keep things more consistent with existing syntax, putting the
>> assignments on the left may make more sense.
>>
>>   idur, iamp, ifreq, Sfile passign 3
>>   i_instr, istart, idur, iamp, ifreq, Sfile passign
>>
>> Best,
>> Jake
>> --
>> The Csound Blog - http://csound.noisepages.com/
>>
>> On Sun, Dec 13, 2009 at 9:24 AM, Jacob Joaquin 
>> wrote:
>>>
>>> One other option worth considering is have passign auto-create ivars
>>> for the first three pfields, such that
>>>
>>>   passign iamp, ipitch, Sfile
>>>
>>> creates ivars i_instr istart and idur in addition to iamp, ipitch and
>>> Sfile. That might be the cleanest looking and easiest to use. The
>>> drawback is that it could cause some confusion since no other opcodes
>>> that I'm aware automatically generate ivars.
>>
>>
>> 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"

I do prefer the form with args on the left and an optional starting point
But.. ther eis no output type for multiple i-rate and s far my attempt to
implement have failed.

==John

> That does make more sense really. Otherwise I think we would need to
> create the variables and then pass them to passign.
>
> On 13 Dec 2009, at 17:43, Jacob Joaquin wrote:
>
>> To keep things more consistent with existing syntax, putting the
>> assignments on the left may make more sense.
>>
>>    idur, iamp, ifreq, Sfile passign 3
>>    i_instr, istart, idur, iamp, ifreq, Sfile passign
>>
>> Best,
>> Jake
>> --
>> The Csound Blog - http://csound.noisepages.com/
>>
>> On Sun, Dec 13, 2009 at 9:24 AM, Jacob Joaquin
>>  wrote:
>>> One other option worth considering is have passign auto-create ivars
>>> for the first three pfields, such that
>>>
>>>    passign iamp, ipitch, Sfile
>>>
>>> creates ivars i_instr istart and idur in addition to iamp, ipitch and
>>> Sfile. That might be the cleanest looking and easiest to use. The
>>> drawback is that it could cause some confusion since no other opcodes
>>> that I'm aware automatically generate ivars.
>>
>>
>> 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"

Args on the left is good, it is more Csound-like; then optional
default args can go in corresponding slots on the right.

i1, i2,... pin [idefault1, idefault2...]

Regards,
Mike

On 12/13/09, jpff@cs.bath.ac.uk  wrote:
> I do prefer the form with args on the left and an optional starting point
> But.. ther eis no output type for multiple i-rate and s far my attempt to
> implement have failed.
>
> ==John
>
>> That does make more sense really. Otherwise I think we would need to
>> create the variables and then pass them to passign.
>>
>> On 13 Dec 2009, at 17:43, Jacob Joaquin wrote:
>>
>>> To keep things more consistent with existing syntax, putting the
>>> assignments on the left may make more sense.
>>>
>>>    idur, iamp, ifreq, Sfile passign 3
>>>    i_instr, istart, idur, iamp, ifreq, Sfile passign
>>>
>>> Best,
>>> Jake
>>> --
>>> The Csound Blog - http://csound.noisepages.com/
>>>
>>> On Sun, Dec 13, 2009 at 9:24 AM, Jacob Joaquin
>>>  wrote:
>>>> One other option worth considering is have passign auto-create ivars
>>>> for the first three pfields, such that
>>>>
>>>>    passign iamp, ipitch, Sfile
>>>>
>>>> creates ivars i_instr istart and idur in addition to iamp, ipitch and
>>>> Sfile. That might be the cleanest looking and easiest to use. The
>>>> drawback is that it could cause some confusion since no other opcodes
>>>> that I'm aware automatically generate ivars.
>>>
>>>
>>> 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"
>

A system for handling default args probably warrants its own opcode,
rather than trying to make everything fit into pin, for a few reasons.

I think John's original idea of having an optional value that
specifies which pfield index to start assignment is a great idea, as
the first two pfields are seldom referred to within an instr body.
The third pfield is also omitted on a regular basis. Having to assign
temporary ivals for pfields that will not be used in an instr body is
redundant and counter to the original purpose of the opcode, to save
keystrokes.

    iamp, ifreq, ifn pin 4

is better than

    i_instr, istart, idur, iamp, ifreq, ifn pin

Unless, of course, the instrument uses the first three assignments.
Let's assume for a moment that default args were part of pin.  Do we
assign default values to the first three pfields? If so, what would be
the point since they are required? If not, does that mean we would
begin assigning default args on pfield 4? Then the values on the right
would not align well with the values on the left, making it much
harder to read.

    i_instr, istart, idur, iamp, ifreq, ifn pin 1.0, 440, 7

Then there is the issue that default args will be tricky regardless
because they require the use of the no-carry statement(!) in the
score. That said, a way to handle default args is much needed, and I
for one welcome a better way then there is now. And it could certainly
be designed to work in tandem with pin.

For example, the first parameter of pdefault lists the starting index
of assigning default args, with the following three values
corresponding for pfields 4, 5 and 6.

    pdefault 4, 1.0, 440, 7
    iamp, ifreq, ifn pin 4

In many languages, args are defined at the end of a function call,
forcing users to specify some args.  The following code would force
users to always specify the amp and frequency, but optionally skip
giving a value for function number, since it has a default arg of 7:

    pdefault 6, 7              ; p6 defaults to function table 7
    iamp, ifreq, ifn pin 4


Am I making sense?

Best,
Jake

This might break old orchestras that used istar, idur etc.

Victor
On 13 Dec 2009, at 22:16, Jacob Joaquin wrote:

> A system for handling default args probably warrants its own opcode,
> rather than trying to make everything fit into pin, for a few reasons.
>
> I think John's original idea of having an optional value that
> specifies which pfield index to start assignment is a great idea, as
> the first two pfields are seldom referred to within an instr body.
> The third pfield is also omitted on a regular basis. Having to assign
> temporary ivals for pfields that will not be used in an instr body is
> redundant and counter to the original purpose of the opcode, to save
> keystrokes.
>
>    iamp, ifreq, ifn pin 4
>
> is better than
>
>    i_instr, istart, idur, iamp, ifreq, ifn pin
>
> Unless, of course, the instrument uses the first three assignments.
> Let's assume for a moment that default args were part of pin.  Do we
> assign default values to the first three pfields? If so, what would be
> the point since they are required? If not, does that mean we would
> begin assigning default args on pfield 4? Then the values on the right
> would not align well with the values on the left, making it much
> harder to read.
>
>    i_instr, istart, idur, iamp, ifreq, ifn pin 1.0, 440, 7
>
> Then there is the issue that default args will be tricky regardless
> because they require the use of the no-carry statement(!) in the
> score. That said, a way to handle default args is much needed, and I
> for one welcome a better way then there is now. And it could certainly
> be designed to work in tandem with pin.
>
> For example, the first parameter of pdefault lists the starting index
> of assigning default args, with the following three values
> corresponding for pfields 4, 5 and 6.
>
>    pdefault 4, 1.0, 440, 7
>    iamp, ifreq, ifn pin 4
>
> In many languages, args are defined at the end of a function call,
> forcing users to specify some args.  The following code would force
> users to always specify the amp and frequency, but optionally skip
> giving a value for function number, since it has a default arg of 7:
>
>    pdefault 6, 7              ; p6 defaults to function table 7
>    iamp, ifreq, ifn pin 4
>
>
> Am I making sense?
>
> Best,
> Jake
> --  
> The Csound Blog - http://csound.noisepages.com/
>
>
> On Sun, Dec 13, 2009 at 11:58 AM, Michael Gogins
>  wrote:
>> Args on the left is good, it is more Csound-like; then optional
>> default args can go in corresponding slots on the right.
>>
>> i1, i2,... pin [idefault1, idefault2...]
>
>
> 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"

On Sun, Dec 13, 2009 at 2:25 PM, Victor Lazzarini
 wrote:
> This might break old orchestras that used istar, idur etc.

Could you clarify?  As far as I can tell, using pin and/or pdefault
would only affect the orchestras they reside in, and should leave all
existing instruments to operate as they do now. Perhaps I'm
overlooking something in my explanation.

Best,
Jake

of course, forget what I said...
On 13 Dec 2009, at 22:33, Jacob Joaquin wrote:

> On Sun, Dec 13, 2009 at 2:25 PM, Victor Lazzarini
>  wrote:
>> This might break old orchestras that used istar, idur etc.
>
> Could you clarify?  As far as I can tell, using pin and/or pdefault
> would only affect the orchestras they reside in, and should leave all
> existing instruments to operate as they do now. Perhaps I'm
> overlooking something in my explanation.
>
> Best,
> Jake
> --  
> The Csound Blog - http://csound.noisepages.com/
>
>
> 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"