Thanks for you feedback. My comments follow.

>> "A Csound Tutorial" by me on Csounds.com has an introduction to Python 
>> scripting for Csound.
>
>Yes, I've downloaded that and skimmed it. It has some very good information,
>but as with other tutorials, it seems to make certain invisible assumptions
>(and I'm not even sure what they are).

I would sure like to know -- I would fix them.

>
>A little while ago I loaded Koch.py into SciTE. When I issue the Run command
>from SciTE, the output window says this:
>
>>pythonw -u "Koch.py"
>>The system cannot find the file specified.

Not what happens with me...

>
>Now, my best guess is that I need to set a path somewhere. But where? In
>Csound, in SciTE, or in Python? And how would I do it? When I look in the
>big fat Python tutorial, it provides no concrete information about exactly
>how one would set paths. It mumbles a bit about what you would need to do in
>Unix, but those paragraphs are obviously written for Unix professionals, not
>for Windows amateurs like me. So I can't run Koch.py.
>
>This is the kind of logjam I'm talking about.

Might be more foolproof to run "set PYTHONPATH=c:\csound\bin;python examples\koch.py" from c:\csound, assuming that's where you have installed Csound.

>
>> The advantage of Python is in using Python scripts as a concise form of 
>> music notation. You use Python to generate the score, and feed notes to 
>> Csound. There is a further advantage in that Python enables the use of 
>> fractals, mathematical music theory, and so forth to generate scores, or 
>> transform scores, in ways that are not necessarily easy to imagine.
>
>Ah, but my job as a journalist is _precisely_ to make them easy to imagine!
>That's why I'm hoping for some specific information on this point.

This is hard to convey without some experience. I repeat, the whole point of using the computer to compose is to come up with stuff that you think might be cool, but that you CAN'T imagine in detail. If you could imagine it in detail, you could just play it in or write it out, and the computer would just be getting in the way. This is related to "process music" and ideas going back to Cage and Stockhausen. A simple example could illustrate this, I think: a Lindenmayer system or chaotic dynamical system in a short Python script, where you make very simple changes to the script and get back big changes in the music. It's a kind of "active shorthand" for musical ideas.

>
>> AthenaCL, by Christopher Ariza, is a whole toolkit of operations and
>> classes 
>> for doing score generation and score manipulation. CsoundAC, by me, which
>> is 
>> part of Csound, is another such toolkit.
>
>Yes, I've looked briefly at the documentation on both of those. Sad to say,
>I can't make heads nor tails of either of them.

Yes, I'm quite aware that the CsoundAC system has no entry point at this time. Writing a tutorial for the system is on my agenda. The existing documentation is purely a reference manual that I use myself to remind myself of details that I have forgotten since I wrote the system.

For what it's worth, I've composed 4 finished CDs and dozens if not hundreds of hours of candidate music using the system. You can find 2 of my CDs on iTunes and some other pieces (and other writings) at my page on www.ruccas.org.

>
>I plan to keep plugging away at it, and eventually the clouds should start
>to clear away. I'm already a halfway decent hobbyist programmer, so there's
>hope. But I can't help wishing I could find some resources that provided
>more in the way of introductory information for people who have never taken
>a university-level course in computer science.
>
>--JA
>
>
>
>-- 
>View this message in context: http://www.nabble.com/Newbie-%28sort-of%29-Questions-tp17593144p17593998.html
>Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Michael Gogins wrote:
> 
> Might be more foolproof to run "set PYTHONPATH=c:\csound\bin;python
> examples\koch.py" from c:\csound, assuming that's where you have installed
> Csound.
> 

c:\csound is a directory. I would have no idea how to run a double-quoted
string from a directory.

Oh, you mean after opening the Command Prompt window (which is what it's
called in Windows, BTW) and navigating to that directory! Now I get it. 

This is probably as good an example as any of the kind of invisible
assumption I mentioned earlier. I would imagine Linux users normally, or
quite often, think in terms of being in a console, or shell, or whatever the
heck it's called. For Windows and Mac users, a directory is a window on the
screen. That's all it is. You can't run anything from a window on the
screen.


Michael Gogins wrote:
> 
>>Ah, but my job as a journalist is _precisely_ to make them easy to
imagine!
>>That's why I'm hoping for some specific information on this point.
> 
> This is hard to convey without some experience. I repeat, the whole point
> of using the computer to compose is to come up with stuff that you think
> might be cool, but that you CAN'T imagine in detail. If you could imagine
> it in detail, you could just play it in or write it out, and the computer
> would just be getting in the way. This is related to "process music" and
> ideas going back to Cage and Stockhausen. A simple example could
> illustrate this, I think: a Lindenmayer system or chaotic dynamical system
> in a short Python script, where you make very simple changes to the script
> and get back big changes in the music. It's a kind of "active shorthand"
> for musical ideas.
> 

Well, I didn't mean imagining it in detail. I understand that the algorithm
is being asked to fill in the details. I'm interested in painting a picture
in words of what it _sounds_ like after you do that.

A simple example would be great. That's what I was hoping to get by running
Koch.py. There absolutely won't be room in the article I'm writing to give a
code example -- and in any case, nobody who read it would understand it.
What I need to do is paint a word picture. Among the words I won't be able
to use are "Lindenmayer system or chaotic dynamical system." Those words
mean nothing whatever to me, let alone to my readership. (I do know what
chaos is, but only barely.)


Michael Gogins wrote:
> 
> For what it's worth, I've composed 4 finished CDs and dozens if not
> hundreds of hours of candidate music using the system. You can find 2 of
> my CDs on iTunes and some other pieces (and other writings) at my page on
> www.ruccas.org.
> 

Excellent. I'll check it out. This is exactly the sort of "picture is worth
a thousand words" information I need -- audio that folks can listen to,
together with a sentence hinting how it was produced.

--JA

-- 
View this message in context: http://www.nabble.com/Newbie-%28sort-of%29-Questions-tp17593144p17605013.html
Sent from the Csound - General mailing list archive at Nabble.com.

David Akbari wrote:
> 
> I think Mike indirectly addresses a great point that may be of
> interest for new users getting started with Csound. This is mainly the
> concept of the Environment Variables that has emerged in version 5 of
> the language which is quite crucial to running Csound with all of its
> optional plugin libraries and is a common concept used throughout Unix
> shell scripting environments, the Mac OSX Aqua interface, and Windows
> XP.
> 
> Maybe just write in your article that they can see what their
> environment variables are by pressing
> 
> Windows Logo + Pause/Break > Advanced Tab > Environment Variables
> 
> A short section describing the etymology and purpose of this concept
> will likely bridge the gap between those who rely on the GUI interface
> and those who are using whatever console/command interpreter/CLI on
> whatever OS. It seems like one of those very important concepts from
> computer science courses but also accessible to the casual user.
> 

Unfortunately, that would be a whole other article. It would take two pages
in the magazine, and I don't have two pages.

Thanks for explaining where the Environment Variables are. I didn't know the
keystroke shortcut, and I had never noticed that button.

Seeing what the Environment Variables are is one thing. Knowing what they do
is a second thing, and understanding exactly what changes you need to make
in them, and in what circumstances, and how to do so without screwing up
your system, is yet a third thing.

In my particular situation, there were three apps in the loop -- SciTE,
Python, and Csound. I would have no clue how to edit the Environment
Variables in order to solve the problem I was having.

The thing is, in order for people to be able to use Csound to make music
(which is, at the end of the day, what we're all trying to do), they do need
a Virgil to take them by the hand and guide them safely through these
circles.

A 3,000-word magazine article introducing Csound can't do that. It would
take at least 30,000 words. Michael's tutorial pdf covers a lot of this
ground; maybe some steroids could be injected into it.

--JA

-- 
View this message in context: http://www.nabble.com/Newbie-%28sort-of%29-Questions-tp17593144p17605500.html
Sent from the Csound - General mailing list archive at Nabble.com.

Jim Aikin wrote:
..
> 
> This is probably as good an example as any of the kind of invisible
> assumption I mentioned earlier. I would imagine Linux users normally, or
> quite often, think in terms of being in a console, or shell, or whatever the
> heck it's called. For Windows and Mac users, a directory is a window on the
> screen. That's all it is. You can't run anything from a window on the
> screen.
> 
Not sure what you mean here - I routinely run all sorts of things from a 
  directory window - not only .exe or .app applications, but tcl-based 
apps, even batch files. Of course, if one needs to read text output, a 
shell window is required, but that is by no means always the case. And 
of course, any file type associated with an application enables you to 
launch the app by double-clicking the file.

And conversely, one can run a gui app (with or wothout a file to load) 
by typing the command in  a shell window.

Richard Dobson

Richard Dobson wrote:
> 
> Not sure what you mean here - I routinely run all sorts of things from a 
>   directory window - not only .exe or .app applications, but tcl-based 
> apps, even batch files.
> 

I think you missed the context. Yes, certainly you can double-click an .exe
or a batch file from within a window. I was replying to this sentence, in
Michael's post: "Might be more foolproof to run "set
PYTHONPATH=c:\csound\bin;python examples\koch.py" from c:\csound...."

If there's a way to "run" a string of text directly within a window, I don't
know what it would be. Windows Explorer doesn't seem to have a text entry
field for that. Maybe the MacOS does.

--JA

-- 
View this message in context: http://www.nabble.com/Newbie-%28sort-of%29-Questions-tp17593144p17610233.html
Sent from the Csound - General mailing list archive at Nabble.com.

Quoting Richard Dobson :

> Jim Aikin wrote:
> ..
> >
> > This is probably as good an example as any of the kind of invisible
> > assumption I mentioned earlier. I would imagine Linux users normally, or
> > quite often, think in terms of being in a console, or shell, or whatever
> the
> > heck it's called. For Windows and Mac users, a directory is a window on the
> > screen. That's all it is. You can't run anything from a window on the
> > screen.
> >
> Not sure what you mean here - I routinely run all sorts of things from a
>   directory window - not only .exe or .app applications, but tcl-based
> apps, even batch files. Of course, if one needs to read text output, a
> shell window is required, but that is by no means always the case. And
> of course, any file type associated with an application enables you to
> launch the app by double-clicking the file.
>
> And conversely, one can run a gui app (with or wothout a file to load)
> by typing the command in  a shell window.
>
> Richard Dobson
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


While this is true, I don't think it detracts from Jim's argument.  Many (most?)
Windows users would not equate "run this program" with "double-click on this
program".  The issue is not just one of terminology and experience, but also
how users think about interacting with a computer.

Programmers, power users, (most) Unix users, et al. all have a (mostly correct)
model of how the computer interprets their actions.  For example, I know the
difference between typing "whoami" and "who am i" *in terms of how the computer
interprets them*.  I know why I need to press return on the CLI to make anything
happen.  Similarly, Richard knows that different UI's both enable him to tell
the computer to run a program, and that the computer *does the same thing*
regardless of the method he uses to start the process.  This model of how the
computer interprets commands makes the user feel comfortable using the
interface because they know what to expect from their actions.  Of course it
goes without saying that one can't develop a mostly-correct model without
actually having a decent understanding of how the interpreter functions, so
these users will be familiar with all the jargon already.

In contrast to this, a Windows user typically does not have a correct model of
how the computer interprets their actions, if there's any model at all.  If I'm
a typical windows user, my thought process goes like this:
"I want to edit the file 'foo'.  Where did I put it (the windows user doesn't
know or care about the filetree)? Okay, there it is, in "My Documents".  Now I
want to open it, so I double-click it (the Windows user doesn't think in terms
of running applications, only opening documents.  The two concepts become
conflated with e.g. email apps.  The user does not see a difference between
opening an "email client application" and a "document" that necessitates
another editing program (i.e. Word))."  I could go on with this, but this
incorrect and/or partial model is one of two major sources of problems for the
Windows user (the other is Microsoft. j/k).

It's already clear that Windows users have difficulty with the concept of
separating the tasks of "editing csound files" and "running csound jobs."  They
think, "I just want to run csound.  Okay, so everything says I need to make this
.csd file to run csound".  Note that while an experienced csound user would
think "edit a csound combined orc/sco file," the Windows user thinks "run
csound."  "It's a csound file, right?  So you run it with csound!" concludes
the user.  So then, after typing in the first orc/sco, how do you run it?  Type
in that "csound -odac blah blah blah" command?  Just typing it in doesn't do
anything.  Double-clicking the file again only reopens the file (or brings the
window to the front, depending on the editor).

There are a lot of other differences in how these two types of users interact
with computers, but I think they all derive from this one major problem.  Once
a user develops an incorrect model of how a computer works, it's very difficult
to unlearn it, even when it's obviously wrong.  And since it is wrong, when the
user gets into trouble they won't be able to figure anything out, and will
usually get even further off track despite their best efforts.

Motivation to learn is also a factor.  Most computer users come to a computer
and just want to get stuff done.  They want to know as little as possible about
the computer, except the minimum necessary to make it do it's job.  Nearly all
of this extra stuff seems like an unnecessary distraction, because they don't
know how much missing it affects them (this is similar to the "blub
programmer").  They want a *process for doing action x* rather than developing
the necessary knowledge to determine *how to make the computer perform action
x*.

John Lato
School of Music
The University of Texas at Austin
1 University Station
Austin, TX  78712

Jim Aikin wrote:
> 
> 
> Richard Dobson wrote:
>> Not sure what you mean here - I routinely run all sorts of things from a 
>>   directory window - not only .exe or .app applications, but tcl-based 
>> apps, even batch files.
>>
> 
> I think you missed the context. Yes, certainly you can double-click an .exe
> or a batch file from within a window. I was replying to this sentence, in
> Michael's post: "Might be more foolproof to run "set
> PYTHONPATH=c:\csound\bin;python examples\koch.py" from c:\csound...."
> 
> If there's a way to "run" a string of text directly within a window, I don't
> know what it would be. Windows Explorer doesn't seem to have a text entry
> field for that. Maybe the MacOS does.


Ah, OK; but that string is a shell (DOS) script ("set" is a command in 
shellese). One can also ask why one can't write a letter without having 
to open a word processor or text editor. In my case, as I have a console 
window open all the time (on both platforms), it is quick enough to Copy 
  the text from an email such as that and Paste it into the shell at the 
command prompt***.


Richard Dobson


***PS:

Here's a simple little Windows trick:

create a small text file called "shell.bat" containing the one line:

cmd.exe

Probably, keep it on the desktop. To open a dos shell in any open 
directory window, copy shell.bat into that directory, then double-click 
it (or press Return if it is highlighted). This opens a DOS window based 
in that directory, into which you can for example paste the text from 
that email, and run  it. Saves having to open the default shell and 
cd'ing down some possibly long-winded path.

Richard Dobson wrote:
> Here's a simple little Windows trick:
> 
> create a small text file called "shell.bat" containing the one line:
> 
> cmd.exe
> 
> 
> Saves having to open the default shell and 
> cd'ing down some possibly long-winded path.
> 

In danger of veering OT, but the Windows "Open Command Window Here" 
powertoy will do the same from an Explorer right-click context menu. 
It's one of the first things I install on a new machine (besides Csound, 
of course!).

http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx

Gareth Edwards wrote:
..
>> Saves having to open the default shell and cd'ing down some possibly 
>> long-winded path.
>>
> 
> In danger of veering OT, but the Windows "Open Command Window Here" 
> powertoy will do the same from an Explorer right-click context menu. 
> It's one of the first things I install on a new machine (besides Csound, 
> of course!).
> 
> http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx
> 

Ah thanks for the reminder about those. Hadn't realised one could 
download them individually. (hardly any of them I have a use for). I am 
now mainly on a Mac, so have lost the habit of finding "cool stuff" for 
the PC.

Richard Dobson