The API should be changed to permit users to create, set, and get at least 
MYFLT variables by name. I'm pretty sure it doesn't currently do this.

In addition, I am adding a real mixer to Csound, as a plugin opcode. There 
are however many busses one creates (numbered), plus however many sends one 
likes to each bus, creating a matrix of sends x busses. Each cell in the 
matrix has a gain that can be set or read. The opcodes are

MixerLevelSet isend, ibuss, klevel
klevel MixerLevelGet isend, ibuss
MixerSend asignal, isend, ibuss, ichannel
asignal MixerReceive ibuss, ichannel
MixerClear

Obviously, MixerSend mixes an audio signal into a channel of a buss at the 
level set by MixerLevelSet with the same send and buss numbers, and 
MixerReceive receives the signal in the buss. For this to work the 
instrument setting levels has to be numbered first, and instruments sending 
audio must be numbered higher than instruments receiving that audio.

It is generally convenient to number the send with the number of the 
instrument doing the sending, and to number the buss with the number of the 
instrument receiving from that bus (though of course one instrument can have 
any number of sends to any number of busses).

There is no reason these opcodes can't also be Csound API functions, as long 
as the mixer opcodes become builtins so the buss arrays are accessible to 
the API. If the mixer is in the API, then any number of audio inputs and 
outputs can go into and come out of Csound to external software.

The mixer levels also could be used to control instruments in Csound from 
external software.

The mixer is now working, and I will add it to SConstruct as soon as I have 
tested the build and functionality on Linux.

Documentation and samples also are forthcoming.

----- Original Message ----- 
From: "Iain Duncan" 
To: 
Sent: Thursday, March 24, 2005 10:02 PM
Subject: Re: [Cs-dev] API, was Broken again


> Would either one allow the api to set a named csound variable? Or is that 
> just crazy talk? Sure would be handy, but I guess going through tables is 
> not such a big hassle. For that matter, can the API handle named csound 
> tables?
>
> Iain
>
> Steven Yi wrote:
>> This would also be the design of MacCsound. IMO, the API that Matt's
>> actually using should get synced up sometime with CS5.  There's a few
>> differences between the two at the moment.  The need for string labels
>> rather than indexes as well as being able to pass strings (in the
>> latest version) as well as number between host and csound are the two
>> differences I can think of at the top of my head.
>>
>> steven
>>
>>
>> On Fri, 25 Mar 2005 00:39:11 +0000, Richard Dobson
>>  wrote:
>>
>>>That would be the automation bus; I am trying to recall just how long ago 
>>>it was
>>>I suggested it....
>>>
>>>Richard Dobson
>>>
>>>gerard van dongen wrote:
>>>...
>>>
>>>>Define control signal-i/o in a generic way in the engine and a seperate
>>>>gui implementation/design tool to make the gui.
>>>>The gui would all be done by a front end.
>>>
>>>...
>>>
>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>Discover which products truly live up to the hype. Start reading now.
>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>_______________________________________________
>>>Csound-devel mailing list
>>>Csound-devel@lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That all sounds very very cool. What about a krate version of the Mixer 
bus as well, ie kontrol bus? And would it be possible for some of those 
mixer functions to be able to take krate args instead of irate ones for 
dynamic mixer patching? And having the opcodes accessible as API 
functions would be great as well.

All this should allow really nice design of real time interfaces. Wheeeee!

Iain

Michael Gogins wrote:
> The API should be changed to permit users to create, set, and get at 
> least MYFLT variables by name. I'm pretty sure it doesn't currently do 
> this.
> 
> In addition, I am adding a real mixer to Csound, as a plugin opcode. 
> There are however many busses one creates (numbered), plus however many 
> sends one likes to each bus, creating a matrix of sends x busses. Each 
> cell in the matrix has a gain that can be set or read. The opcodes are
> 
> MixerLevelSet isend, ibuss, klevel
> klevel MixerLevelGet isend, ibuss
> MixerSend asignal, isend, ibuss, ichannel
> asignal MixerReceive ibuss, ichannel
> MixerClear
> 
> Obviously, MixerSend mixes an audio signal into a channel of a buss at 
> the level set by MixerLevelSet with the same send and buss numbers, and 
> MixerReceive receives the signal in the buss. For this to work the 
> instrument setting levels has to be numbered first, and instruments 
> sending audio must be numbered higher than instruments receiving that 
> audio.
> 
> It is generally convenient to number the send with the number of the 
> instrument doing the sending, and to number the buss with the number of 
> the instrument receiving from that bus (though of course one instrument 
> can have any number of sends to any number of busses).
> 
> There is no reason these opcodes can't also be Csound API functions, as 
> long as the mixer opcodes become builtins so the buss arrays are 
> accessible to the API. If the mixer is in the API, then any number of 
> audio inputs and outputs can go into and come out of Csound to external 
> software.
> 
> The mixer levels also could be used to control instruments in Csound 
> from external software.
> 
> The mixer is now working, and I will add it to SConstruct as soon as I 
> have tested the build and functionality on Linux.
> 
> Documentation and samples also are forthcoming.
> 
> ----- Original Message ----- From: "Iain Duncan" 
> To: 
> Sent: Thursday, March 24, 2005 10:02 PM
> Subject: Re: [Cs-dev] API, was Broken again
> 
> 
>> Would either one allow the api to set a named csound variable? Or is 
>> that just crazy talk? Sure would be handy, but I guess going through 
>> tables is not such a big hassle. For that matter, can the API handle 
>> named csound tables?
>>
>> Iain
>>
>> Steven Yi wrote:
>>
>>> This would also be the design of MacCsound. IMO, the API that Matt's
>>> actually using should get synced up sometime with CS5.  There's a few
>>> differences between the two at the moment.  The need for string labels
>>> rather than indexes as well as being able to pass strings (in the
>>> latest version) as well as number between host and csound are the two
>>> differences I can think of at the top of my head.
>>>
>>> steven
>>>
>>>
>>> On Fri, 25 Mar 2005 00:39:11 +0000, Richard Dobson
>>>  wrote:
>>>
>>>> That would be the automation bus; I am trying to recall just how 
>>>> long ago it was
>>>> I suggested it....
>>>>
>>>> Richard Dobson
>>>>
>>>> gerard van dongen wrote:
>>>> ...
>>>>
>>>>> Define control signal-i/o in a generic way in the engine and a 
>>>>> seperate
>>>>> gui implementation/design tool to make the gui.
>>>>> The gui would all be done by a front end.
>>>>
>>>>
>>>> ...
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real 
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> The API should be changed to permit users to create, set, and get at 
> least MYFLT variables by name. I'm pretty sure it doesn't currently do 
> this.

What kind of variables are you referring to ?

> There is no reason these opcodes can't also be Csound API functions, as 
> long as the mixer opcodes become builtins so the buss arrays are 
> accessible to the API. If the mixer is in the API, then any number of 
> audio inputs and outputs can go into and come out of Csound to external 
> software.

But isn't your mixer interface C++, and the main Csound API is C ?

> The mixer is now working, and I will add it to SConstruct as soon as I 
> have tested the build and functionality on Linux.

I would rather suggest making it optional, with a default of not building.
By the way, I think CsoundVST should not be built by default, either (in fact,
it used to be disabled by default, but recent changes have apparently made
the default to compile CsoundVST, now I always have to use buildCsoundVST=0).


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote:

> By the way, I think CsoundVST should not be built by default, either 
> (in fact,
> it used to be disabled by default, but recent changes have apparently 
> made
> the default to compile CsoundVST, now I always have to use 
> buildCsoundVST=0).

Well, I build (and even use) CsoundVST routinely, so I like it built by 
default. However, I take your point, and I would suggest that eventually 
there be a "lowest common denominator" set of default build options. At 
this stage it's not really very important to me what's default and 
what's not. I realize that Cs5 is beta-stage software and I expect 
things to change frequently (and even disastrously at times). I just 
have to remember to run scons -h before compiling, I think I can do that. :)

Must remember the CVS -d option too...

Best,

dp




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

You mean like chani and chano ?

==John ffitch
>>>>> "Iain" == Iain Duncan  writes:

 Iain> That all sounds very very cool. What about a krate version of the Mixer 
 Iain> bus as well, ie kontrol bus? And would it be possible for some of those 
 Iain> mixer functions to be able to take krate args instead of irate ones for 
 Iain> dynamic mixer patching? And having the opcodes accessible as API 
 Iain> functions would be great as well.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net