Your proposal is simple and makes sense to me. I would prefer automatic
growing of the bus vectors. I take it that the MYFLT* arguments in the
audio rate API point to vectors of ksmps MYFLT.

Original Message:
-----------------
From:  jpff@codemist.co.uk
Date: Thu,  6 May 2004 09:31:16 +0100
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4571] Bus design


This message is a meander through thoughts on the software bus.

Basic design:
   Finite number of a-input, a-output, k-input and k-output slots, all
   independent.

   Csound interface with four opcodes:
          buso       a1, kn    ;; write a1 to a-output #kn 
   ar     busi       kn        ;; read ar from a-input #kn 
          buso       k1, kn    ;; write k1 to k-output #kn 
   kr     busi       kn        ;; read kr from k-input #kn 

   API interface:
   Not so sure about this but something like
   csoundReadABus(void*, MYFLT* a, int n);
   csoundWriteABus(void*, MYFLT* a, int n);
   csoundReadKBus(void*, MYFLT* k, int n);
   csoundWriteKBus(void*, MYFLT* k, int n);
                   /* or csoundWriteKBus(void*, MYFLT k,int n); ???*/

   Implementation:
   Within the ENVIRON variable pointers to the four regions.  Rest is
   obvious!

   Problems:
   How many bus items should we provide?  Should it be a fixed number
   or grow as referenced?

   Alternatives:
   Just allow access to ZAK buses from the API.  I rather prefer the
   above as it seems simpler and orthogonal to previous ideas

Comments, improvements,... as appropriate.  The above would be easy to
implement over breakfast(!)

==John ffitch


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

My proposal is that Csound should guarantee some minimum number of bus slots (64 
say, or some other "round number"), but with the option to increase the number 
under some form of user control. This way, orchestras that do not exceed the 
minimum are guaranteed to run on all versions without the user having to 
configure anything. Thus a Csound host must equally guarantee to support the 
same minimum number.


Richard Dobson



gogins@pipeline.com wrote:
> Your proposal is simple and makes sense to me. I would prefer automatic
> growing of the bus vectors. I take it that the MYFLT* arguments in the
> audio rate API point to vectors of ksmps MYFLT.
> 
....

Hi all,

Would the bus be accessed by numeric index only or would there be named 
slots as well?  Seems to me if the bus was backed by a hash map with the 
number or name as key and the bus as value we could then allocate as 
required without much problem.  So, something like:

WRITE TO BUS:
    grabBus(id) //where id is name or number
       -if bus identifier doesn't exist, create new ksmps-long MYFLT 
array and add to map with id as key
       -return bus from map
    write to bus

READ FROM BUS:
    grabBus(id)
       -if bus identifier doesn't exist, create new ksmps-long MYFLT 
array and add to map with id as key
       -return bus from map
    read from bus

I think that using an indexed array of fixed size and changing the size 
at compile time would be very limiting.

steven


Richard Dobson wrote:

> My proposal is that Csound should guarantee some minimum number of bus 
> slots (64 say, or some other "round number"), but with the option to 
> increase the number under some form of user control. This way, 
> orchestras that do not exceed the minimum are guaranteed to run on all 
> versions without the user having to configure anything. Thus a Csound 
> host must equally guarantee to support the same minimum number.
>
>
> Richard Dobson
>
>
>
> gogins@pipeline.com wrote:
>
>> Your proposal is simple and makes sense to me. I would prefer automatic
>> growing of the bus vectors. I take it that the MYFLT* arguments in the
>> audio rate API point to vectors of ksmps MYFLT.
>>
> ....
>
>
>

Well, numeric index, but there is nothing to prevent users from creating 
variables with meaningful names. On a 64-channel mixer, they are naturally 
numbered from 1 to 64, but anyone can stick a label on a channel saying "bass 
drum" or "filter_cutoff", etc....

	kfilter_Cutoff = readkBus(2)

etc...

And there should be no reason why several Csound  variables can't access a 
single bus channel, for reading.

Richard Dobson



steven yi wrote:

> Hi all,
> 
> Would the bus be accessed by numeric index only or would there be named 
> slots as well?  Seems to me if the bus was backed by a hash map with the 
> number or name as key and the bus as value we could then allocate as 
> required without much problem.  So, something like:
> 
> WRITE TO BUS:
>    grabBus(id) //where id is name or number
>       -if bus identifier doesn't exist, create new ksmps-long MYFLT 
>

....