Re: [Bluemusic-users] A thought about effects
Brought to you by:
kunstmusik
From: Steven Y. <ste...@gm...> - 2007-08-20 17:20:27
|
Hi Peiman, I think I'll look at implementing the mixer strip on the timeline first before looking at one in the instrument area. I'm wondering how if embedding and having always-on code available in an instrument will alleviate needing a strip in the instrument area so will want to experiment with that first. As for the python orchestra library, I started to document it a while ago here: http://csounds.com/stevenyi/python/index.html but have not updated that since that draft in 2003. The library itself is quite small and simple really and the principles haven't changed since I first put it together. It is included with blue in the blue/lib/pythonLib/orchestra folder. You can look at my pieces in the blue/examples/pieces/stevenYi folder for usage. In my pieces you'll normally find on the top sound layer a single python object for setup of the performers and performerGroups (those were used in Etude quite a bit). In other objects you'll find some performance functions that are piece-specific. If you have any other questions just let me know! steven On 8/20/07, peiman <pei...@gm...> wrote: > > Hi Steven, > Having a mixer strip near the time-line does sound great. Particularly as > the shift-p5 shortcut does not seem to work on os x. In fact non of the > shortcuts in blue involving the "F keys" work on my powerbook G4 (this may > be a laptop thing). I see your point about adding the mixer channel UI to > the instrument. I think a single strip with a drop-down menu as you > mentioned, would be brilliant in the time-line window. Could there not be a > similar strip also in the orchestra window but this time when clicking on an > instrument the strip automatically changes to the mixer channel of that > particular instrument? This could be helpful in cases were the instrument is > highly depended on it's effects. > > Is there a source where I can read more about your python orchestra library? > It sounds very interesting and I would very much like to know more about it. > > Thanks so much for your reply > Peiman > > > > Steven Yi wrote: > > > > Hi Peiman, > > > > The abstraction of not having instruments and tracks have a one-to-one > > relationship is intentional and is something I thought about and > > decided to do this way. (There might be more emails on this in the > > mailing list archive). I prefer it this way as it is more flexible > > how one organizes one's own material on the timeline. On the other > > hand it limits in certain ways, but I think it is worth it personally. > > > > There would be no way I could really do the kinds of things I do with > > my orchestral composition library if notes generated had to only be > > for one instrument. It'd also make it very complicated to parse and > > require a guarantee when using fractional instrument numbers that they > > go with the instrument. I might use 10 instances of the instrument > > with 10 performer objects in my library, each creating their own > > distinct musical lines, and visually I might want to represent that on > > 10 different sound layers. This however would not be possible on a > > MIDI based environment as far as I am aware. > > > > I am not sure if adding the mixer channel UI to the instrument would > > be the way to go personally as I find that most manipulations to the > > mixer are done in context visually when working the timeline, so I > > find it easier to pop open the mixer with shift-f5 and modify while > > viewing the timeline behind it. I have seen how some MIDI > > environments will show a mixer channel strip when working in their > > main timeline area, with the mixer channel strip changing according to > > which track they are on. I can imagine creating some kind of > > mini-mixer panel that could be embedded on the left-hand side of the > > score area. This could be nice as it would be much longer and could > > be wider so maybe more of the effects bins could be visible. Maybe a > > single strip, then at top a dropdown or a right-clip popup menu could > > be used to change mixer channels. Any thoughts? > > > > steven > > > > On 8/16/07, peiman <pei...@gm...> wrote: > >> > >> Hi Steven, > >> > >> I like this idea. Portability apart, what I currently fined confusing in > >> blue is the way the mixer is visually laid out like a conventional > >> sequencer > >> but the channels represent instruments instead of tracks. Since I am > >> always > >> oscillating between blue and protools this requires a complete change of > >> mindset that can get confusing at early hours of the morning! > >> > >> I think it would certainly be visually more coherent if the individual > >> channels on the mixer were embedded in the instrument window, paired with > >> their corresponding instrument. While still keeping the master channel > >> and > >> buses for global or user-defined effects configuration. > >> > >> Best > >> Peiman > >> > >> > >> Steven Yi wrote: > >> > > >> > Hi Michael, > >> > > >> > Your email is timely as I have been thinking about the same issue! > >> > I've been looking at MIDI based instruments and studying them and > >> > thinking about instrument design in general and will mention my notes > >> > and thoughts here. > >> > > >> > Something that Csound inherently lacks as an abstract concept when > >> > designing instruments is that a single instrument generally consists > >> > of signal generation and modification both on a per-note instance as > >> > well as a global always-on instance. > >> > > >> > The general way to do that is to create a first instrument which > >> > creates per-note audio, then have that send signals to a second > >> > instrument which is always on for processing. Generally there may be > >> > more than one per-note instrument instance but only one always-on > >> > instrument instance. This idea can be easily seen in the case of a > >> > guitar, where multiple strings may play notes but the sound is mixed > >> > and processed by the resonant body which is "always-on". > >> > > >> > In blue, currently to achieve this kind of signal setup, one can > >> > create the instrument and then user the mixer with effects as the > >> > always-on part of that path. However, as Michael mentioned, this is > >> > problematic in terms of portability. Also, it separates visually the > >> > parts of the instrument which are meant to be worked with together. > >> > > >> > So, on my mind is allow instruments to generate pre and post always-on > >> > code. Post always-on code is no problem as it can dynamically create > >> > and append to the instrument list and add a note that lasts the > >> > duration of the score + extra time. What is more difficult is pre > >> > stuff. This would be for things like an always-on oscillator for > >> > monosynths if you wanted to do a design like that, or for doing things > >> > like always-on LFO. I don't know how important those are though, > >> > while post always-on seems to be very common in instrument design. So > >> > maybe just post always-on code (and just calling it always-on code) > >> > would be enough. > >> > > >> > The way I imagined it was having an extra tab for always-on instr > >> > code. An extra pair of meta opcodes could be made, somewhat like > >> > blueMixerOut (maybe blueSend and blueReceive ?) could be used to do > >> > communication. UI Widgets could all be placed in the same panel > >> > though some might be routed to per-instance audio code and others to > >> > always-on instr code. There shouldn't be problems there as already the > >> > idea of configuring a widget is static to all instr instances. > >> > > >> > How does this all sound? > >> > > >> > Also, as something that popped into my mind while thinking about all > >> > of this is somehow embedding effects into BSB instrument panels. The > >> > idea of grouping widgets together into a logical unit so that one > >> > could do things like build up a library of ENV generators, oscil > >> > banks, etc. But not just for BSB, but also for effects and > >> > ObjectBuilder (it would have to work differently here of course). > >> > Will have to think this one through very carefully. > >> > > >> > Thanks! > >> > steven > >> > > >> > > >> > > >> > On 8/14/07, Michael Bechard <got...@ya...> wrote: > >> >> I'm getting to the point now where allot of my instruments are based > >> >> heavily on their effects, with the actual instrument being rather > >> basic. > >> >> This not only allows me to develop sounds more quickly (via the > >> effects' > >> >> gui's, order, etc.), but also helps performance, sometimes > >> significantly. > >> >> > >> >> Anyway, my point in bringing this up is that the downside is that it > >> >> makes the instruments themselves less portable. What I would like > >> would > >> >> be the ability to package up a series of effects into one bundle, a > >> kind > >> >> of poly-effect, and make these savable just like the effects and > >> >> instruments libraries. All gui settings would be saved, of course. > >> >> Thoughts? > >> >> > >> >> Michael Bechard > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> ____________________________________________________________________________________ > >> >> Pinpoint customers who are looking for what you sell. > >> >> http://searchmarketing.yahoo.com/ > >> >> > >> >> > >> ------------------------------------------------------------------------- > >> >> This SF.net email is sponsored by: Splunk Inc. > >> >> Still grepping through log files to find problems? Stop. > >> >> Now Search log events and configuration files using AJAX and a > >> browser. > >> >> Download your FREE copy of Splunk now >> http://get.splunk.com/ > >> >> _______________________________________________ > >> >> Bluemusic-users mailing list > >> >> Blu...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/bluemusic-users > >> >> > >> > > >> > > >> ------------------------------------------------------------------------- > >> > This SF.net email is sponsored by: Splunk Inc. > >> > Still grepping through log files to find problems? Stop. > >> > Now Search log events and configuration files using AJAX and a browser. > >> > Download your FREE copy of Splunk now >> http://get.splunk.com/ > >> > _______________________________________________ > >> > Bluemusic-users mailing list > >> > Blu...@li... > >> > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > >> > > >> > > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/A-thought-about-effects-tf4267525.html#a12182693 > >> Sent from the Csound - Blue - User mailing list archive at Nabble.com. > >> > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Splunk Inc. > >> Still grepping through log files to find problems? Stop. > >> Now Search log events and configuration files using AJAX and a browser. > >> Download your FREE copy of Splunk now >> http://get.splunk.com/ > >> _______________________________________________ > >> Bluemusic-users mailing list > >> Blu...@li... > >> https://lists.sourceforge.net/lists/listinfo/bluemusic-users > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Bluemusic-users mailing list > > Blu...@li... > > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > > > > > > -- > View this message in context: http://www.nabble.com/A-thought-about-effects-tf4267525.html#a12236257 > Sent from the Csound - Blue - User mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Bluemusic-users mailing list > Blu...@li... > https://lists.sourceforge.net/lists/listinfo/bluemusic-users > |