Re: [Bluemusic-users] A thought about effects
Brought to you by:
kunstmusik
From: Steven Y. <ste...@gm...> - 2007-08-20 03:51:34
|
Hi Peiman, I've debated introducing different sound layer types but usually revert to keeping it the way it is due to the complexities it introduces. I know that I could probably write a blue program script in python that could do the import/export of bundles of track data and would think that might be a way to go, though if it's deemed useful could be done in Java and made a built-in part of blue. steven On 8/16/07, peiman <pei...@gm...> wrote: > > Just to add another thought to my previous post. If the instrument effects > were paired with the instruments themselves, keeping the master track and > the ability to add buses intact (in the mixer view) would it be possible if > buses and the master channel actually corresponded to individual (different > than normal) tracks on the time-line that could be hidden by the user if > desired? So the automation for any effects inserted on these channels would > automatically be added to the corresponding tracks of the channels only > (much like a sequencer). In this case it may be possible to add the ability > to export bus tracks and the mixer track data together with the automation > and effects information, adding them to a presets menu for use in other > sessions. > > Best > Peiman > > > peiman 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#a12183233 > 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 > |