The 'User-Friendly' Alternate Reality of Csound
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Re: Re: Re: Re: Re: Re: The 'User-Friendly' Alternate Reality of Csound
by jpff-2
::
Rate this Message:
>
> Let's say I have Csound built on my system with no optional > configurations. > Can I build each option individually as I need them, without re-compiling > Csound? E.G. FLTK, OSC, STK, Loris, etc. > > Best, > Jake Yes as long as you haave the headers for the same API version Actually not sre aout FLTK -- that is too enbedded for my taste, but that has been argumed endlessly ==John ff Send bugs reports to this list. To unsubscribe, send email sympa@... with body "unsubscribe csound" |
|
|
Re: Re: Re: Re: Re: Re: The 'User-Friendly' Alternate Reality of Csound
by Jacob Joaquin
::
Rate this Message:
That's great to hear. Now if I was to compile and install one of these optional configurations, without re-compiling Csound, where in the documentation can I find instructions on how to do this?
Best, Jake
|
|
|
Re: Re: Re: Re: Re: Re: Re: The 'User-Friendly' Alternate Reality of Csound
by Dr. Richard Boulanger-4
::
Rate this Message:
You should think about ways to continue supporting FLTK but not embed
it so deeply into the core. It should be mire of a plug-in. Sent from my Arp 2600 ;-) On Jul 12, 2009, at 6:52 PM, jpff@... wrote: >> >> Let's say I have Csound built on my system with no optional >> configurations. >> Can I build each option individually as I need them, without re- >> compiling >> Csound? E.G. FLTK, OSC, STK, Loris, etc. >> >> Best, >> Jake > > Yes as long as you haave the headers for the same API version > > Actually not sre aout FLTK -- that is too enbedded for my taste, but > that > has been argumed endlessly > > ==John ff > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@... with body > "unsubscribe csound" Send bugs reports to this list. To unsubscribe, send email sympa@... with body "unsubscribe csound" |
|
|
Re: The 'User-Friendly' Alternate Reality of Csound
by David Worrall
::
Rate this Message:
It seems to me that the _idea_ of being able to use a cut-down version
(CDV) is a good one. However, what's included, what's not must be defined by the conceptual design of the system as a whole, rather than some definition based on some loose agreement between the current needs of individual users. Someone might want FLTK, someone else MIDI but not python, python and OSC but not MIDI, LORIS opcodes etc. Then others might want filters and soundfile processing but not synthesis. Trying to build a system on that sort of basis quickly becomes a nightmare. SC is designed around the idea of a "sound server" and a language that supports/sends commands to it. While I'm not suggesting that is an optimal solution (I think there problems) the idea of functional segregation is a good idea. As Mike says, the current build options do provide various options, once you know what you're doing. But there doesn't seem to be any conceptual hierarchy beyond shall a feature be included or not, as well as the important one of K and S rate. So if you're interested in building a version with X but not Y, conceptually it's quite simple but implementing it seems to require more of an in- depth understanding of the whole system than should be necessary. If we have Sound: [input, output, synthesis, processing ] Graphic: [input, output, (synthesis, processing )] SoundControl: [input, output, dynamic] GraphicControl:[input, output, dynamic] - and this is mirrored in the documentation- The sources for each of these could be contained in various separate directories and it is clear what the limitations are - especially platform limitations. Perhaps separate directories for each platform as clearly indicated in directory name, including an AllPlat 'tag' IMO there needs to be no more than a dozen files/directories in at the top level, including a separate directory for tests and other 'guru' experiments. David On 13/07/2009, at 8:23 AM, Michael Gogins wrote: > I'm not sure whether you are talking about building, or about > installation. > > For installation on Linux, most of the things you talk about already > are separate packages. > > For installation on Windows, the next installer will provide the user > options on which subsets of Csound to install. > > For building, the build system already offers options for building or > not building each of these things. > > I would urge you to consider that what one user considers 'optional' > or 'outside' Csound is not necessarily the same as what another user > would. In such a case, I think it is better to be inclusive rather > than exclusive. > > But perhaps I'm not quite hearing what you are trying to say. > > Regards, > Mike > > On 7/12/09, Jacob Joaquin <jacobjoaquin@...> wrote: >> >> Okay, I think I see why my terminology is a bit confusing. I've >> been using >> the term plugin in a somewhat generic fashion, where 'plugin' seems >> to have >> an existing specific meaning in Csound. So perhaps it is indeed >> packaging >> in which I'm referring to. So let me sure I have this right. >> >> Being that the loris opcodes requires a special-case external >> dependency, it >> would be better if loris was removed from the main Csound source. >> Instead, >> loris should be placed into its own package, separate from the core >> Csound >> source code, in which users could install later. The package would >> include >> documentation, source to the loris opcodes, and perhaps the binaries. >> >> Plugin unit generators/opcodes that do depend on external >> dependencies would >> still be part of the csound core source. e.g. biquad. >> >> Other parts of Csound that may be separated from the core Csound >> source and >> broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK >> Widgets >> (maybe not this one), Virtual MIDI Keyboard (maybe not this one, >> etiher), >> Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes, >> Cscore. >> >> Best, >> Jake >> >> >> >> >> >> >> jpff-2 wrote: >>> >>>> >>>> I'm trying to make the case that optional features be placed >>>> outside of >>>> the >>>> main csound source, and treated as plugins. >>>> >>>> >>> >>> Still not sure I follow. Plugin opocodes are in Opcodes. OOps >>> are ones >>> that cannot be factored out. Engine is essential.... >>> >>> Still sounds like packaging >>> >>> >>> >>> >>> >>> >>> Send bugs reports to this list. >>> To unsubscribe, send email sympa@... with body >>> "unsubscribe >>> csound" >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html >> Sent from the Csound - General mailing list archive at Nabble.com. >> >> >> >> Send bugs reports to this list. >> To unsubscribe, send email sympa@... with body >> "unsubscribe >> csound" >> > > > -- > Michael Gogins > Irreducible Productions > http://www.michael-gogins.com > Michael dot Gogins at gmail dot com > > > Send bugs reports to this list. > To unsubscribe, send email sympa@... with body > "unsubscribe csound" ________________________________________________ David Worrall. - Experimental Polymedia: www.avatar.com.au - Education for Financial Independence: www.mindthemarkets.com.au Australian research affiliations: - Capital Markets Cooperative Research Centre: www.cmcrc.com - Sonic Communications Research Group: creative.canberra.edu.au/scrg - MARCS Auditory Laboratories: marcs.uws.edu.au Send bugs reports to this list. To unsubscribe, send email sympa@... with body "unsubscribe csound" |
|
|
Re: Re: Re: Re: Re: Re: The 'User-Friendly' Alternate Reality of Csound
by Michael Gogins-2
::
Rate this Message:
So you're talking about building.
. The answer to your question is yes. You pass the name of the target to SCons, but the name of the target is not always obvious. I use a shell script to build, with all my SConstruct options predefined, plus some additional wildard options. Then I can just say ./build.sh myplugin.so to build my plugin opcode. I have done this and it works fine. It should work other targets as well. Hope this helps, Mike On 7/12/09, Jacob Joaquin <jacobjoaquin@...> wrote: > > Let's say I have Csound built on my system with no optional configurations. > Can I build each option individually as I need them, without re-compiling > Csound? E.G. FLTK, OSC, STK, Loris, etc. > > Best, > Jake > > > Michael Gogins-2 wrote: >> >> I'm not sure whether you are talking about building, or about >> installation. >> >> For installation on Linux, most of the things you talk about already >> are separate packages. >> >> For installation on Windows, the next installer will provide the user >> options on which subsets of Csound to install. >> >> For building, the build system already offers options for building or >> not building each of these things. >> >> I would urge you to consider that what one user considers 'optional' >> or 'outside' Csound is not necessarily the same as what another user >> would. In such a case, I think it is better to be inclusive rather >> than exclusive. >> >> But perhaps I'm not quite hearing what you are trying to say. >> >> Regards, >> Mike >> >> On 7/12/09, Jacob Joaquin <jacobjoaquin@...> wrote: >>> >>> Okay, I think I see why my terminology is a bit confusing. I've been >>> using >>> the term plugin in a somewhat generic fashion, where 'plugin' seems to >>> have >>> an existing specific meaning in Csound. So perhaps it is indeed >>> packaging >>> in which I'm referring to. So let me sure I have this right. >>> >>> Being that the loris opcodes requires a special-case external dependency, >>> it >>> would be better if loris was removed from the main Csound source. >>> Instead, >>> loris should be placed into its own package, separate from the core >>> Csound >>> source code, in which users could install later. The package would >>> include >>> documentation, source to the loris opcodes, and perhaps the binaries. >>> >>> Plugin unit generators/opcodes that do depend on external dependencies >>> would >>> still be part of the csound core source. e.g. biquad. >>> >>> Other parts of Csound that may be separated from the core Csound source >>> and >>> broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK Widgets >>> (maybe not this one), Virtual MIDI Keyboard (maybe not this one, etiher), >>> Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes, Cscore. >>> >>> Best, >>> Jake >>> >>> >>> >>> >>> >>> >>> jpff-2 wrote: >>>> >>>>> >>>>> I'm trying to make the case that optional features be placed outside of >>>>> the >>>>> main csound source, and treated as plugins. >>>>> >>>>> >>>> >>>> Still not sure I follow. Plugin opocodes are in Opcodes. OOps are >>>> ones >>>> that cannot be factored out. Engine is essential.... >>>> >>>> Still sounds like packaging >>>> >>>> >>>> >>>> >>>> >>>> >>>> Send bugs reports to this list. >>>> To unsubscribe, send email sympa@... with body "unsubscribe >>>> csound" >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html >>> Sent from the Csound - General mailing list archive at Nabble.com. >>> >>> >>> >>> Send bugs reports to this list. >>> To unsubscribe, send email sympa@... with body "unsubscribe >>> csound" >>> >> >> >> -- >> Michael Gogins >> Irreducible Productions >> http://www.michael-gogins.com >> Michael dot Gogins at gmail dot com >> >> >> Send bugs reports to this list. >> To unsubscribe, send email sympa@... with body "unsubscribe >> csound" >> >> > > -- > View this message in context: > http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453191.html > Sent from the Csound - General mailing list archive at Nabble.com. > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@... with body "unsubscribe > csound" > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com Send bugs reports to this list. To unsubscribe, send email sympa@... with body "unsubscribe csound" |
|
|
Re: Re: Re: Re: Re: Re: The 'User-Friendly' Alternate Reality of Csound
by Jacob Joaquin
::
Rate this Message:
This does help. Is build.sh part of the Csound source, or a custom script for personal use?
Best, Jake
|
|
|
Re: Re: Re: Re: Re: Re: Re: The 'User-Friendly' Alternate Reality of Csound
by Michael Gogins-2
::
Rate this Message:
It's customized, but there are variants of it in CVS. You could
customize one of these yourself. The same goes for customizing custom.py, you could create a build.jj.sh that calls SCons with custom.jj.py. Regards, Mike On 7/12/09, Jacob Joaquin <jacobjoaquin@...> wrote: > > This does help. Is build.sh part of the Csound source, or a custom script > for > personal use? > > Best, > Jake > > > Michael Gogins-2 wrote: >> >> So you're talking about building. >> . >> The answer to your question is yes. You pass the name of the target to >> SCons, but the name of the target is not always obvious. >> >> I use a shell script to build, with all my SConstruct options >> predefined, plus some additional wildard options. Then I can just say >> ./build.sh myplugin.so to build my plugin opcode. I have done this and >> it works fine. It should work other targets as well. >> >> Hope this helps, >> Mike >> >> On 7/12/09, Jacob Joaquin <jacobjoaquin@...> wrote: >>> >>> Let's say I have Csound built on my system with no optional >>> configurations. >>> Can I build each option individually as I need them, without re-compiling >>> Csound? E.G. FLTK, OSC, STK, Loris, etc. >>> >>> Best, >>> Jake >>> >>> >>> Michael Gogins-2 wrote: >>>> >>>> I'm not sure whether you are talking about building, or about >>>> installation. >>>> >>>> For installation on Linux, most of the things you talk about already >>>> are separate packages. >>>> >>>> For installation on Windows, the next installer will provide the user >>>> options on which subsets of Csound to install. >>>> >>>> For building, the build system already offers options for building or >>>> not building each of these things. >>>> >>>> I would urge you to consider that what one user considers 'optional' >>>> or 'outside' Csound is not necessarily the same as what another user >>>> would. In such a case, I think it is better to be inclusive rather >>>> than exclusive. >>>> >>>> But perhaps I'm not quite hearing what you are trying to say. >>>> >>>> Regards, >>>> Mike >>>> >>>> On 7/12/09, Jacob Joaquin <jacobjoaquin@...> wrote: >>>>> >>>>> Okay, I think I see why my terminology is a bit confusing. I've been >>>>> using >>>>> the term plugin in a somewhat generic fashion, where 'plugin' seems to >>>>> have >>>>> an existing specific meaning in Csound. So perhaps it is indeed >>>>> packaging >>>>> in which I'm referring to. So let me sure I have this right. >>>>> >>>>> Being that the loris opcodes requires a special-case external >>>>> dependency, >>>>> it >>>>> would be better if loris was removed from the main Csound source. >>>>> Instead, >>>>> loris should be placed into its own package, separate from the core >>>>> Csound >>>>> source code, in which users could install later. The package would >>>>> include >>>>> documentation, source to the loris opcodes, and perhaps the binaries. >>>>> >>>>> Plugin unit generators/opcodes that do depend on external dependencies >>>>> would >>>>> still be part of the csound core source. e.g. biquad. >>>>> >>>>> Other parts of Csound that may be separated from the core Csound source >>>>> and >>>>> broken in packages include: CsoundAC, CsoundVST, TclCsound, FLTK >>>>> Widgets >>>>> (maybe not this one), Virtual MIDI Keyboard (maybe not this one, >>>>> etiher), >>>>> Loris Opcodes, LADPSA, Python opcodes, Image Processing opcodes, >>>>> Cscore. >>>>> >>>>> Best, >>>>> Jake >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> jpff-2 wrote: >>>>>> >>>>>>> >>>>>>> I'm trying to make the case that optional features be placed outside >>>>>>> of >>>>>>> the >>>>>>> main csound source, and treated as plugins. >>>>>>> >>>>>>> >>>>>> >>>>>> Still not sure I follow. Plugin opocodes are in Opcodes. OOps are >>>>>> ones >>>>>> that cannot be factored out. Engine is essential.... >>>>>> >>>>>> Still sounds like packaging >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Send bugs reports to this list. >>>>>> To unsubscribe, send email sympa@... with body >>>>>> "unsubscribe >>>>>> csound" >>>>>> >>>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24452358.html >>>>> Sent from the Csound - General mailing list archive at Nabble.com. >>>>> >>>>> >>>>> >>>>> Send bugs reports to this list. >>>>> To unsubscribe, send email sympa@... with body >>>>> "unsubscribe >>>>> csound" >>>>> >>>> >>>> >>>> -- >>>> Michael Gogins >>>> Irreducible Productions >>>> http://www.michael-gogins.com >>>> Michael dot Gogins at gmail dot com >>>> >>>> >>>> Send bugs reports to this list. >>>> To unsubscribe, send email sympa@... with body "unsubscribe >>>> csound" >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453191.html >>> Sent from the Csound - General mailing list archive at Nabble.com. >>> >>> >>> >>> Send bugs reports to this list. >>> To unsubscribe, send email sympa@... with body "unsubscribe >>> csound" >>> >> >> >> -- >> Michael Gogins >> Irreducible Productions >> http://www.michael-gogins.com >> Michael dot Gogins at gmail dot com >> >> >> Send bugs reports to this list. >> To unsubscribe, send email sympa@... with body "unsubscribe >> csound" >> >> > > -- > View this message in context: > http://www.nabble.com/The-%27User-Friendly%27-Alternate-Reality-of-Csound-tp24393267p24453845.html > Sent from the Csound - General mailing list archive at Nabble.com. > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@... with body "unsubscribe > csound" > -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com Send bugs reports to this list. To unsubscribe, send email sympa@... with body "unsubscribe csound" |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
