Thread: [Bluemusic-users] A thought about effects
Brought to you by:
kunstmusik
From: Michael B. <got...@ya...> - 2007-08-14 14:05:50
|
I'm getting to the point now where allot of my instruments are based heavil= y 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, ord= er, etc.), but also helps performance, sometimes significantly.=0A=0AAnyway= , my point in bringing this up is that the downside is that it makes the in= struments 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, a= nd make these savable just like the effects and instruments libraries. All = gui settings would be saved, of course. Thoughts?=0A=0AMichael Bechard=0A= =0A=0A=0A=0A =0A_____________________________________________________= _______________________________=0APinpoint customers who are looking for wh= at you sell. =0Ahttp://searchmarketing.yahoo.com/ |
From: Steven Y. <ste...@gm...> - 2007-08-14 19:41:05
|
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 > |
From: peiman <pei...@gm...> - 2007-08-16 14:44:10
|
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. |
From: peiman <pei...@gm...> - 2007-08-16 15:07:23
|
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. |
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 > |
From: Steven Y. <ste...@gm...> - 2007-08-20 03:48:08
|
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 > |
From: peiman <pei...@gm...> - 2007-08-20 13:46:57
|
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. |
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 > |
From: peiman <pei...@gm...> - 2007-08-20 22:00:36
|
Thanks Steven, That sound great. Peiman Steven Yi wrote: > > 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 >> > > ------------------------------------------------------------------------- > 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#a12244789 Sent from the Csound - Blue - User mailing list archive at Nabble.com. |