Control flow
| Date | 2006-02-20 22:31 |
| From | Tobiah |
| Subject | Control flow |
Is something like this possible with csound? aout = 0 for rep in range(100): pitch = rnd(1000) + 100 asig oscil 1000 pitch 1 aout = aout + asig out aout |
| Date | 2006-02-20 22:57 |
| From | Istvan Varga |
| Subject | Re: Control flow |
| Attachments | None |
| Date | 2006-02-20 23:36 |
| From | Tobiah |
| Subject | Re: Control flow |
> If you mean 100 parallel instances of the oscillator, then you can get > that with a recursive user defined opcode Right. I thought of that after my post. Thanks for the example, it clears up some things for me about UDO's. I tried them for the first time today. > is also not as efficient as just using macros): How do you envision this working through macros? Thanks, Tobiah |
| Date | 2006-02-20 23:52 |
| From | Istvan Varga |
| Subject | Re: Control flow |
| Attachments | None |
| Date | 2006-02-21 09:40 |
| From | Victor Lazzarini |
| Subject | Re: Control flow |
Another possibility is to use a scripting language of your choice to produce the code and write it into a file for csound to perform. Python seems to be a popular choice. Tcl is another one (the file gen.tcl in the sources examples/tclcsound directory demonstrates it). You can use any language you like, but the advantage of Python or Tcl is that your code can also control Csound performance (using the API). Victor At 23:52 20/02/2006, you wrote: >On Tuesday 21 February 2006 00:36, Tobiah wrote: > > > How do you envision this working through macros? > >Of course, macros are only an option if the number of oscillators >is constant (otherwise you would need the dynamic instantiation >of oscillators that is possible with user defined opcodes and >subinstruments). The example below is uglier than the previous one, >but is faster. > > |
| Date | 2006-02-21 19:20 |
| From | Tobiah |
| Subject | Re: Control flow |
Victor Lazzarini wrote: > Another possibility is to use a scripting language of your choice > to produce the code and write it into a file for csound to perform. > I guess that's really the best option. I've definitely been driven to that in the past. I invariably use a program to generate scores, and it often makes sense to do that with orchestras as well. |
| Date | 2006-03-02 04:26 |
| From | Iain Duncan |
| Subject | Re: Control flow |
A further advantage to the approach Victor mentions is that in the process you learn a language that becomes an invaluable tool for actually writing instruments and scores. I personally like python because the python extensions for gvim are fantastic and it is very easy to work on my orc/sco files with python from within a gvim session. If I were to go back five years to tell myself what to learn sooner I would say gvim, python, regular expressions. Much coding time would be saved. ;) Iain Victor Lazzarini wrote: > Another possibility is to use a scripting language of your choice > to produce the code and write it into a file for csound to perform. > > Python seems to be a popular choice. Tcl is another one (the > file gen.tcl in the sources examples/tclcsound directory demonstrates > it). You can use any language you like, but the advantage of Python or > Tcl is that your code can also control Csound performance (using the API). > > Victor > > At 23:52 20/02/2006, you wrote: > >> On Tuesday 21 February 2006 00:36, Tobiah wrote: >> >> > How do you envision this working through macros? >> >> Of course, macros are only an option if the number of oscillators >> is constant (otherwise you would need the dynamic instantiation >> of oscillators that is possible with user defined opcodes and >> subinstruments). The example below is uglier than the previous one, >> but is faster. >> >> |
| Date | 2006-03-02 08:40 |
| From | Victor Lazzarini |
| Subject | Re: Control flow |
Or emacs and elisp? The csound-x emacs mode is very useful. At 04:26 02/03/2006, you wrote: >A further advantage to the approach Victor mentions is that in the >process you learn a language that becomes an invaluable tool for >actually writing instruments and scores. I personally like python >because the python extensions for gvim are fantastic and it is very easy >to work on my orc/sco files with python from within a gvim session. > >If I were to go back five years to tell myself what to learn sooner I >would say gvim, python, regular expressions. Much coding time would be >saved. ;) > >Iain > >Victor Lazzarini wrote: > > Another possibility is to use a scripting language of your choice > > to produce the code and write it into a file for csound to perform. > > > > Python seems to be a popular choice. Tcl is another one (the > > file gen.tcl in the sources examples/tclcsound directory demonstrates > > it). You can use any language you like, but the advantage of Python or > > Tcl is that your code can also control Csound performance (using the API). > > > > Victor > > > > At 23:52 20/02/2006, you wrote: > > > >> On Tuesday 21 February 2006 00:36, Tobiah wrote: > >> > >> > How do you envision this working through macros? > >> > >> Of course, macros are only an option if the number of oscillators > >> is constant (otherwise you would need the dynamic instantiation > >> of oscillators that is possible with user defined opcodes and > >> subinstruments). The example below is uglier than the previous one, > >> but is faster. > >> > >> |
| Date | 2006-03-03 05:37 |
| From | Iain Duncan |
| Subject | Re: Control flow |
> Or emacs and elisp? The csound-x emacs mode is very useful. Yeah, that would be the "other leading brand" tee hee. For my money though, I like the fact that python is used both within csound and gvim, as well as for extensions to many other audio apps. Yeah I know, common lisp music, snd, etc. I'll learn it eventually too, all the elite haxors tell ya to eat your lisp vitamins. ;) Iain |