Score Alignment Utility

[Stéphane Rollandin]

> No environment variables; no installer; different versions of Csound can
> coexist without problems.

We have been asking for this for ages...

Stef




Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[David Worrall]

It is good to here that it is not just me banging on about these  
issue. It is simply not true - or a solution - to assume that build  
difficulties mean "(dumb) newbie at work." In another current thread  
(Sugar on a Stick - and OLPCsound) On 03/07/2009, at 7:01 AM, Michael  
Gogins wrote:

> As I have mentioned several times on this list, making the Csound API
> independent of the Python version is not practical.
>
> We use SWIG to generate the Python wrapper, because it saves a simply
> enormous amount of work to do so. Using SWIG also makes it easy to
> generate two of the other wrappers: the Lua API and the Java API (the
> Lisp API is done with cffi, which is different).
>
> SWIG, however, makes the Python wrapper depend on the specific version
> of Python.

As I and others have mentioned several times on this list, keeping the  
Csound API dependent on a specific version of Python is not practical  
from a user
(as opposed to a developer clique) perspective.
As I have mentioned several times on this list, there is a middle way:

1) It is not using SWIG to generate the wrapper that creates the  
dependency. It is the way it is (not) used that creates the  
dependency. The build process needs to be made easy enough that the  
user can download the sources and use easy-install. Lots of complex  
packages out there do this. However it requires a

2) Change in the oligarchical 'priesthood' approach to developer  
status. (Notice how warmly Brian's recent offer to become involved in  
OSX-oriented development was met? NOT!  I hope he's not holding his  
breath!) This would mean that the whole idea of there not being a  
version build available would more likely to disappear. jp's recent  
Adminstrivia Message said:
>  Newbies are
> sometimes afraid to post because they read discussions about the
> incomprehensible deep inner workings, and all they want to know is how
> to get a sound to come out of their iBook.  Rest assured that your
> question will be answered quickly, and (usually) in a helpful and
> courteous manner.  We've all been there.  Please post.


This could have come straight out of Hesse's The Glass Bead Game! Your  
questions may be answered but your suggestions frequently ignored.  
Afterall, the priests far to busy doing important things like  
producing the next version release, to fix "newbie problems. Get back  
in your box and genuflect,  genuflect,  genuflect!

Michael recently said
> I really don't understand the difficulty with the Windows installers.
> I routinely test it at home and at work; and at work, i uninstall
> Csound before installing it again. It always just runs out of the box.

The difficulty is not a failure of the people trying to do the  
install, it a development process failure. We all know how hard it is  
to do the n'th correction of a text we've written, whereas fresh eyes  
see the flaws easily. Ditto SW development.

On 03/07/2009, at 4:26 AM, Dr. Richard Boulanger wrote:

> I can't agree more.
>
> We desperately need a simple *installable* Windows version of  
> Csound5 with the QuteCsound front-end - as part of the package.
>
> I can't tell you how many Electronic Musicians, Synth Majors, Synth  
> professor, and very skilled and
> Experienced Computer Music/Electronic Music colleagues - just give  
> UP!  When common sense fails,
> when logic fails, when professional standards are not met... they  
> move on - to the TONS of other
> great and powerful tools at their disposal.
>
> At least there is NOW a Macintosh version that simple installs in a  
> clean and professional way, although
> one has to find and know to install QuteCsound too... and even then,  
> there is confusion about which version
> will work with which version and platform.

It is somewhat consoling to here your  build difficulty anecdotes.  
Unfortunately the Mac version is not as up to the standard you think.
As Victor said earlier in this thread
> The Intel binaries I build are linked against MacPython 2.5. But it's
> done in 10.4 (at the moment), so no guarantees for OSX 10.5.

So around we go again. Problems mentioned, excuses (complexity, blah,  
blah) offered. Solution: People disappear (back) to a more user-
oriented environment.

And for the record... Csound may be fantastic, but it really is no  
more complex that Supercollider. Bigger, yes, more weighed down by its  
own history and self importance, yes, but not more complex.

None of my posts on this are meant personally. I have considerable  
regard for the work of many on this list. But the elephant (and rhino)  
in the room need to be identified for what they are.
In the meantime, when people as whether they should learn csound, I  
continue to say "not yet, not yet".

D.
...

> -dB
>
>
> On Jul 2, 2009, at 1:37 PM, Jacob Joaquin wrote:
>
>>
>>
>> Felipe Sateler wrote:
>>>
>>> I still wonder why regular users need to bother with building  
>>> csound.
>>> There is *no* need for that.
>>> Just to make it clear: you do *not* need to build csound to use the
>>> API. Unless the binary packages for OSX and Windows don't install  
>>> the
>>> headers (which I'd be surprised to learn they don't).
>>>
>>
>> Python does not work with the Csound API on my system. So I have to  
>> build it
>> to use it.
>>
>>
>> Felipe Sateler wrote:
>>>
>>> BTW, I do agree the csound build system is less than optimal, but it
>>> is not easy to cater for all use cases. Anyways, it is not that hard
>>> either: setup the appropriate environment (ie, install all needed
>>> dependencies), setup your path and specific flags in custom.py and  
>>> run
>>> scons with the wanted flags. If you have build errors, report them  
>>> so
>>> that the minimum versions of dependencies are adjusted or the  
>>> problem
>>> is fixed within csound.
>>>
>>
>> Hard is a relative term.  Setting up the appropriate environment,
>> dependencies, paths, flags, etc...  There  are lots of people who  
>> have no
>> clue how to interact with these technical hurdles, who are still very
>> capable of writing Csound and python code.  Generally speaking, for  
>> every
>> obstacle there is to get Csound up and running, we lose potential  
>> Csounders.
>> Unfortunately, Csound has more obstacles than just about anything  
>> else out
>> in the wild.
>>
>> For all the time and hard work the developers and other put into  
>> Csound
>> (which I truly appreciate), much of it is wasted because of often
>> unnecessary technical hurdles for newbies.  There are some  
>> technical issues
>> that may never be eliminated, I understand this, but there is  
>> certainly much
>> streamlining that can be done.  I'm willing to do my part.
>>
>> Plus, Csound isn't the only game in town, anymore;  It's hard  
>> enough to get
>> people to give Csound a try with other great music tools such as  
>> MaxMSP,
>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to  
>> grow the
>> Csound community, we have knock off this technical elite attitude,  
>> and start
>> looking at Csound through the eyes of newbies.
>>
>> My two cents.
>> Jake
>>
> ...
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body  
> "unsubscribe csound"

________________________________________________
David Worrall.
- Experimental Polymedia:  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au







Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[francibal]

Dear all,
I'm a beginner, and i have no knowledge in programming, but i work with a pc windows (xp-vista),
and i never had problems. I have installed many different versions, and both float and double, and many times i have disinstalled and again, but always it were all ok. And i'm not so able with a pc.
Csound is not so easy at begin, but with a little bit (and with a great help from You), one can understand how to work. A new frontend would be really a pleasure. I use scite(!), and i'm studying emacs
(thanks Mr Rollandin!), and for me it is sufficient. Maybe more experienced users, like most of You, have some differents problems, I suppose.

Only for report, from a lovers of csound,

ciao, and thanks for all,

fran.

[David Worrall]

Fran,
I am pleased that you don't have problems doing an install that suits  
you. And that you enjoy using it.
Thus, the difficulties we are discussing need not concern you.

Bbuild difficulties and usage difficulties are different - I think it  
is best not to confuse them.

D
On 03/07/2009, at 8:55 AM, francibal wrote:

>
> Dear all,
> I'm a beginner, and i have no knowledge in programming, but i work  
> with a pc
> windows (xp-vista),
> and i never had problems. I have installed many different versions,  
> and both
> float and double, and many times i have disinstalled and again, but  
> always
> it were all ok. And i'm not so able with a pc.
> Csound is not so easy at begin, but with a little bit (and with a  
> great help
> from You), one can understand how to work. A new frontend would be  
> really a
> pleasure. I use scite(!), and i'm studying emacs
> (thanks Mr Rollandin!), and for me it is sufficient. Maybe more  
> experienced
> users, like most of You, have some differents problems, I suppose.
>
> Only for report, from a lovers of csound,
>
> ciao, and thanks for all,
>
> fran.
> --
> View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24315191.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"

________________________________________________
David Worrall.
- Experimental Polymedia:  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au







Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Michael Gogins-2]

I don't at all appreciate the tone in some of the posts to which I am
responding, and I would appreciate an apology.

I do not view myself as a member of any sort of "priesthood," and views that
I do are contradicted by the extensive efforts that I have made to enable
other people easily to use Csound and CsoundAC. I have contributed a build
system that actually does build Csound on all platforms, after other
approaches failed to do so; I have written a tutorial introduction to Csound
that several have told me is quite useful to beginners; and I have written
two of the several guides to building Csound, including the one in the
Csound manual, and a separate standalone guide to building on Windows.

I don't view any of the other committed Csound developers as a "priesthood"
either. But most of us are quite busy and Csound is one part of what we do.

Now, I would like to address some substantive points.

I'm sorry, but it is indeed the use of SWIG that creates a dependency on a
specific version of Python, that is just how SWIG works. I have looked
through the SWIG documentation and mailing list for pointers on this issue,
and everybody just builds version-specific wrappers. In fact, this is the
case with most Python extension modules -- not just ones built with SWIG.

If anyone happens to know how to get SWIG to make a non-version-specific
wrapper, I will admit that I am wrong, I would be very glad to hear about
it, and I would definitely try to adopt it. Otherwise, please do not repeat
factual errors.

The use of a specific version of Python does not prevent users from using
Csound with or without Python. You can have several versions of Python
installed on the same computer and they will happily co-exist. You can use
one version of Python to run one Python extension module that is specific to
that version, and you can use another version of Python to run another
Python extension module that is specific to that version. You can do this by
setting up different "environments" for different versions of Python. You
can do this in a batch file that sets the appropriate PATH and other
environment variables for running Csound with its required version of
python, and another batch file for running other programs that need other
versions of Python.

It also, of course, is possible to simply throw out annoying parts of
Csound, as Art Hunkins has so clearly explained.

In the meantime, be assured that I will make every reasonable effort to make
the installer, and Csound, easier to use. More information about specific
problems, including OS and Csound and Python versions, and screen shots of
error messages, would be most useful.

I am considering creating two installers, one with a "cut-down" release of
Csound, and one with all bells and whistles including all the language APIs.
Then the installer with Python stuff wouldn't have to try to figure out what
is what on the installee's computer.

I also will look into changing the build system to use Python distutils to
make the Python extension module, although I am not sure that this will
really be an improvement.

Regards,
Mike

----- Original Message -----
From: "DavidW" <vip@...>
To: <csound@...>
Sent: Thursday, July 02, 2009 6:54 PM
Subject: [Csnd] Re: Building Python API (was Re: : Score Alignment Utility)

> It is good to here that it is not just me banging on about these  issue.
> It is simply not true - or a solution - to assume that build  difficulties
> mean "(dumb) newbie at work." In another current thread  (Sugar on a
> Stick - and OLPCsound) On 03/07/2009, at 7:01 AM, Michael  Gogins wrote:
>
>> As I have mentioned several times on this list, making the Csound API
>> independent of the Python version is not practical.
>>
>> We use SWIG to generate the Python wrapper, because it saves a simply
>> enormous amount of work to do so. Using SWIG also makes it easy to
>> generate two of the other wrappers: the Lua API and the Java API (the
>> Lisp API is done with cffi, which is different).
>>
>> SWIG, however, makes the Python wrapper depend on the specific version
>> of Python.
>
>
> As I and others have mentioned several times on this list, keeping the
> Csound API dependent on a specific version of Python is not practical
> from a user
> (as opposed to a developer clique) perspective.
> As I have mentioned several times on this list, there is a middle way:
>
> 1) It is not using SWIG to generate the wrapper that creates the
> dependency. It is the way it is (not) used that creates the  dependency.
> The build process needs to be made easy enough that the  user can download
> the sources and use easy-install. Lots of complex  packages out there do
> this. However it requires a
>
> 2) Change in the oligarchical 'priesthood' approach to developer  status.
> (Notice how warmly Brian's recent offer to become involved in
> OSX-oriented development was met? NOT!  I hope he's not holding his
> breath!) This would mean that the whole idea of there not being a  version
> build available would more likely to disappear. jp's recent  Adminstrivia
> Message said:
>>  Newbies are
>> sometimes afraid to post because they read discussions about the
>> incomprehensible deep inner workings, and all they want to know is how
>> to get a sound to come out of their iBook.  Rest assured that your
>> question will be answered quickly, and (usually) in a helpful and
>> courteous manner.  We've all been there.  Please post.
>
>
> This could have come straight out of Hesse's The Glass Bead Game! Your
> questions may be answered but your suggestions frequently ignored.
> Afterall, the priests far to busy doing important things like  producing
> the next version release, to fix "newbie problems. Get back  in your box
> and genuflect,  genuflect,  genuflect!
>
> Michael recently said
>> I really don't understand the difficulty with the Windows installers.
>> I routinely test it at home and at work; and at work, i uninstall
>> Csound before installing it again. It always just runs out of the box.
>
> The difficulty is not a failure of the people trying to do the  install,
> it a development process failure. We all know how hard it is  to do the
> n'th correction of a text we've written, whereas fresh eyes  see the flaws
> easily. Ditto SW development.
>
> On 03/07/2009, at 4:26 AM, Dr. Richard Boulanger wrote:
>
>> I can't agree more.
>>
>> We desperately need a simple *installable* Windows version of  Csound5
>> with the QuteCsound front-end - as part of the package.
>>
>> I can't tell you how many Electronic Musicians, Synth Majors, Synth
>> professor, and very skilled and
>> Experienced Computer Music/Electronic Music colleagues - just give  UP!
>> When common sense fails,
>> when logic fails, when professional standards are not met... they  move
>> on - to the TONS of other
>> great and powerful tools at their disposal.
>>
>> At least there is NOW a Macintosh version that simple installs in a
>> clean and professional way, although
>> one has to find and know to install QuteCsound too... and even then,
>> there is confusion about which version
>> will work with which version and platform.
>
> It is somewhat consoling to here your  build difficulty anecdotes.
> Unfortunately the Mac version is not as up to the standard you think.
> As Victor said earlier in this thread
>> The Intel binaries I build are linked against MacPython 2.5. But it's
>> done in 10.4 (at the moment), so no guarantees for OSX 10.5.
>
> So around we go again. Problems mentioned, excuses (complexity, blah,
> blah) offered. Solution: People disappear (back) to a more user- oriented
> environment.
>
> And for the record... Csound may be fantastic, but it really is no  more
> complex that Supercollider. Bigger, yes, more weighed down by its  own
> history and self importance, yes, but not more complex.
>
> None of my posts on this are meant personally. I have considerable  regard
> for the work of many on this list. But the elephant (and rhino)  in the
> room need to be identified for what they are.
> In the meantime, when people as whether they should learn csound, I
> continue to say "not yet, not yet".
>
> D.
> ...
>> -dB
>>
>>
>> On Jul 2, 2009, at 1:37 PM, Jacob Joaquin wrote:
>>
>>>
>>>
>>> Felipe Sateler wrote:
>>>>
>>>> I still wonder why regular users need to bother with building  csound.
>>>> There is *no* need for that.
>>>> Just to make it clear: you do *not* need to build csound to use the
>>>> API. Unless the binary packages for OSX and Windows don't install  the
>>>> headers (which I'd be surprised to learn they don't).
>>>>
>>>
>>> Python does not work with the Csound API on my system. So I have to
>>> build it
>>> to use it.
>>>
>>>
>>> Felipe Sateler wrote:
>>>>
>>>> BTW, I do agree the csound build system is less than optimal, but it
>>>> is not easy to cater for all use cases. Anyways, it is not that hard
>>>> either: setup the appropriate environment (ie, install all needed
>>>> dependencies), setup your path and specific flags in custom.py and  run
>>>> scons with the wanted flags. If you have build errors, report them  so
>>>> that the minimum versions of dependencies are adjusted or the  problem
>>>> is fixed within csound.
>>>>
>>>
>>> Hard is a relative term.  Setting up the appropriate environment,
>>> dependencies, paths, flags, etc...  There  are lots of people who  have
>>> no
>>> clue how to interact with these technical hurdles, who are still very
>>> capable of writing Csound and python code.  Generally speaking, for
>>> every
>>> obstacle there is to get Csound up and running, we lose potential
>>> Csounders.
>>> Unfortunately, Csound has more obstacles than just about anything  else
>>> out
>>> in the wild.
>>>
>>> For all the time and hard work the developers and other put into  Csound
>>> (which I truly appreciate), much of it is wasted because of often
>>> unnecessary technical hurdles for newbies.  There are some  technical
>>> issues
>>> that may never be eliminated, I understand this, but there is  certainly
>>> much
>>> streamlining that can be done.  I'm willing to do my part.
>>>
>>> Plus, Csound isn't the only game in town, anymore;  It's hard  enough to
>>> get
>>> people to give Csound a try with other great music tools such as
>>> MaxMSP,
>>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to  grow
>>> the
>>> Csound community, we have knock off this technical elite attitude,  and
>>> start
>>> looking at Csound through the eyes of newbies.
>>>
>>> My two cents.
>>> Jake
>>>
>> ...
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body  "unsubscribe
>> csound"
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:   worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
>
>
>
>
> 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"

[csounder]

asking for this, begging for this - and loosing Csounders all over the  
world - for ages.

sad.  so... incredibly sad... particularly given the fact that for  
those of us who survive the installation and hang
in there - it's a pretty incredible tool -

uugh.......

-dB

On Jul 2, 2009, at 6:25 PM, Stéphane Rollandin wrote:

>> No environment variables; no installer; different versions of  
>> Csound can coexist without problems.
>
> We have been asking for this for ages...
>
> Stef
>
>
>
>
> 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"

[Dr. Richard Boulanger]

And it is interesting to note that Fran (welcome by the way - happy to  
have you on this adventure)
does not use a front-end really.

-dB


On Jul 2, 2009, at 7:10 PM, DavidW wrote:

> Fran,
> I am pleased that you don't have problems doing an install that  
> suits you. And that you enjoy using it.
> Thus, the difficulties we are discussing need not concern you.
>
> Bbuild difficulties and usage difficulties are different - I think  
> it is best not to confuse them.
>
> D
> On 03/07/2009, at 8:55 AM, francibal wrote:
>
>>
>> Dear all,
>> I'm a beginner, and i have no knowledge in programming, but i work  
>> with a pc
>> windows (xp-vista),
>> and i never had problems. I have installed many different versions,  
>> and both
>> float and double, and many times i have disinstalled and again, but  
>> always
>> it were all ok. And i'm not so able with a pc.
>> Csound is not so easy at begin, but with a little bit (and with a  
>> great help
>> from You), one can understand how to work. A new frontend would be  
>> really a
>> pleasure. I use scite(!), and i'm studying emacs
>> (thanks Mr Rollandin!), and for me it is sufficient. Maybe more  
>> experienced
>> users, like most of You, have some differents problems, I suppose.
>>
>> Only for report, from a lovers of csound,
>>
>> ciao, and thanks for all,
>>
>> fran.
>> --
>> View this message in context: http://www.nabble.com/Score-Alignment-Utility-tp24227460p24315191.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"
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:  worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
>
>
>
>
> 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"

[David Worrall]

On 03/07/2009, at 10:16 AM, michael.gogins@... wrote:

> I don't at all appreciate the tone in some of the posts to which I  
> am responding, and I would appreciate an apology.
>
If the cap fits, wear it. If not, it wasn't meant for you. No apology  
necessary. As I said, it isn't personal, so be careful imputing tone,  
especially in this forum format. Csound has this reputation, and  
denying it (especially from within the "inner circle") is not a valid  
reply to just criticism. I am not intentionally being uncivil, just  
direct. No need to take personal offence when none is implied.

> I do not view myself as a member of any sort of "priesthood," and  
> views that I do are contradicted by the extensive efforts that I  
> have made to enable other people easily to use Csound and CsoundAC.  
> I have contributed a build system that actually does build Csound on  
> all platforms, after other approaches failed to do so; I have  
> written a tutorial introduction to Csound that several have told me  
> is quite useful to beginners; and I have written two of the several  
> guides to building Csound, including the one in the Csound manual,  
> and a separate standalone guide to building on Windows.
>

If the mitre fits, wear it. If not, ignore it. I've always read and  
appreciated your contributions.
> I don't view any of the other committed Csound developers as a  
> "priesthood" either. But most of us are quite busy and Csound is one  
> part of what we do.
>
We differ wrt that, and we both speak from experience. Almost everyone  
is busy; that doesn't make the problem(s) disappear. If the "inner  
circle" is too busy, then expanding the "inner circle" is a more  
intelligent approach than appealing to their being overworked. What  
I'm saying is that csound dev. needs to sharpen its axes, not ignore  
the people who register that the trees are cut too roughly.

> Now, I would like to address some substantive points.
>
> I'm sorry, but it is indeed the use of SWIG that creates a  
> dependency on a specific version of Python, that is just how SWIG  
> works. I have looked through the SWIG documentation and mailing list  
> for pointers on this issue, and everybody just builds version-
> specific wrappers. In fact, this is the case with most Python  
> extension modules -- not just ones built with SWIG.
>
> If anyone happens to know how to get SWIG to make a non-version-
> specific wrapper, I will admit that I am wrong, I would be very glad  
> to hear about it, and I would definitely try to adopt it. Otherwise,  
> please do not repeat factual errors.
>

Let me assume you're not purposely misrepresenting my point....  I am  
not arguing for some unspecified version of "SWIG to make a non-
version-specific wrapper":
- A User with machine X with OS version Y and Python version Z and  
wants to build csound for it.
- The User installs the version of SWIG etc appropriate for their X, Y  
and Z.
- The User downloads the csound sources and runs the SConstruct.
- If it doesn't build/install etc appropriate to The User's machine,  
then it is a csound problem, unless it originates as a "specific  
version of SWIG problem." Even then, it is a csound problem because,  
given people-power, communication with SWIG dev. team etc, it it  
likely to be solvable.

Of course, if one User is trying to use one version of SWIG/python and  
one particular (set of) X, Y, and Z ,to generate generic wrappers for  
all X, Y and Z,  then there's likely to be a problem. But as I said,  
this is not what I'm suggesting, so I am not repeating factual errors.
Or perhaps I'm misunderstanding what you're saying. Are you saying  
that is is not possible to write a SConstruct file that can be made  
appropriately sensitive to the version of SWIG/python that is running  
it? If so, then long live MAKE. However, my experience with csound's  
SConstruct file is that problems were caused by it having certain  
things (such as the location of the python framework) "hard-wired".

> The use of a specific version of Python does not prevent users from  
> using Csound with or without Python. You can have several versions  
> of Python installed on the same computer and they will happily co-
> exist. You can use one version of Python to run one Python extension  
> module that is specific to that version, and you can use another  
> version of Python to run another Python extension module that is  
> specific to that version. You can do this by setting up different  
> "environments" for different versions of Python. You can do this in  
> a batch file that sets the appropriate PATH and other environment  
> variables for running Csound with its required version of python,  
> and another batch file for running other programs that need other  
> versions of Python.

I know about frameworks and different versions of python, as I've said  
before. And I've probably been using PATH variables longer than many  
on this list have been alive. But this doesn't solve the problem, as  
I've said before. If  A, B, C etc need to be done as part of a  
composition process and all the tools to do that except csound build  
to install for (one reasonable/the latest version of) python, how does  
having different versions available solve the problem? I do not accept  
the argument that it is good practice for the whole world to revolve  
around a particular version of python just because of csound. If the  
world marches to a particular step and csound is not instep, then it  
is csound, not the world. that is out-of-step.

> It also, of course, is possible to simply throw out annoying parts  
> of Csound, as Art Hunkins has so clearly explained.
>
As a user? Or are you suggesting the starting up a new project as a  
way of solving the current problem?
> In the meantime, be assured that I will make every reasonable effort  
> to make the installer, and Csound, easier to use. More information  
> about specific problems, including OS and Csound and Python  
> versions, and screen shots of error messages, would be most useful.
>
Thanks.
> I am considering creating two installers, one with a "cut-down"  
> release of Csound, and one with all bells and whistles including all  
> the language APIs. Then the installer with Python stuff wouldn't  
> have to try to figure out what is what on the installee's computer.
>
> I also will look into changing the build system to use Python  
> distutils to make the Python extension module, although I am not  
> sure that this will really be an improvement.
>
Lets discuss the options.
> Regards,
> Mike
in appreciation,

David

> ----- Original Message ----- From: "DavidW" <vip@...>
> To: <csound@...>
> Sent: Thursday, July 02, 2009 6:54 PM
> Subject: [Csnd] Re: Building Python API (was Re: : Score Alignment  
> Utility)
>
>
>> It is good to here that it is not just me banging on about these  
>> issue. It is simply not true - or a solution - to assume that  
>> build  difficulties mean "(dumb) newbie at work." In another  
>> current thread  (Sugar on a Stick - and OLPCsound) On 03/07/2009,  
>> at 7:01 AM, Michael  Gogins wrote:
>>
>>> As I have mentioned several times on this list, making the Csound  
>>> API
>>> independent of the Python version is not practical.
>>>
>>> We use SWIG to generate the Python wrapper, because it saves a  
>>> simply
>>> enormous amount of work to do so. Using SWIG also makes it easy to
>>> generate two of the other wrappers: the Lua API and the Java API  
>>> (the
>>> Lisp API is done with cffi, which is different).
>>>
>>> SWIG, however, makes the Python wrapper depend on the specific  
>>> version
>>> of Python.
>>
>>
>> As I and others have mentioned several times on this list, keeping  
>> the Csound API dependent on a specific version of Python is not  
>> practical from a user
>> (as opposed to a developer clique) perspective.
>> As I have mentioned several times on this list, there is a middle  
>> way:
>>
>> 1) It is not using SWIG to generate the wrapper that creates the  
>> dependency. It is the way it is (not) used that creates the  
>> dependency. The build process needs to be made easy enough that  
>> the  user can download the sources and use easy-install. Lots of  
>> complex  packages out there do this. However it requires a
>>
>> 2) Change in the oligarchical 'priesthood' approach to developer  
>> status. (Notice how warmly Brian's recent offer to become involved  
>> in OSX-oriented development was met? NOT!  I hope he's not holding  
>> his breath!) This would mean that the whole idea of there not being  
>> a  version build available would more likely to disappear. jp's  
>> recent  Adminstrivia Message said:
>>> Newbies are
>>> sometimes afraid to post because they read discussions about the
>>> incomprehensible deep inner workings, and all they want to know is  
>>> how
>>> to get a sound to come out of their iBook.  Rest assured that your
>>> question will be answered quickly, and (usually) in a helpful and
>>> courteous manner.  We've all been there.  Please post.
>>
>>
>> This could have come straight out of Hesse's The Glass Bead Game!  
>> Your questions may be answered but your suggestions frequently  
>> ignored. Afterall, the priests far to busy doing important things  
>> like  producing the next version release, to fix "newbie problems.  
>> Get back  in your box and genuflect,  genuflect,  genuflect!
>>
>> Michael recently said
>>> I really don't understand the difficulty with the Windows  
>>> installers.
>>> I routinely test it at home and at work; and at work, i uninstall
>>> Csound before installing it again. It always just runs out of the  
>>> box.
>>
>> The difficulty is not a failure of the people trying to do the  
>> install, it a development process failure. We all know how hard it  
>> is  to do the n'th correction of a text we've written, whereas  
>> fresh eyes  see the flaws easily. Ditto SW development.
>>
>> On 03/07/2009, at 4:26 AM, Dr. Richard Boulanger wrote:
>>
>>> I can't agree more.
>>>
>>> We desperately need a simple *installable* Windows version of  
>>> Csound5 with the QuteCsound front-end - as part of the package.
>>>
>>> I can't tell you how many Electronic Musicians, Synth Majors,  
>>> Synth professor, and very skilled and
>>> Experienced Computer Music/Electronic Music colleagues - just  
>>> give  UP! When common sense fails,
>>> when logic fails, when professional standards are not met... they  
>>> move on - to the TONS of other
>>> great and powerful tools at their disposal.
>>>
>>> At least there is NOW a Macintosh version that simple installs in  
>>> a clean and professional way, although
>>> one has to find and know to install QuteCsound too... and even  
>>> then, there is confusion about which version
>>> will work with which version and platform.
>>
>> It is somewhat consoling to here your  build difficulty anecdotes.  
>> Unfortunately the Mac version is not as up to the standard you think.
>> As Victor said earlier in this thread
>>> The Intel binaries I build are linked against MacPython 2.5. But  
>>> it's
>>> done in 10.4 (at the moment), so no guarantees for OSX 10.5.
>>
>> So around we go again. Problems mentioned, excuses (complexity,  
>> blah, blah) offered. Solution: People disappear (back) to a more  
>> user- oriented environment.
>>
>> And for the record... Csound may be fantastic, but it really is no  
>> more complex that Supercollider. Bigger, yes, more weighed down by  
>> its  own history and self importance, yes, but not more complex.
>>
>> None of my posts on this are meant personally. I have considerable  
>> regard for the work of many on this list. But the elephant (and  
>> rhino)  in the room need to be identified for what they are.
>> In the meantime, when people as whether they should learn csound, I  
>> continue to say "not yet, not yet".
>>
>> D.
>> ...
>>> -dB
>>>
>>>
>>> On Jul 2, 2009, at 1:37 PM, Jacob Joaquin wrote:
>>>
>>>>
>>>>
>>>> Felipe Sateler wrote:
>>>>>
>>>>> I still wonder why regular users need to bother with building  
>>>>> csound.
>>>>> There is *no* need for that.
>>>>> Just to make it clear: you do *not* need to build csound to use  
>>>>> the
>>>>> API. Unless the binary packages for OSX and Windows don't  
>>>>> install  the
>>>>> headers (which I'd be surprised to learn they don't).
>>>>>
>>>>
>>>> Python does not work with the Csound API on my system. So I have  
>>>> to build it
>>>> to use it.
>>>>
>>>>
>>>> Felipe Sateler wrote:
>>>>>
>>>>> BTW, I do agree the csound build system is less than optimal,  
>>>>> but it
>>>>> is not easy to cater for all use cases. Anyways, it is not that  
>>>>> hard
>>>>> either: setup the appropriate environment (ie, install all needed
>>>>> dependencies), setup your path and specific flags in custom.py  
>>>>> and  run
>>>>> scons with the wanted flags. If you have build errors, report  
>>>>> them  so
>>>>> that the minimum versions of dependencies are adjusted or the  
>>>>> problem
>>>>> is fixed within csound.
>>>>>
>>>>
>>>> Hard is a relative term.  Setting up the appropriate environment,
>>>> dependencies, paths, flags, etc...  There  are lots of people  
>>>> who  have no
>>>> clue how to interact with these technical hurdles, who are still  
>>>> very
>>>> capable of writing Csound and python code.  Generally speaking,  
>>>> for every
>>>> obstacle there is to get Csound up and running, we lose potential  
>>>> Csounders.
>>>> Unfortunately, Csound has more obstacles than just about  
>>>> anything  else out
>>>> in the wild.
>>>>
>>>> For all the time and hard work the developers and other put into  
>>>> Csound
>>>> (which I truly appreciate), much of it is wasted because of often
>>>> unnecessary technical hurdles for newbies.  There are some  
>>>> technical issues
>>>> that may never be eliminated, I understand this, but there is  
>>>> certainly much
>>>> streamlining that can be done.  I'm willing to do my part.
>>>>
>>>> Plus, Csound isn't the only game in town, anymore;  It's hard  
>>>> enough to get
>>>> people to give Csound a try with other great music tools such as  
>>>> MaxMSP,
>>>> Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want  
>>>> to  grow the
>>>> Csound community, we have knock off this technical elite  
>>>> attitude,  and start
>>>> looking at Csound through the eyes of newbies.
>>>>
>>>> My two cents.
>>>> Jake
>>>>
>>> ...
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@... with body  
>>> "unsubscribe csound"
>>

________________________________________________
David Worrall.
- Experimental Polymedia:  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au







Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Michael Gogins-2]

> Let me assume you're not purposely misrepresenting my point....  I am  not
> arguing for some unspecified version of "SWIG to make a non-
> version-specific wrapper":
> - A User with machine X with OS version Y and Python version Z and  wants
> to build csound for it.
> - The User installs the version of SWIG etc appropriate for their X, Y
> and Z.
> - The User downloads the csound sources and runs the SConstruct.
> - If it doesn't build/install etc appropriate to The User's machine,  then
> it is a csound problem, unless it originates as a "specific  version of
> SWIG problem." Even then, it is a csound problem because,  given
> people-power, communication with SWIG dev. team etc, it it  likely to be
> solvable.

It is not appropriate for SCons
to try to deduce the version of Python to use, precisely because users may
have
more than one version of Python installed on their computer. There is a
Python version argument for SCons,
and you can set specific PATH variables in your environment and other
paths in your custom.py to match that version.

> I know about frameworks and different versions of python, as I've said
> before. And I've probably been using PATH variables longer than many  on
> this list have been alive. But this doesn't solve the problem, as  I've
> said before. If  A, B, C etc need to be done as part of a  composition
> process and all the tools to do that except csound build  to install for
> (one reasonable/the latest version of) python, how does  having different
> versions available solve the problem? I do not accept  the argument that
> it is good practice for the whole world to revolve  around a particular
> version of python just because of csound. If the  world marches to a
> particular step and csound is not instep, then it  is csound, not the
> world. that is out-of-step.
>
>> It also, of course, is possible to simply throw out annoying parts  of
>> Csound, as Art Hunkins has so clearly explained.
>>
> As a user?

That's what Art Hunkins did, isn't it?

>> In the meantime, be assured that I will make every reasonable effort  to
>> make the installer, and Csound, easier to use. More information  about
>> specific problems, including OS and Csound and Python  versions, and
>> screen shots of error messages, would be most useful.
>>
> Thanks.

You're welcome.

>> I am considering creating two installers, one with a "cut-down"  release
>> of Csound, and one with all bells and whistles including all  the
>> language APIs. Then the installer with Python stuff wouldn't  have to try
>> to figure out what is what on the installee's computer.
>>
>> I also will look into changing the build system to use Python  distutils
>> to make the Python extension module, although I am not  sure that this
>> will really be an improvement.
>>
> Lets discuss the options.

Are you more concerned about building Csound, or about installing it?

Regards,
Mike



Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Panos Katergiathis-3]

Friends, i would like to re-suggest that Csound (for PC, Mac, Linux...
whatever) should be built and packaged as a portable, no-installer-used
application. Anything else is (and will be) causing problems, forever.

I first suggested this approach, two or three years ago, on a thread i
opened right here, mostly influenced by the fact that Blue is being
distributed this way and also by the very positive effect that this site
(http://www.portableapps.com) had on my PC life. I thought "wow, that's
exactly what Csound, should be: a "portableapp" as well".

Panos




Dr. Richard Boulanger wrote:

> And it is interesting to note that Fran (welcome by the way - happy to
> have you on this adventure)
> does not use a front-end really.
>
> -dB
>
>
> On Jul 2, 2009, at 7:10 PM, DavidW wrote:
>
>> Fran,
>> I am pleased that you don't have problems doing an install that suits
>> you. And that you enjoy using it.
>> Thus, the difficulties we are discussing need not concern you.
>>
>> Bbuild difficulties and usage difficulties are different - I think it
>> is best not to confuse them.
>>
>> D
>> On 03/07/2009, at 8:55 AM, francibal wrote:
>>
>>>
>>> Dear all,
>>> I'm a beginner, and i have no knowledge in programming, but i work
>>> with a pc
>>> windows (xp-vista),
>>> and i never had problems. I have installed many different versions,
>>> and both
>>> float and double, and many times i have disinstalled and again, but
>>> always
>>> it were all ok. And i'm not so able with a pc.
>>> Csound is not so easy at begin, but with a little bit (and with a
>>> great help
>>> from You), one can understand how to work. A new frontend would be
>>> really a
>>> pleasure. I use scite(!), and i'm studying emacs
>>> (thanks Mr Rollandin!), and for me it is sufficient. Maybe more
>>> experienced
>>> users, like most of You, have some differents problems, I suppose.
>>>
>>> Only for report, from a lovers of csound,
>>>
>>> ciao, and thanks for all,
>>>
>>> fran.
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Score-Alignment-Utility-tp24227460p24315191.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"
>>
>> ________________________________________________
>> David Worrall.
>> - Experimental Polymedia:      worrall.avatar.com.au
>> - Sonification: www.sonifiction.com.au
>> - Education for Financial Independence: www.mindthemarkets.com.au
>>
>>
>>
>>
>>
>>
>>
>> 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"
>

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Andy Fillebrown]

2009/7/2 Stéphane Rollandin <lecteur@...>:

>
> What I do believe is that a whole other project is needed to wrap Csound
> within a full-blown composition system. But for this to happen we need a
> group of motivated people, sharing a common vision of what such a system
> should be. This is very challenging.
>
> Personnaly I have my own one-person thing, Surmulot, developed along the
> lines I just exposed: it is very easy to install (just unzip the archive),
> it has graphical front-ends for score, orchestra and envelopes, a powerful
> textual front-end (Emacs), algorithmic tools, high level languages for
> composing (Lisp and Smalltalk). But it definitely is not friendly to
> newbies. Could be made so, maybe, sometime...
>

As part of the AudioCarver project, I've been developing two base libraries to wrap Csound the "Qt way".

The first project, MiQtCsound, is a thin C++ wrapper for Csound's C api. It main feature is that it uses Qt's library loading class in such a way that (in theory) allows it to wrap any version of the api that uses the same function names, based solely on the library name passed into a constructor at runtime with no link-time dependencies to Csound.

The second MiQtCsound project is contained in the larger MiQt project and is aimed at providing a trimmed down, logical, and Qt-like interface to Csound's api via the first project's library.  I have only recently worked out a rudimentary playback system in it, and it is probably not very useful to anyone other than myself at the moment -- but I'm hopeful AudioCarver will become a full blown sequencer based on it in the near future.

At this point the projects are only setup to build on Windows but I'm having success building small parts of it on Ubuntu as well -- and it should not be difficult to get it up and running on Mac platforms in due time, either, assuming I'm able to afford it.

---

Being self-taught I consider myself only an amatuer programmer, but I have 10 years of fairly complex (albeit non-professional) C++ design under my belt -- and I've taken great care in learning Qt's design methodologies and naming schemes with the idea being from the start that others will find it useful, too.  This is a critical time in all three projects' development, though.  In the last two weeks I've gotten to the bottom of most of my "how" and "why" questions regarding the csound api and I'll soon be entering the over-arching design phase now that the intitial research phase is nearing completion.  I think it might be really cool if some of the devs here could take a look at code for these projects and see if they could possibly fit the bill for something along the lines of what Stephane is talking about -- and this is the perfect time to be considering large-scale changes in their design should it be deemed necessary.

I'd post links to the projects (MiQtCsound, MiQt, and AudioCarver) but SourceForge has locked me out of them while it updates it's new look/feel.  In the meantime they should be easy enough to locate via SourceForge's search function, and hopefully they'll be up again soon.

Regards,
-andy.f



----- "Stéphane Rollandin" <lecteur@...> wrote:

> > Plus, Csound isn't the only game in town, anymore;  It's hard enough
> to get
> > people to give Csound a try with other great music tools such as
> MaxMSP,
> > Supercollider, ChucK, Reaktor, Ableton Live, etc...  If we want to
> grow the
> > Csound community, we have knock off this technical elite attitude,
> and start
> > looking at Csound through the eyes of newbies.  
>
> Csound is very different from the others you list. It is more
> low-level,
> and more powerful IMO. What we would need is a friendly layer above it
>
> exposing its power in a clean and simple way to newbies, or simply
> composers that are not fond of assembly programming. To me it would be
>
> another system altogether. Some attempts have been made, from Blue to
>
> Cecilia or older stuff like PatchWork and many others. These are/were
>
> all individual projects so they have limited scope and lack the
> manpower
> required to build a Reaktor clone.
>
> So, to summarize, the technical elite attitude you regret mirrors the
>
> actual technical nature of Csound itself. I don't think it can be very
>
> much more newbie friendly.
>
> What I do believe is that a whole other project is needed to wrap
> Csound
> within a full-blown composition system. But for this to happen we need
> a
> group of motivated people, sharing a common vision of what such a
> system
> should be. This is very challenging.
>
> Personnaly I have my own one-person thing, Surmulot, developed along
> the
> lines I just exposed: it is very easy to install (just unzip the
> archive), it has graphical front-ends for score, orchestra and
> envelopes, a powerful textual front-end (Emacs), algorithmic tools,
> high
> level languages for composing (Lisp and Smalltalk). But it definitely
> is
> not friendly to newbies. Could be made so, maybe, sometime...
>
>
>
> Stef
>
>
>
> 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"

[Mark Van Peteghem-2]

I don't feel too comfortable about PortableApps. It is recommended to
install applications with administrator rights in a folder that is
write-protected, and use them from then on with a user account that
can't write in that directory. This prevents viruses and other malware
from changing the executables. PortableApps throws this security
mechanism out of the window. So I prefer that CSound doesn't become
portable app.

Blue is not a portable app (at least not in that sense), because it puts
data that can be modified by the user (like the instrument library) in
the home directory of the user, while the executable is in the
applications folder. And I always install Blue using its installer
(don't know if it is possible without). But it is a lot easier to
install than CSound (although installing CSound was easy - at least in
my case).


Mark


Panos Katergiathis wrote:
> I first suggested this approach, two or three years ago, on a thread i
> opened right here, mostly influenced by the fact that Blue is being
> distributed this way and also by the very positive effect that this
> site (http://www.portableapps.com) had on my PC life. I thought "wow,
> that's exactly what Csound, should be: a "portableapp" as well".



Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[john ffitch]

>>>>> "=?ISO-8859-1?Q?St=E9phane" == =?ISO-8859-1?Q?St=E9phane Rollandin?= <lecteur@...> writes:

 >> No environment variables; no installer; different versions of Csound can
 >> coexist without problems.

 =?ISO-8859-1?Q?St=E9phane> We have been asking for this for ages...

 =?ISO-8859-1?Q?St=E9phane> Stef



So have I (re environment variables) .....

==John ffitch


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[joachim heintz]

I'd like to discuss this more in detail. I'd appreciate if we could  
define some subjects/ projects: what must be done to improve the user-
friendlyness of Csound, and how can it be done? If there is a  
consensus about some points, we could perhaps have some groups of  
people who are willing to contribute to a certain issue.

To begin with my own opinion: I'd like to have something like a  
practical guide (and contribute to it) to the different approaches of  
Csound. There should be good examples with rather short explanations  
to the different chapters of Csound, including
- general configuration
- working with live input
- working with MIDI
- loop constructions and event management
- classical sound synthesis
- granular synthesis
- spectral processing
- working with the API
- using Csound and the utilities with Shell Scripts
- and and and ...

The goal of this practical guide would be:
1) to collect the most important informations about the different ways  
of using Csound (for example, "what you should know about commandline  
flags", "what you should know when you work with MIDI input")
2) to give hints about which opcodes can be used for the different  
approaches, uncluding some kind of selection (for example, the pvs  
opcodes are actually replacing some older opcodes, or poscil can be  
used instead of oscil also for non-power-of-two function tables)
3) to show a rich collection of good examples: good in programming,  
with interesting musical results.

What others think about this? And are there other items, perhaps more  
necessary?

        joachim


Am 29.06.2009 um 00:51 schrieb Jacob Joaquin:

>
> Csound is not user-friendly.  If developers and others in the  
> community spent
> a full year working towards improving the user-experience, while  
> putting on
> hold everything else Csound related, this would be time well spent.  
> People
> are easily turned off the number of hoops they have to jump through -
> whether its issues with Python, or just rendering a file.  Csound is
> supposed to be an instrument of musical expression, not a technical  
> hurdle.
>
> In my humble opinion.  :)
>

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Michael Gogins-2]

OK, no environment variables. Then Csound must search specific paths
for plugin opcodes, samples, and so on.

I would prefer this myself.

Regards,
Mike

On 7/4/09, jpff <jpff@...> wrote:

>>>>>> "=?ISO-8859-1?Q?St=E9phane" == =?ISO-8859-1?Q?St=E9phane Rollandin?=
>>>>>> <lecteur@...> writes:
>
>  >> No environment variables; no installer; different versions of Csound can
>  >> coexist without problems.
>
>  =?ISO-8859-1?Q?St=E9phane> We have been asking for this for ages...
>
>  =?ISO-8859-1?Q?St=E9phane> Stef
>
>
>
> So have I (re environment variables) .....
>
> ==John ffitch
>
>
> 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"

[Michael Gogins-2]

Much of this information already exists in "A Csound Tutorial" by me.
I would be happy for other people to edit this or add to it. It is in
the tutorial module of Csound CVS.

Regards,
Mike


On 7/4/09, joachim heintz <jh@...> wrote:

> I'd like to discuss this more in detail. I'd appreciate if we could
> define some subjects/ projects: what must be done to improve the user-
> friendlyness of Csound, and how can it be done? If there is a
> consensus about some points, we could perhaps have some groups of
> people who are willing to contribute to a certain issue.
>
> To begin with my own opinion: I'd like to have something like a
> practical guide (and contribute to it) to the different approaches of
> Csound. There should be good examples with rather short explanations
> to the different chapters of Csound, including
> - general configuration
> - working with live input
> - working with MIDI
> - loop constructions and event management
> - classical sound synthesis
> - granular synthesis
> - spectral processing
> - working with the API
> - using Csound and the utilities with Shell Scripts
> - and and and ...
>
> The goal of this practical guide would be:
> 1) to collect the most important informations about the different ways
> of using Csound (for example, "what you should know about commandline
> flags", "what you should know when you work with MIDI input")
> 2) to give hints about which opcodes can be used for the different
> approaches, uncluding some kind of selection (for example, the pvs
> opcodes are actually replacing some older opcodes, or poscil can be
> used instead of oscil also for non-power-of-two function tables)
> 3) to show a rich collection of good examples: good in programming,
> with interesting musical results.
>
> What others think about this? And are there other items, perhaps more
> necessary?
>
> joachim
>
>
> Am 29.06.2009 um 00:51 schrieb Jacob Joaquin:
>
>>
>> Csound is not user-friendly.  If developers and others in the
>> community spent
>> a full year working towards improving the user-experience, while
>> putting on
>> hold everything else Csound related, this would be time well spent.
>> People
>> are easily turned off the number of hoops they have to jump through -
>> whether its issues with Python, or just rendering a file.  Csound is
>> supposed to be an instrument of musical expression, not a technical
>> hurdle.
>>
>> In my humble opinion.  :)
>>
>
>
>
> 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"

[Jacob Joaquin]

Here are somethings I think we should consider, but not necessarily implement.

-Messages should be written to <stdout> instead of <stderr>.

-0dbfs should be set to 1.0 by default.  Hard coding to a range of +/- 32768 should be considered bad practice.

-Every new feature that is intended to go into Csound should be spec'd out, and with extensive community input.  Since backwards compatibility is a staple of Csound culture, I think it would be wise to start doing this immediately.

-Debate the merits breaking backwards compatibility in Csound6.  What would lose?  What could we gain? Could a script be written to convert from the old to new? Or perhaps a guide showing how to update older pieces?

-Csound Core might be a priorty, with a focus on getting it up and running fast and easy.

-Defragment the Csound knowledge base.  There is a lot of scattered information out.  On top of this, much of it is deprecated, which can be very confusing for beginners and power users.

-Community should find ways of putting more emphasis on music and art.  We often live in our own little worlds and only come together when it comes to technical related issues.

-Look at everything and ask ourselves, "Can this be done better?"  For example, $ csound outputs a list of flags and extras 55 lines long.  Would this be better if reduced the list of flags to only the most common flags?  And then emphasize --help.

-Bring the sexy back.  Superficially speaking, we live in a world where people find Wine tastes better if it comes out of an expensive looking bottle.  Csound looks like it's being consumed from a straw sticking out of a paper bag, despite being an excellent vintage.

-User test everything, just to be sure. Just because someone may seem like a no brainer to one person, doesn't mean it isn't really confusing to everyone else. I've seen many examples in various online tech communities where some explains something, and leaves out important details because he or she assumes that everyone knows what the know.

Off the top of my head.

Best,
Jake

joachim heintz wrote:

I'd like to discuss this more in detail. I'd appreciate if we could  
define some subjects/ projects: what must be done to improve the user-
friendlyness of Csound, and how can it be done? If there is a  
consensus about some points, we could perhaps have some groups of  
people who are willing to contribute to a certain issue.

To begin with my own opinion: I'd like to have something like a  
practical guide (and contribute to it) to the different approaches of  
Csound. There should be good examples with rather short explanations  
to the different chapters of Csound, including
- general configuration
- working with live input
- working with MIDI
- loop constructions and event management
- classical sound synthesis
- granular synthesis
- spectral processing
- working with the API
- using Csound and the utilities with Shell Scripts
- and and and ...

The goal of this practical guide would be:
1) to collect the most important informations about the different ways  
of using Csound (for example, "what you should know about commandline  
flags", "what you should know when you work with MIDI input")
2) to give hints about which opcodes can be used for the different  
approaches, uncluding some kind of selection (for example, the pvs  
opcodes are actually replacing some older opcodes, or poscil can be  
used instead of oscil also for non-power-of-two function tables)
3) to show a rich collection of good examples: good in programming,  
with interesting musical results.

What others think about this? And are there other items, perhaps more  
necessary?

        joachim


Am 29.06.2009 um 00:51 schrieb Jacob Joaquin:

>
> Csound is not user-friendly.  If developers and others in the  
> community spent
> a full year working towards improving the user-experience, while  
> putting on
> hold everything else Csound related, this would be time well spent.  
> People
> are easily turned off the number of hoops they have to jump through -
> whether its issues with Python, or just rendering a file.  Csound is
> supposed to be an instrument of musical expression, not a technical  
> hurdle.
>
> In my humble opinion.  :)
>



Send bugs reports to this list.
To unsubscribe, send email [e-mail] with body "unsubscribe csound"

[Felipe Sateler]

Doesn't csound have a default path for all of the env variables? For
opcodes in linux there is...

On 04/07/2009, Michael Gogins <michael.gogins@...> wrote:

> OK, no environment variables. Then Csound must search specific paths
> for plugin opcodes, samples, and so on.
>
> I would prefer this myself.
>
> Regards,
> Mike
>
> On 7/4/09, jpff <jpff@...> wrote:
> >>>>>> "=?ISO-8859-1?Q?St=E9phane" == =?ISO-8859-1?Q?St=E9phane Rollandin?=
> >>>>>> <lecteur@...> writes:
> >
> >  >> No environment variables; no installer; different versions of Csound can
> >  >> coexist without problems.
> >
> >  =?ISO-8859-1?Q?St=E9phane> We have been asking for this for ages...
> >
> >  =?ISO-8859-1?Q?St=E9phane> Stef
> >
> >
> >
> > So have I (re environment variables) .....
> >
> > ==John ffitch
> >
> >
> > 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"
>

--

Saludos,
Felipe Sateler


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Mike Moser-Booth]

I definitely agree that a sort of practical guide would go a long way to help new users of Csound. I think it might be worth taking a look at what other music programming environments have done in this area. Max/MSP and Pd immediately come to mind here. They both come with fairly extensive tutorials that start with the most basic "Hello World" patches and work their way up to more complicated techniques in a logical progression. Not only are the techniques practical themselves, but they are made more so by the fact information from preceding tutorials are applicable to later tutorials, thus making concepts that may initially seem out of reach more accessible. I know that seems elementary, but it seems to be lacking quite a bit in Csound world. So many tutorials are scattered in different sources and often assume a prior knowledge that one must search elsewhere to find. Dr. B's TOOTS are the only thing that immediately comes to mind that even comes close to fulfilling this paradigm, as they address the absolute beginner and build up from there.

I would be very willing to contribute to a project like this. Just a couple of things I would add to your list, Joachim, off the top of my head:
-using Csound in conjunction with sequencers/DAWs
-a general "Using the Command Line" tutorial, as most people these days simply don't use it and don't have a clue

.mmb

joachim heintz wrote:

I'd like to discuss this more in detail. I'd appreciate if we could define some subjects/ projects: what must be done to improve the user-friendlyness of Csound, and how can it be done? If there is a consensus about some points, we could perhaps have some groups of people who are willing to contribute to a certain issue.

To begin with my own opinion: I'd like to have something like a practical guide (and contribute to it) to the different approaches of Csound. There should be good examples with rather short explanations to the different chapters of Csound, including
- general configuration
- working with live input
- working with MIDI
- loop constructions and event management
- classical sound synthesis
- granular synthesis
- spectral processing
- working with the API
- using Csound and the utilities with Shell Scripts
- and and and ...

The goal of this practical guide would be:
1) to collect the most important informations about the different ways of using Csound (for example, "what you should know about commandline flags", "what you should know when you work with MIDI input")
2) to give hints about which opcodes can be used for the different approaches, uncluding some kind of selection (for example, the pvs opcodes are actually replacing some older opcodes, or poscil can be used instead of oscil also for non-power-of-two function tables)
3) to show a rich collection of good examples: good in programming, with interesting musical results.

What others think about this? And are there other items, perhaps more necessary?

    joachim


Am 29.06.2009 um 00:51 schrieb Jacob Joaquin:

Csound is not user-friendly.  If developers and others in the community spent
a full year working towards improving the user-experience, while putting on
hold everything else Csound related, this would be time well spent.  People
are easily turned off the number of hoops they have to jump through -
whether its issues with Python, or just rendering a file.  Csound is
supposed to be an instrument of musical expression, not a technical hurdle.

In my humble opinion.  :)

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jason Adams]

First off let me say that i'm new to this world (lovin' it, but still new), but i think the biggest thing that is/was standing in the way for myself to really dig in was the translation.  It was figuring out what the heck a "modified hyperbolic tangent distortion" is in laymans terms... (which is somewhat like a morphable distortion from soft clipping to hard clipping, in musical terms)  although the manual is amazing in that distort1 is exactly what it says, a "modified hyperbolic tangent distortion".  i laughed at a few of the definitions right off the bat, even thought they are spot on, i had to translate the technical, exact definition into musical language that i understand. 

i think mike has some good suggestions... practical, building block toots, for those who can't afford/have-access-to the Csound book.  -using Csound with sequencers/DAWs, that would be amazing... i'm currently trying to figure how to pipe audio from max into Csound to do live granular/chopping/mayhem/resonating-Lanksy-style electric bass performance stuff and it's been a realy pain (i had little idea of where to start). 

this said, as a newb... i can't believe not only how active the community is (my inbox is constantly full) but also how interested you cats are in bring Csound to the masses while at the same time figuring out uber-geeky ways of making this program better (perhaps why i have come to really like this community... ah, the comfort in discovering like-minded individuals).

best of luck in this... there is any way i could be of service my email is available... heck, here it is... jadams1@...

ciao
jAdams

---------------------------------------
Original E-mail
From: Mike Moser-Booth <mmoserbooth@...>
Date: 07/05/2009 12:23 AM
To: csound@...
Subject: [Csnd] Re: How to make Csound more user-friendly

 

I definitely agree that a sort of practical guide would go a long way to help new users of Csound. I think it might be worth taking a look at what other music programming environments have done in this area. Max/MSP and Pd immediately come to mind here. They both come with fairly extensive tutorials that start with the most basic "Hello World" patches and work their way up to more complicated techniques in a logical progression. Not only are the techniques practical themselves, but they are made more so by the fact information from preceding tutorials are applicable to later tutorials, thus making concepts that may initially seem out of reach more accessible. I know that seems elementary, but it seems to be lacking quite a bit in Csound world. So many tutorials are scattered in different sources and often assume a prior knowledge that one must search elsewhere to find. Dr. B's TOOTS are the only thing that immediately comes to mind that even comes close to fulfilling this paradigm, as they address the absolute beginner and build up from there.

I would be very willing to contribute to a project like this. Just a couple of things I would add to your list, Joachim, off the top of my head:
-using Csound in conjunction with sequencers/DAWs
-a general "Using the Command Line" tutorial, as most people these days simply don't use it and don't have a clue

.mmb

joachim heintz wrote:

I'd like to discuss this more in detail. I'd appreciate if we could define some subjects/ projects: what must be done to improve the user-friendlyness of Csound, and how can it be done? If there is a consensus about some points, we could perhaps have some groups of people who are willing to contribute to a certain issue.  
 
To begin with my own opinion: I'd like to have something like a practical guide (and contribute to it) to the different approaches of Csound. There should be good examples with rather short explanations to the different chapters of Csound, including  
- general configuration  
- working with live input  
- working with MIDI  
- loop constructions and event management  
- classical sound synthesis  
- granular synthesis  
- spectral processing  
- working with the API  
- using Csound and the utilities with Shell Scripts  
- and and and ...  
 
The goal of this practical guide would be:  
1) to collect the most important informations about the different ways of using Csound (for example, "what you should know about commandline flags", "what you should know when you work with MIDI input")  
2) to give hints about which opcodes can be used for the different approaches, uncluding some kind of selection (for example, the pvs opcodes are actually replacing some older opcodes, or poscil can be used instead of oscil also for non-power-of-two function tables)  
3) to show a rich collection of good examples: good in programming, with interesting musical results.  
 
What others think about this? And are there other items, perhaps more necessary?  
 
    joachim  
 
 
Am 29.06.2009 um 00:51 schrieb Jacob Joaquin:  
 
 

Csound is not user-friendly.  If developers and others in the community spent    
a full year working towards improving the user-experience, while putting on    
hold everything else Csound related, this would be time well spent.  People    
are easily turned off the number of hoops they have to jump through -    
whether its issues with Python, or just rendering a file.  Csound is    
supposed to be an instrument of musical expression, not a technical hurdle.    
   
In my humble opinion.  :)    
   
 

 
 
 
Send bugs reports to this list.  
To unsubscribe, send email sympa@... with body "unsubscribe csound"