I have been looking at the vbap/vbaplsinit issue.  As currently
implemented so there is only one call to vbaplsinit, and the result is
held in an internal global.  As I understand recent comments, some
people would like to have more than one speaker layout in one run.

I _think_ this could achieved if 
1) vbaplsinit returned a value that indicates the speaker layout
2) add another (optional) argument to vbap opcodes to say which layout
to use

This is compatible with current code but at present I cannot see how
to make vbap*move opcodes work this way without breaking backwards
compatability.  One could create a vbap*moveX family opcode with the
extra argument but that seems odd.

Any suggestions?

==John ffitch

hi john,

i agree with joachim; there are definately situations where one would
want to use multiple vbap setups in a single orchestra run.  and i
think that the idea having vbaplsinit return a handle that is then
supplied to the vbap opcodes is a good solution.

regarding the vbap*move opcodes, when i first looked at vbap years
ago, their existence made sense since the regular (non-moving) vbap
opcodes didn't take k-rate arguments.  however, since they now do, i'm
not even sure how useful the *move opcodes are anymore.  i get that
backwards compatibility is important, but i'm not sure that a next
generation of move opcodes is needed.... unless there are those out
there who use them, of course!

what about using "vbap1" as the next-generation vbap and adding the
speaker-setup init argument to it?

--  ben


On Fri, Jul 13, 2012 at 10:37 AM, john ffitch  wrote:
> I have been looking at the vbap/vbaplsinit issue.  As currently
> implemented so there is only one call to vbaplsinit, and the result is
> held in an internal global.  As I understand recent comments, some
> people would like to have more than one speaker layout in one run.
>
> I _think_ this could achieved if
> 1) vbaplsinit returned a value that indicates the speaker layout
> 2) add another (optional) argument to vbap opcodes to say which layout
> to use
>
> This is compatible with current code but at present I cannot see how
> to make vbap*move opcodes work this way without breaking backwards
> compatability.  One could create a vbap*moveX family opcode with the
> extra argument but that seems odd.
>
> Any suggestions?
>
> ==John ffitch
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

hi ben, hi john -
i agree. i also never really understood the *move variants, and i do
think that a new variant (like vbap1) which refers to a handle argument
would be the best.
thanks for looking into this, john!
best -
	joachim


Am 13.07.2012 21:44, schrieb ben hackbarth:
> hi john,
> 
> i agree with joachim; there are definately situations where one would
> want to use multiple vbap setups in a single orchestra run.  and i
> think that the idea having vbaplsinit return a handle that is then
> supplied to the vbap opcodes is a good solution.
> 
> regarding the vbap*move opcodes, when i first looked at vbap years
> ago, their existence made sense since the regular (non-moving) vbap
> opcodes didn't take k-rate arguments.  however, since they now do, i'm
> not even sure how useful the *move opcodes are anymore.  i get that
> backwards compatibility is important, but i'm not sure that a next
> generation of move opcodes is needed.... unless there are those out
> there who use them, of course!
> 
> what about using "vbap1" as the next-generation vbap and adding the
> speaker-setup init argument to it?
> 
> --  ben
> 
> 
> On Fri, Jul 13, 2012 at 10:37 AM, john ffitch  wrote:
>> I have been looking at the vbap/vbaplsinit issue.  As currently
>> implemented so there is only one call to vbaplsinit, and the result is
>> held in an internal global.  As I understand recent comments, some
>> people would like to have more than one speaker layout in one run.
>>
>> I _think_ this could achieved if
>> 1) vbaplsinit returned a value that indicates the speaker layout
>> 2) add another (optional) argument to vbap opcodes to say which layout
>> to use
>>
>> This is compatible with current code but at present I cannot see how
>> to make vbap*move opcodes work this way without breaking backwards
>> compatability.  One could create a vbap*moveX family opcode with the
>> extra argument but that seems odd.
>>
>> Any suggestions?
>>
>> ==John ffitch
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

OK; wull look into it

too late tonight....



> hi ben, hi john -
> i agree. i also never really understood the *move variants, and i do
> think that a new variant (like vbap1) which refers to a handle argument
> would be the best.
> thanks for looking into this, john!
> best -
> 	joachim
>
>
> Am 13.07.2012 21:44, schrieb ben hackbarth:
>> hi john,
>>
>> i agree with joachim; there are definately situations where one would
>> want to use multiple vbap setups in a single orchestra run.  and i
>> think that the idea having vbaplsinit return a handle that is then
>> supplied to the vbap opcodes is a good solution.
>>
>> regarding the vbap*move opcodes, when i first looked at vbap years
>> ago, their existence made sense since the regular (non-moving) vbap
>> opcodes didn't take k-rate arguments.  however, since they now do, i'm
>> not even sure how useful the *move opcodes are anymore.  i get that
>> backwards compatibility is important, but i'm not sure that a next
>> generation of move opcodes is needed.... unless there are those out
>> there who use them, of course!
>>
>> what about using "vbap1" as the next-generation vbap and adding the
>> speaker-setup init argument to it?
>>
>> --  ben
>>
>>
>> On Fri, Jul 13, 2012 at 10:37 AM, john ffitch 
>> wrote:
>>> I have been looking at the vbap/vbaplsinit issue.  As currently
>>> implemented so there is only one call to vbaplsinit, and the result is
>>> held in an internal global.  As I understand recent comments, some
>>> people would like to have more than one speaker layout in one run.
>>>
>>> I _think_ this could achieved if
>>> 1) vbaplsinit returned a value that indicates the speaker layout
>>> 2) add another (optional) argument to vbap opcodes to say which layout
>>> to use
>>>
>>> This is compatible with current code but at present I cannot see how
>>> to make vbap*move opcodes work this way without breaking backwards
>>> compatability.  One could create a vbap*moveX family opcode with the
>>> extra argument but that seems odd.
>>>
>>> Any suggestions?
>>>
>>> ==John ffitch
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe csound"
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
>