Re: [Bluemusic-users] More on Zak
Brought to you by:
kunstmusik
From: Steven Yi <ste...@gm...> - 2005-07-29 09:31:34
|
Hi Michael, Hope you managed to recover your work from you C Drive! Viruses and failing hard drives are such a drag and I hope you haven't lost any work! Thanks very much for you thoughts on Zak, Mixers, Channels, and Busses. I think it's very very important that if we put such a thing in blue that it really be able to automate as much as possible to hand all of these things automatically for the user. I think prototyping with BSB so far has helped to bring some of these issues out a bit for myself as well as help to visualize the issues. I am going to review Michael Bechard's email now and perhaps with your thoughts and everyone else's, we can really work out a long-term solution that can make this aspect of Csounding much easier and a versatile solution that can work with all of our different needs. Thanks again! steven On 7/28/05, Michael Rempel <mic...@sh...> wrote: > Hello All >=20 > I have been off list for a week or so because of a virus. I had to rebuil= d > my C drive. As a result I can not back track this thread, so please forgi= ve > me if my suggestions have already been discussed. >=20 > The Zak system is a very versitile tool, but one of it's shorcomings IMHO= is > that it does not follow a true mixer paradigm. There is no way to > distinguish the purpose of a Zac variable or signal. While the flexabilit= y > is nice, it is a pain to work with especially if you are doing what blue > will want to do with it. >=20 > If we organize a macro like structure with a pre-pended purpose such as > <bzChan-1> where bz is blue Zak Chan for channel and the number or name > after that, then the macro resolver can assign zak numbers as required. >=20 > And similar to a conventional mixer, there could be a mixer instrument th= at > can resolve the channels into a mix. Each channel should have a bzChanLev= el > control which is 0-1 ranged level which can be set in the mixer, or in th= e > conrol chain, default 1. >=20 > in addition to channels, busses are a useful thing. Bus levels need to be > set in the control chain as signals are fed into the bus, but the output > level of the bus needs to be controlled by it's own coresponding zak var, > again settable anywhere in the tool chain. >=20 > Effects are a special case of Busses. They are not zeroed after use like > other channels. >=20 > The other factor that needs discussion is pan. I think several pan models > need to be implementable. I work in surround a fair bit, and would like t= o > see an x-y-z-size pan as a possibility without loosing the simplicity of = a 2 > channel pan for normal operation. I dont have this figured out. It may be > that Steven's idea of a 2 channel solution simply needs to be disableable= . >=20 > Michael Rempel >=20 > --- Steven Yi <ste...@gm...> wrote: >=20 > > -Zak Mixer/Settings Panel > > -enable/disable zak features for project (so, > > not forced to use if > > not interested in) >=20 > If zak disabled, would you go with global vars > instead? >=20 > > -Can set number of channels to use, or can be > > hardcoded to a very > > high number like 128 > > ... > > -Perhaps can work out routing options, so > > possible to have > > sends/receives to allow easier setting up of global > > effects for > > multliple channels >=20 > Perhaps we'd better stay away from the "channel" > nomenclature, since, as you mentioned before, blue and > csound really don't have channels. Since what we're > really talking about here are zak/global controllers, > why don't we just call them that? >=20 > > -will have sliders to control gain settings for > > channel >=20 > And panning controls too, right? >=20 > > -Zak In/Out Widget in BSB - can read from project > > how many channels > > there are and only allow selection of channels which > > are avaialable in > > project > > >=20 > Sounds good, though reading the selection of channels > in use for zak input could get sticky. Might just want > to look for a zakinit opcode and leave it at that. >=20 > Michael Bechard >=20 >=20 >=20 > ____________________________________________________ > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic= k > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO Septem= ber > 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > |