Re: [Bluemusic-users] A thought about effects

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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
>